Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

[Kevin Benton]

>Also, in my proposal, it is more the router that is the grouping mechanism.

I can't reconcile this with all of the points you make in the rest of your
email. You want the collection of subnets that a network represents, but
you don't want any other properties of the network.

>that the network object is currently the closest thing we have to
representing the L3 part of the network.

The L3 part of a network is the subnets. You can't have IP addresses
without the subnets, you can't have floating IPs without the subnets, etc.

A Neutron network is an L2 construct that encapsulates L3 things. By
encapsulating them it also provides an implicit grouping. The routed
networks proposal basically wants that implicit grouping without the
encapsulation or the L2 part.

>We don't associate floating ips with a network because we want to arp for
them.  You're taking a consequence of the current model and its constraints
and presenting that as the motivation for the model. We do so because there
is no better L3 object to associate it to.

Don't make assumptions about how people use floating IPs now just because
it doesn't fit your use-case well. When an external network is implemented
as a real Neutron network (leaving external_network_bridge blank like we
suggest in the networking guide), normal ports can be attached and can
co-exist/communicate with the floating IPs because it behaves as an L2
network exactly as implied by the API. The current model works quite well *if
*your fabric can extend the external network everywhere it needs to be.

If you don't want floating IPs to be reachable on the network they are
associated with, then let's stop associating them with a network and
instead start associating them with a group of subnets from which they
allocate IPs.

>If we insist on a new object for the L3 part of a network then I'd say we
had better have an L3 only port to connect to it.

I don't think a new port type is necessary. We can just make the network ID
nullable for a port to indicate that it isn't attached to a Neutron network
since it won't be. It would then have a relationship to its associated
subnet via fixed_ips as it does now.

>The subnet is not the L3 object that we're looking for.  You may wish it
were but that does not make it so.

I never said a subnet is what we are looking for. The group of subnets is
what we seem to be after.

>Ignoring the forced dependence on L2, the subnets still don't stand alone
to describe just the L3 part, they must be linked to a network to make any
sense.

They don't need to be. If we made the network_id nullable on ports and
subnets, we could still have ports associated with subnets. The network
portion is the L2 portion. You don't want L2 so don't ask for the network.

I understand that we want a way to reference collections of subnets and
create ports that allocate IPs from them. Networks provide that now, but
they imply an L2 domain for the ports, which we don't want. So we are
trying to change what a network implies for this one special case, which is
going to have ripple effects everywhere.

Here are some areas where I can already see we will need special-casing:

   - DHCP agent scheduling - broadcast doesn't work on L3 networks, every
   compute node will need to use the direct tap attachment logic Neil brought
   up.
   - DHCP lease generation - a port can't get the normal subnet mask for
   the L3 network it's attached to because it would try to ARP for addresses
   in the same subnet, which are actually somewhere else.
   - Router interface attachment - what happens when a user attaches one
   interface to a regular network and one to an L3 network? Before they were
   all L2 networks so it didn't matter, but now none of the ports will be
   reachable on the L3 network without route table manipulation.
   - (or) Router creation - to avoid the above you can have different
   router types that can only attach to one or the other.
   - Every L2 attribute related to networks - we will need logic in the API
   that hides these fields or marks them as invalid and to generate an error
   if the user tries to update them.
   - Multi-provider segments - We can't let a user add an L3 segment to a
   network with L2 segments (e.g. VXLAN, VLAN). Same goes for the inverse.
   - Hierarchical port binding - coordinating ToRs for VXLAN+VLAN is l2
   encap. L3 would need route propagation logic instead.
   - Every plugin, service, tool, etc, built on the assumption that a
   Neutron network is L2.
   - Port creation - If you aren't doing the full l3 like Neil's proposal,
   you need to intercept port creation requests and schedule the port to one
   of the underlying regular networks. The port then has a different
   network_id than the one requested, or we have more special-casing to hide
   that.

All of those will be branches in the codebase to handle current Neutron
networks vs L3 networks. If we go down this route, it will be even worse
than the conditionals we have to 

[openstack-dev] Which is the correct way to set ha queues in RabbitMQ

[Alvise Dorigo]

Hi,
I read these two documents:

http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html

https://www.rdoproject.org/RabbitMQ

To configure the queues in HA mode, the two docs suggests two slightly 
different commands;


The first one says:

rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'


while the second one says:

rabbitmqctl set_policy HA '^(?!amq\.).*' '{"ha-mode": "all"}'


"ha_all" vs. "HA".

which one is correct ?

thanks,

Alvise
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Dragonflow - Weekly IRC Meeting

[Gal Sagie]

Hello Everyone,

If you are not familiar with Dragonflow, it is a lightweight SDN controller
embedded in Neutron
that tries to solve distributed virtual routing the SDN way.

Dragonflow is officially part of Neutron big tent starting at Kilo, you can
read more information
about it in the following blog posts [1], [2] and [3].

We are currently under going scale testing and performance tuning using
shaker [4] and big scale
Openstack environment.

There are many future features and ideas coming and we want to make our
discussion as
transparent and visible to everyone that is interested and hopefully
prioritize things based
on inputs from the community.

We would like to conduct a weekly IRC meeting, If you are interested in the
project
and planning to attend, please suggest what is the best day/time to do the
meeting.

Thanks
Gal.

[1] http://blog.gampel.net/2015/01/dragonflow-sdn-based-distributed.html
[2]
http://galsagie.github.io/sdn/openstack/ovs/dragonflow/2015/05/09/dragonflow-1/
[3]
http://galsagie.github.io/sdn/openstack/ovs/dragonflow/2015/05/11/dragonflow-2/
[4] https://github.com/stackforge/shaker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][extra-dhcp-opt]How to use extra-dhcp-opt when the opt_name="static-route" and opt_name="classless-static-route"?

[????]

Hi all,
When using the extr-dhcp-opt, I find the function works well when 
opt_name="mtu" and opt_name="router". The vm created will use the assigned mtu 
value or the assigned gateway. But when I create port using 
 --extra-dhcp-opt  
opt_name="static-route",opt_value="192.168.0.0/24 2.2.2.2"
the vm won't use this route. The opt_name="classless-static-route" shows the 
same result. Do i use them in the wrong way?



Any suggestion will be grateful.
Thank you.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

[Evgeniy L]

Hi Konstantin,

I'm not sure if we track such feature anywhere. But one of the reasons
to use containers on the master was to deliver plugin specific containers,
so they don't intersect and don't break Fuel master dependencies.
Do you have some specific use case for that?

Thanks,

On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov 
wrote:

> Hi,
>
> Is there a plans to allow plugin to be delivered as docker container
> images?
>
> Thanks
>
> --
> Kostiantyn Danilov aka koder.ua
> Principal software engineer, Mirantis
>
> skype:koder.ua
> http://koder-ua.blogspot.com/
> http://mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc][deb-packaging] Updated proposal for OpenStack deb packages

[Thomas Goirand]

On 07/24/2015 11:07 AM, Thierry Carrez wrote:
> Igor Yozhikov wrote:
>> Hello again to everyone, resending this letter due to typo in the topic
>> of the previous letter, apologize for this.
>> *
>> Introductory words:*
>>  I want to present renewed proposal for packaging of OpenStack
>> components for deb based Linux distributions.
>> In case of stackforge retirement, I believe that new repositories for
>> deb specs should appears under the //openstack// name-space instead of
>> //stackforge//.
>> This and further steps was also advised by dhellmann, anteaya and
>> angdraug at #openstack-meeting irc channel during/after
>> TechnicalCommittee meeting 
>> yesterday 21 of Jul 2015.
>> Also it would be great to discuss all of this during next TC meeting
>> July 28th.
> 
> Igor,
> 
> The following was proposed to the TC, but needs a revision to match what
> you propose here:
> 
> https://review.openstack.org/#/c/185187/
> 
> Would you mind updating the proposed change there ? That way we could
> discuss it at the TC next week...

Done.

Please note that package repository names are based on actual source
package names in Debian. For example, /openstack/openstack-trove and not
just trove, which refers to a Java library in Debian.

Thomas

P.S: I'd also would like to add that I've seen people bike-shedding
around the name "openstack-pkg-tools". The rename of this tool is *not*
open for discussion (it would be too much work). Yes, it's Debian
specific, but maybe it wont at some point, as there are tools that may
be interesting for RPM guys. Even if we never do that, this (Debian
native) package is prefixed by "deb-" like every other Git repository,
so there's no way to be confused. Finally, this has *nothing* to do with
the actual TC discussion, so let's discuss this issue *separately*,
shall we?


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L  wrote:

> Currently network template uses ERB [1] style template language,
> but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
> the user, with ERB which is in fact jinja and doesn't have any ERB
> features.
>

we have not so much syntax choices for  convenient templating. Network
temptales will be used by system administrators.
The '<%  %>' pair is a de-facto standart in this area. In the puppet world.
Not every system administrator will meaning ERB when seeing '<% %>' pair.
Another pairs (i.e. '<$ $>' , '<< >>', etc) looks more non-standart. Plenty
of syntax features are annoy and make usability of product less convenient.
I propose do not make extra essences on the clean area...

We never say in the docs about ERB. IMHO it's enough for leave '<%  %>' as
is.


/sv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Dmitry Tantsur]

On 07/27/2015 10:41 PM, Sean Dague wrote:

On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:

Hi friends.

Ironic implemented API "micro" versions in Kilo. We originally did this
to allow for breaking changes in the API while allowing users to opt in
to the breakage.

Since then, we've had a "default version" for our client that we bump to
something sensible with each release. Currently it is at 1.8.
Negotiation is done with the server to figure out what is supported and
adjust accordingly.

Now we've landed a patch[0] with a new version (1.11) that is not
backward compatible. It causes newly added Node objects to begin life in
the ENROLL state, rather than AVAILABLE. This is a good thing, and
people should want this! However, it is a breaking change. Automation
that adds nodes to Ironic will need to do different things after the
node-create call.

Our API versioning scheme makes this opt-in (by specifying the API
version). However, some folks have a problem with releasing this change
as-is. The logic is that we might release a client that defaults to 1.11
or higher, or the user may request 1.12 later to get a new feature, thus
breaking their application that enrolls nodes.

This is clearly backwards. Users should read release notes and be aware
of what changes between versions in the API. Users need to be aware of
the fact that our API is versioned, and use that to their advantage.

It seems to me that the goal of the version negotiation in our client
has been to pretend that our API versions don't exist, from a user
perspective. We need to stop doing this and force users to think about
what they are doing when they interact with our API.

It seems to me we have a few options here:

1) Default the python client and CLI to the earliest supported version.
This will never break users by default.

2) Default the python client and CLI to use the special version
'latest'. This will always use the latest API version, and always
break people when a new server version (that is not backwards
compatible) is deployed.

3) Do what Nova does[1]. Default CLI to latest and python client to
earliest. This assumes that CLI is typically used for one-time commands
(and it isn't a big deal if we break a one-off command once), and the
python client is used for applications.


Actually what Nova is doing is slight different than this, the CLI will
default to "latest" on the server. There will be an extra round trip to
figure out what that is. And the CLI will (long term) just not present
commands that aren't available at the server level you are talking to.

Consider the CLI an auto negotiating microversion application of the
python API client. And, realistically, should solve some of the issues
of people running "nova foo" and getting cryptic errors from the server
when they are hitting an old version of Nova that doesn't know how to foo.

So the CLI should actually break less often, and will expose the most
functionality you can get out of your cloud.


What I find weird about this and similar approaches is that we treat CLI 
and any different from other ways to use API. And I *suspect* this is 
because we, the developers, use it the most and point newcomers to it. 
And I agree it's troublesome to explain that to use "manage" provision 
verb you have to provide --ironic-api-version 1.6. Or was 1.6 for 
inspect? Hmm, I really don't remember.


CLI is not different, CLI is not special and CLI is not "an auto 
negotiating microversion application of the python API client". By 
saying any of these we just refusing it eat our dog's food. If we 
consciously believe (I personally don't) that versioning is the right 
thing to do for people using our API - lets stop dodging it ourselves. 
Otherwise it looks like we've invented an architecture that people 
presumably dream of, but we don't know if it's even usable (to say 
nothing about useful). I tried writing versioning-aware code for our 
devstack yesterday, and it wasn't that nice and shiny.


If our versioning requires negotiations, lets have it on API level, so 
that all users get it. Actually, server has the same level of 
information as the client. Let's have "X-OpenStack-XXX-Version: 
negotiate" figure out a proper version for us - or refuse to process a 
request if it's not possible. And if we think that versioning as it is 
now is unusable at all, lets rework the whole idea.


tl;dr my vote if for CLI to strictly follow whatever server API does. 
That is, default to the lowest version, require explicit version 
argument to get new features. (it's up to a follow up discussion what to 
do during the deprecation period).




-Sean




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Devs,

There is an NFS backend driver for cinder, which supports only limited volume 
handling features. Specifically, "snapshot" and "cloning" features are missing.

Eric Harney has proposed a feature of "NFS driver snapshot" [1][2][3], which 
was approved on Dec 2014 but not implemented yet.

[1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
[2] cinder-specs https://review.openstack.org/#/c/133074/  - merged for Kilo 
but moved to Liberty
[3] implementation https://review.openstack.org/#/c/147186/  - WIP

As of now [4] nova patch is a blocker for this feature.
I have tested this feature by applying [4] nova patch and it is working as per 
expectation.

[4] https://review.openstack.org/#/c/149037/

IMO this is a very useful feature and I want to know communities 
opinion/direction about getting it merged during liberty time-frame.

Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Anita Kuno]

On 07/27/2015 07:15 PM, Cathy Zhang wrote:
> Hi Anita,
> 
> Not sure if you read the logs. The concern on 
> https://review.openstack.org/#/c/186663/ and duplication were brought up by 
> Sean.
> The goal is to have one set of API instead of multiple APIs with minor 
> differences. The consensus is that the SFC API seems more general than the 
> forwarding API, the forwarding API can be covered by the chain API, and the 
> forwarding API is just a chain of 1 (a special case of chain API). Here are 
> some snips of the meeting log related to this discussion. Per my action items 
> of the meeting, I am sending out an email updating everyone about our 
> discussion and consensus. No one can force anyone else to do anything. This 
> community project team have done diligence to reach out to authors of 
> https://review.openstack.org/#/c/186663/ multiple times before about 
> collaboration and convergence of APIs (Please refer to previous meeting 
> logs). 
> 
> ---
> 17:11:55  vikram: it's not the same but it has a lot in common. If 
> we're going to have both there will need to be extremely clear documentation 
> to guide operators and tenants on when to use each.
> 17:12:16  Especially if the two can interact in unpredictable ways
> 17:12:19  pcarver: i agree..
> 17:12:23  I just feel like there are some things that are in common, 
> the idea of redirecting traffic - the mechanics may be different but I don't 
> like this idea of "oh it's just a little bit different, therefore a whole new 
> separate API is justified"
> 17:12:52  sc68cal: h
> 17:13:20  cathy_: I understand the desire to not have too many 
> dependencies, but it may make sense to have a have one be a degenerate case 
> of the other
> 17:13:42  as opposed to two unrelated things that appear similar to 
> the user
> 17:14:04  sc68cal: the sfc is more general than the forwarding spec
> 17:14:30  its functionality can be covered by the sfc spec
> 17:14:36  sc68cal, pcarver: I agree, service function chaining can 
> achieve the use case defined in forwarding spec 
> 17:15:06  LouisF, vikram: I haven't reviewed 186663 before looking 
> at it just now, but is there a reason why it couldn't be implemented as a 
> trivially simple service chain?
> 
> --
> 17:15:31  vikram:agree with you. Would you like to talk with Yuji on 
> that ?
> 17:15:32  pcarver: I believe it can
> 17:15:36  pcarver: yes I think that can be done
> 17:16:03  yeah I mean I could be stupid but the forwarding API is 
> basically just a chain of 1
> --
> 17:16:11  cathy_: We can put our concerns over the etherpad link 
> shared for this spec
> 17:16:14  and BTW - fwaas is going to be a chain of 1
> 17:16:26  https://etherpad.openstack.org/p/forwarding-rule
> 17:16:27  if we're inserting a firewall between an instance and the 
> rest of the network
> 17:16:52  I had hoped to consume SFC, to look into making fwaas more 
> flexible
> 17:17:00  sc68cal:+++100
> 17:17:41  sc68cal: +1, security functions are a primary example of 
> the reason for SFC, although not all chained functions are firewallish
> 17:17:55  +1
> 17:18:27  So we all agree that the service chain API can cover the 
> functionality needed in https://review.openstack.org/#/c/186663/
> 17:18:41  +1
> 17:18:58  I'm also hearing requirements from the NFV side wanting to 
> replicate hub and spoke topologies. I'm viewing that also as a subset of SFC
> -
> 17:21:16  So how should we make sure there is no duplicate API? Maybe 
> Vikram can communicate this with Yuji? Suggestion?
> 17:22:13  I'd say maybe an e-mail to the ML, with the results of 
> this meeting, and say that we want to try and converge where there is 
> commonality
> 17:22:19  cathy_: sure.. i have posted a comment on the spec.. will 
> try to catch him tomorrow over IRC as wekk

I'm suggesting to both yourself and Louis that a bit of humility would
be a welcome consideration to your communications.

Thank you,
Anita.


> 
> 
> 
> -Original Message-
> From: Anita Kuno [mailto:ante...@anteaya.info] 
> Sent: Monday, July 27, 2015 2:20 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] The proposed "Neutron API extension for packet 
> forwarding" has a lot of duplication to the Neutron SFC API
> 
> On 07/24/2015 06:50 PM, Cathy Zhang wrote:
>> Hi Everyone,
>> In our last networking-sfc project IRC meeting, an issue was brought up that 
>> the API proposed in https://review.openstack.org/#/c/186663/ has a lot of 
>> duplication to the SFC API https://review.openstack.org/#/c/192933/ that is 
>> being currently implemented. In the IRC meeting, the project team reached 
>> consensus that we only need one API and the service chain API can cover the 
>> functionality needed by https://review.openstack.org/#/c/186663/. Please 
>> refer to the meeting log 
>> http://eavesdrop.openstack.org/meetings/service_chaining/2015/se

Re: [openstack-dev] Announcing HyperStack project

[Adrian Otto]

Jay,

Yes, it is on the agenda.

Thanks,

Adrian

On Jul 27, 2015, at 8:32 AM, Jay Lau 
mailto:jay.lau@gmail.com>> wrote:

Adrian,

Can we put hyper as a topic for this week's (Tomorrow) meeting? I want to have 
some discussion with you.

Thanks

2015-07-27 0:43 GMT-04:00 Adrian Otto 
mailto:adrian.o...@rackspace.com>>:
Peng,

For the record, the Magnum team is not yet comfortable with this proposal. This 
arrangement is not the way we think containers should be integrated with 
OpenStack. It completely bypasses Nova, and offers no Bay abstraction, so there 
is no user selectable choice of a COE (Container Orchestration Engine). We 
advised that it would be smarter to build a nova virt driver for Hyper, and 
integrate that with Magnum so that it could work with all the different bay 
types. It also produces a situation where operators can not effectively bill 
for the services that are in use by the consumers, there is no sensible 
infrastructure layer capacity management (scheduler), no encryption management 
solution for the communication between k8s minions/nodes and the k8s master, 
and a number of other weaknesses. I’m not convinced the single-tenant approach 
here makes sense.

To be fair, the concept is interesting, and we are discussing how it could be 
integrated with Magnum. It’s appropriate for experimentation, but I would not 
characterize it as a “solution for cloud providers” for the above reasons, and 
the callouts I mentioned here:

http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html

Positioning it that way is simply premature. I strongly suggest that you attend 
the Magnum team meetings, and work through these concerns as we had Hyper on 
the agenda last Tuesday, but you did not show up to discuss it. The ML thread 
was confused by duplicate responses, which makes it rather hard to follow.

I think it’s a really bad idea to basically re-implement Nova in Hyper. Your’e 
already re-implementing Docker in Hyper. With a scope that’s too wide, you 
won’t be able to keep up with the rapid changes in these projects, and anyone 
using them will be unable to use new features that they would expect from 
Docker and Nova while you are busy copying all of that functionality each time 
new features are added. I think there’s a better approach available that does 
not require you to duplicate such a wide range of functionality. I suggest we 
work together on this, and select an approach that sets you up for success, and 
gives OpenStack could operators what they need to build services on Hyper.

Regards,

Adrian

On Jul 26, 2015, at 7:40 PM, Peng Zhao mailto:p...@hyper.sh>> 
wrote:

Hi all,
I am glad to introduce the HyperStack project to you.
HyperStack is a native, multi-tenant CaaS solution built on top of OpenStack. 
In terms of architecture, HyperStack = Bare-metal + Hyper + Kubernetes + Cinder 
+ Neutron.
HyperStack is different from Magnum in that HyperStack doesn't employ the Bay 
concept. Instead, HyperStack pools all bare-metal servers into one singe 
cluster. Due to the hypervisor nature in Hyper, different tenants' applications 
are completely isolated (no shared kernel), thus co-exist without security 
concerns in a same cluster.
Given this, HyperStack is a solution for public cloud providers who want to 
offer the secure, multi-tenant CaaS.
Ref: 
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png
The next step is to present a working beta of HyperStack at Tokyo summit, which 
we submitted a presentation: 
https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030.
 Please vote if you are interested.
In the future, we want to integrate HyperStack with Magnum and Nova to make 
sure one OpenStack deployment can offer both IaaS and native CaaS services.
Best,
Peng
-- Background 
---
Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker images 
with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different from the 
minimalist Linux distros like CoreOS by that Hyper runs on the physical box and 
load the Docker images from the metal into the VM instance, in which no guest 
OS is present. Instead, Hyper boots a minimalist kernel in the VM to host the 
Docker images (Pod).
With this approach, Hyper is able to bring some encouraging results, which are 
similar to container:
- 300ms to boot a new HyperVM instance with a pod of Docker images
- 20MB for min mem footprint of a HyperVM instance
- Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for 
scheduling
- Immune from the shared kernel problem in LXC, isolated by VM
- Work seamlessly with OpenStack components, Neutron, Cinder, due to the 
hypervisor nature
- BYOK, bring-your-own-kernel is somewhat mandatory for a public cloud platform

___

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

[Thomas Goirand]

On 07/27/2015 11:42 PM, William M Edmonds wrote:
> python-swiftclient is only needed by operators that are using the swift
> backend, so it really doesn't belong in requirements.txt. Listing it in
> requirements forces all operators to install it, even if they're not
> going to use the swift backend. When I proposed a change [1] to move
> this from requirements to test-requirements (would still be needed there
> because of tests using the swift backend), others raised concerns about
> the impact this could have on operators who use the swift backend today
> and would be upgrading to Liberty. I believe everyone agreed this should
> not be in requirements, but the fact is that it has been, so operators
> may have (incorrectly) been depending on that during upgrades. If we
> remove it in Liberty, and there are changes in Liberty that require a
> newer version of swiftclient, how would those operators know that they
> need to upgrade swiftclient?

Even if swiftclient was removed from requirements.txt, I would still
keep it as a hard Depends: in Debian, so it would not change anything
for (Debian) users.

Thomas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Alexander Kostrikov]

Completely agree with Sergey.

>Currently network template uses ERB [1] style template language,
but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
the user

[1] - I just uses <% and %> to substitute values. That is not ERB style
template language.
[2] - We are not using Jinja templating (it is just yaml file, not html
template), we are using Jinja placeholder substitution. And in current code
we have a problem with content at first parsed from yaml and that parser
treats { and [ as a start if a dict or an array.
[3] - Templates are for people who do not care about Jinja/ERB (maybe some
familiar with Puppet/Chef), so no confusion.




On Tue, Jul 28, 2015 at 10:57 AM, Sergey Vasilenko 
wrote:

>
> On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L  wrote:
>
>> Currently network template uses ERB [1] style template language,
>> but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
>> the user, with ERB which is in fact jinja and doesn't have any ERB
>> features.
>>
>
> we have not so much syntax choices for  convenient templating. Network
> temptales will be used by system administrators.
> The '<%  %>' pair is a de-facto standart in this area. In the puppet
> world. Not every system administrator will meaning ERB when seeing '<% %>'
> pair.
> Another pairs (i.e. '<$ $>' , '<< >>', etc) looks more
> non-standart. Plenty of syntax features are annoy and make usability of
> product less convenient.
> I propose do not make extra essences on the clean area...
>
> We never say in the docs about ERB. IMHO it's enough for leave '<%  %>' as
> is.
>
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Kind Regards,

Alexandr Kostrikov,

Mirantis, Inc.

35b/3, Vorontsovskaya St., 109147, Moscow, Russia


Tel.: +7 (495) 640-49-04
Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>

Skype: akostrikov_mirantis

E-mail: akostri...@mirantis.com 

*www.mirantis.com *
*www.mirantis.ru *
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Python 3: 5 more projects with a py34 voting gate, only 4 remaing

[Roman Vasilets]

I have updated it. Thank you for sharing a link.

On Mon, Jul 27, 2015 at 3:44 PM, Victor Stinner  wrote:

> Hi,
>
> On 27/07/2015 12:35, Roman Vasilets wrote:
>
>> Hi, just what to share with you. Rally project also have voting py34
>> jobs. Thank you.
>>
>
> Cool! I don't know if Rally port the Python 3 is complete or not, so I
> wrote "work in progress". Please update the wiki page if the port is done:
> https://wiki.openstack.org/wiki/Python3#OpenStack_applications
>
>
> Victor
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

[Gorka Eguileor]

On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote:
> Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +:
> > Hi Devs,
> > 
> > X-Openstack-Request-Id. We have analysed python-cinderclient, 
> > python-glanceclient, python-novaclient, python-keystoneclient and 
> > python-neutronclient to check the return types.
> > 
> > There are 9 ways return values are returned from python clients:
> > 1. List
> > 2. Dict
> > 3. Resource class object
> > 4. None
> > 5. Tuple
> > 6. Exception
> > 7. Boolean (True/False, for keystoneclient)
> > 8. Generator (for list api's in glanceclient)
> > 9. String (for novaclient)
> > 
> > Out of 9 we have solution for all return types except generator.
> > In case of glance-client list api's are returning generator which is 
> > immutable. So it is not possible to return request-id in this case, which 
> > is a blocker for adopting the solution.
> > 
> > I have added detail analysis for above return types in etherpad [2] as 
> > solution #3.
> > 
> > If you have any suggestion in case of generation type then please let me 
> > know.
> 
> It should be possible to create a new class to wrap the existing
> generator and implement the iterator protocol [3].
> 
> [3] 
> https://docs.python.org/2/reference/expressions.html#generator-iterator-methods
> 
> Doug
> 

Unless I'm missing something I think we wouldn't even need to create a
new class that implements the iterator protocol, we can just return a
generator that generates from the other one.

For example, for each of the requests, if we get the generator in
variable *result* that returns dictionaries and we want to add *headers*
to each dictionary:

return (DictWithHeaders(resource, headers) for resource in result)

Wouldn't that work?

Cheers,
Gorka.


> > 
> > 
> > [1] 
> > http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-07-21.01.log.html
> > [2] https://etherpad.openstack.org/p/request-id
> > 
> > 
> > Thanks & Best Regards,
> > 
> > Abhishek Kekane
> > 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Lucas Alvares Gomes]

Hi,

> Could you combine 1 and 4?
>
> Deprecate not specifying the version, but pin to the oldest one for now?
> That way users get the warnings that they need to adapt, but things keep
> working? Could be switched to just 4 after a few months.
>

This is similar to what I would like to suggest. But I would leave the
pin at the current version we have right now (which is 1.9 [1])
instead of the earliest one; We then add some deprecation messages
when the user do not specify a version. Otherwise we may break people
that are currently using the features up to version we have pinned
right now.

In the long run I think that option 4. is the best option. As @Jim
already pointed out from a UX point of view it's not that it will make
anything worse since we already require a number of arguments. This
will also makes users understand the versions we provide and pin his
environment at a specific version, that way it will not break due
future changes to our API and he/she can, at his/her own pace, update
his/her systems to a newest version knowing that he/she already has a
version that works.

> I say that having just added some IP addresses to a server with iproute2,
> which has been telling me for probably 10 years that _not_ adding /32
> to single IP's will eventually be deprecated...
>

Heh we should be faster than that (-:


[1] 
https://github.com/openstack/python-ironicclient/blob/52f4ba68ba8a2e45875783c3240fe58f27fa54c6/ironicclient/common/http.py#L40

Cheers,
Lucas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Evgeniy L]

Hi Alexander, I don't agree with your statements

>> [1] - I just uses <% and %> to substitute values.

It's what templating is about, you have some text preprocessor to
substitute values.

>> That is not ERB style template language.

ERB uses the same syntax, hence it Is ERB style.

>> [2] - We are not using Jinja templating (it is just yaml file, not html
template), we are using Jinja placeholder substitution.

We *are using* jinja templating (I don't understand why you mention here
html),
with all it's features and here is the proof [1].

>> And in current code we have a problem with content at first parsed from
yaml and that parser treats { and [ as a start if a dict or an array.

key: "{{blha}}"

>> [3] - Templates are for people who do not care about Jinja/ERB (maybe
some familiar with Puppet/Chef), so no confusion.

That is not correct, every template has it's own syntax, so people have to
care about
specific implementation i.e. Jinja or ERB, and there will be confusion when
somebody will
try to use ERB specific features, and she/he will fail because you hide
Jinja under ERB
syntax.

[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/objects/node.py#L854-L855


On Tue, Jul 28, 2015 at 11:29 AM, Alexander Kostrikov <
akostri...@mirantis.com> wrote:

> Completely agree with Sergey.
>
> >Currently network template uses ERB [1] style template language,
> but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
> the user
>
> [1] - I just uses <% and %> to substitute values. That is not ERB style
> template language.
> [2] - We are not using Jinja templating (it is just yaml file, not html
> template), we are using Jinja placeholder substitution. And in current code
> we have a problem with content at first parsed from yaml and that parser
> treats { and [ as a start if a dict or an array.
> [3] - Templates are for people who do not care about Jinja/ERB (maybe some
> familiar with Puppet/Chef), so no confusion.
>
>
>
>
> On Tue, Jul 28, 2015 at 10:57 AM, Sergey Vasilenko <
> svasile...@mirantis.com> wrote:
>
>>
>> On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L  wrote:
>>
>>> Currently network template uses ERB [1] style template language,
>>> but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
>>> the user, with ERB which is in fact jinja and doesn't have any ERB
>>> features.
>>>
>>
>> we have not so much syntax choices for  convenient templating. Network
>> temptales will be used by system administrators.
>> The '<%  %>' pair is a de-facto standart in this area. In the puppet
>> world. Not every system administrator will meaning ERB when seeing '<% %>'
>> pair.
>> Another pairs (i.e. '<$ $>' , '<< >>', etc) looks more
>> non-standart. Plenty of syntax features are annoy and make usability of
>> product less convenient.
>> I propose do not make extra essences on the clean area...
>>
>> We never say in the docs about ERB. IMHO it's enough for leave '<%  %>'
>> as is.
>>
>>
>> /sv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Kind Regards,
>
> Alexandr Kostrikov,
>
> Mirantis, Inc.
>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>
>
> Tel.: +7 (495) 640-49-04
> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>
> Skype: akostrikov_mirantis
>
> E-mail: akostri...@mirantis.com 
>
> *www.mirantis.com *
> *www.mirantis.ru *
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

[Jordan Pittier]

Hi

The patch [4] has been abandoned but it's not clear why. I too think that
having a full fledged NFS driver would be great !

[4] https://review.openstack.org/#/c/149037/

Jordan

On Tue, Jul 28, 2015 at 10:00 AM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

>  Hi Devs,
>
>
>
> There is an NFS backend driver for cinder, which supports only limited
> volume handling features. Specifically, "snapshot" and "cloning" features
> are missing.
>
>
>
> Eric Harney has proposed a feature of "NFS driver snapshot" [1][2][3],
> which was approved on Dec 2014 but not implemented yet.
>
>
>
> [1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
>
> [2] cinder-specs https://review.openstack.org/#/c/133074/  - merged for
> Kilo but moved to Liberty
>
> [3] implementation https://review.openstack.org/#/c/147186/  - WIP
>
>
>
> As of now [4] nova patch is a blocker for this feature.
>
> I have tested this feature by applying [4] nova patch and it is working as
> per expectation.
>
>
>
> [4] https://review.openstack.org/#/c/149037/
>
>
>
> IMO this is a very useful feature and I want to know communities
> opinion/direction about getting it merged during liberty time-frame.
>
>
>
> Thanks & Regards,
>
>
>
> Abhishek Kekane
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][RabbitMQ][puppet] Kilo status of the heartbeats implementation

[Bogdan Dobrelya]

Folks, it seems the situation with Kilo support for RabbitMQ heartbeats
should be elaborated.
There is a bug [0] and a ML [1] related. The questions are:

a) Should Fuel 7.0 with Kilo *explicitly* disable via puppet the
upstream implementation of heartbeats for all OpenStack components
(Neutron example [2]) and keep the MOS specific implementation of
heartbeats configured the same way as it was for Juno?

b) Or should we change nothing additionally allowing Oslo defaults for
Kilo being populated for heartbeats settings out of box? Related
question - what are upstream heartbeat defaults in MOS, do they differ
to upstream ones?

[0] https://bugs.launchpad.net/fuel/+bug/1477689
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068751.html
[2] https://review.openstack.org/#/c/194381/

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Cross-Project meeting, Tue July 28th, 21:00 UTC

[John Garbutt]

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting today at 21:00 UTC.
I have agreed to chair it this week.

Here is the agenda:
* Team announcements (horizontal, vertical, diagonal)
* API Guidelines that are ready for final review [1]
* Cross project specs
** No global admin [2]
** Uniform public methods for clients [3]
** Return request-id to caller - tpatil [4]
* Open discussion

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069765.html
[2] https://review.openstack.org/#/c/205629
[3] https://review.openstack.org/#/c/202586
[4] https://review.openstack.org/#/c/156508

If you're from an horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, feel free to abuse the
relevant sections of that meeting and make sure it gets #info-ed by the
meetbot in the meeting summary.

See you there!

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

[Kuvaja, Erno]

I do agree, we don't depend or are cleaning the other clients out of the glance 
dependencies as well and I think swift should not be there either.

The default store is filesystem store and if something is depending on the 
actual store clients it should be either glance_store or deployer (well for 
example our gate) glance itself should not have hard dependencies for 'em.


-  Erno

From: William M Edmonds [mailto:edmon...@us.ibm.com]
Sent: Monday, July 27, 2015 10:42 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] Removing python-swiftclient from 
requirements.txt


python-swiftclient is only needed by operators that are using the swift 
backend, so it really doesn't belong in requirements.txt. Listing it in 
requirements forces all operators to install it, even if they're not going to 
use the swift backend. When I proposed a change [1] to move this from 
requirements to test-requirements (would still be needed there because of tests 
using the swift backend), others raised concerns about the impact this could 
have on operators who use the swift backend today and would be upgrading to 
Liberty. I believe everyone agreed this should not be in requirements, but the 
fact is that it has been, so operators may have (incorrectly) been depending on 
that during upgrades. If we remove it in Liberty, and there are changes in 
Liberty that require a newer version of swiftclient, how would those operators 
know that they need to upgrade swiftclient?

The optional dependencies spec [2] could definitely help here. I don't think we 
should have to wait for that, though. This is an issue we obviously already 
have today for other backends, which indicates folks can deal with it without 
an optional dependencies implementation.

This would be a new concern for operators using the default swift backend, 
though. So how do we get the message out to those operators? And do we need to 
put out a message about this change in Liberty and then wait until Mitaka to 
actually remove this, or can we go ahead and remove in Liberty?

[1] https://review.openstack.org/#/c/203242
[2] 
http://specs.openstack.org/openstack/oslo-specs/specs/liberty/optional-deps.html

-Matthew
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Gaël Chamoulaud]

On 27/Jul/2015 .::. 15:06, Emilien Macchi wrote:
> Puppet group,
> 
> Yanis has been working in our group for a while now.
> He has been involved in a lot of tasks, let me highlight some of them:
> 
> * Many times, involved in improving consistency across our modules.
> * Strong focus on data binding, backward compatibility and flexibility.
> * Leadership on cookiebutter project [1].
> * Active participation to meetings, always with actions, and thoughts.
> * Beyond the stats, he has a good understanding of our modules, and
> quite good number of reviews, regularly.
> 
> Yanis is for our group a strong asset and I would like him part of our
> core team.
> I really think his involvement, regularity and strong knowledge in
> Puppet OpenStack will really help to make our project better and stronger.
> 
> I would like to open the vote to promote Yanis part of Puppet OpenStack
> core reviewers.
> 
> Best regards,
> 
> [1] https://github.com/openstack/puppet-openstack-cookiecutter
> -- 
> Emilien Macchi
> 

A Strong +1 :-)

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Best Regards, Gaël.

-- 
Gaël Chamoulaud
Openstack Engineering
Mail: [gchamoul|gael] at redhat dot com
IRC: strider/gchamoul (Red Hat), gchamoul (Freenode)
GnuPG Key ID: 7F4B301
C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301

Freedom...Courage...Commitment...Accountability


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature

[Aleksandr Didenko]

Hi,

I agree with Sergii, the patch had some problems only with tests which are
already resolved. So I vote for FFE.

P.S. We've just merged it.

Regards,
Alex

On Mon, Jul 27, 2015 at 3:30 PM, Sergii Golovatiuk  wrote:

> Hi,
>
> I have checked the code. After fixing tests, this patch maybe included to
> FFE as it has minimal impact on core functionality. +1 for FFE for
> https://review.openstack.org/#/c/196114/
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Mon, Jul 27, 2015 at 1:38 PM, Vladimir Kuklin 
> wrote:
>
>> There is a slight change needed, e.g. fixing of noop tests. Then we can
>> merge it and accept for FFE, I think.
>>
>> On Fri, Jul 24, 2015 at 1:34 PM, Andrian Noga  wrote:
>>
>>> Colleagues,
>>> actually, i'm tottaly agree with Mike. We can merge
>>> https://review.openstack.org/#/c/196114/ w/o additional Ceilometer
>>> support (will be moved to next release). So if we merge it today we dont
>>> need FFE for this feature.
>>>
>>>
>>> Regards,
>>> Andrian
>>>
>>> On Fri, Jul 24, 2015 at 1:18 AM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
 Since we are in FF state already, I'd like to have urgent estimate from
 one of fuel-library cores:
 - holser
 - alex_didenko
 - aglarendil
 - bogdando

 aglarendil is on vacation though. Guys, please take a look at
 https://review.openstack.org/#/c/196114/ - can we accept it as
 exception? Seems to be good to go...

 I still think that additional Ceilometer support should be moved to the
 next release.

 Thanks,

 On Thu, Jul 23, 2015 at 1:56 PM Mike Scherbakov <
 mscherba...@mirantis.com> wrote:

> Hi Andrian,
> this is High priority blueprint [1] for 7.0 timeframe. It seems we
> still didn't merge the main part [2], and need FF exception for additional
> stuff.
>
> The question is about quality. If we focus on enhancements, then we
> don't focus on bugs. Which whether means to deliver work with lower 
> quality
> of slip the release.
>
> My opinion is rather don't give FF exception in this case, and don't
> have Ceilometer support for this new feature.
>
> [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role
> [2] https://review.openstack.org/#/c/196114/
>
> On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga 
> wrote:
>
>> Hi,
>>
>> The patch patch for fuel-library
>>   that implements
>> 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) 
>> requires
>> additional work to do (ceilometer support.), but as far as I can see it
>> doesn't affect any other parts of the product.
>>
>> We plan to implement it in 3 working days (2 for implementation, 1
>> day for writing system test and test runs), it should not be hard since 
>> we
>> already support ceilometer compute agent deployment on controller
>> nodes.
>>
>> We need 1 DevOps engineer and 1 QA engineer to be engaged for this
>> work.
>>
>> So I think it's ok to accept this feature as an exception for feature
>> freeze.
>>
>> Regards,
>> Andrian Noga
>> Project manager
>> Partner Centric Engineering
>> Mirantis, Inc
>>
>> Mob.phone: +38 (063) 966-21-24
>>
>> Email: an...@mirantis.com
>> Skype: bigfoot_ua
>>
> --
> Mike Scherbakov
> #mihgen
>
 --
 Mike Scherbakov
 #mihgen

>>>
>>>
>>>
>>> --
>>> --
>>> Regards,
>>> Andrian
>>> Mirantis, Inc
>>>
>>> Mob.phone: +38 (063) 966-21-24
>>> Email: an...@mirantis.com
>>> Skype: bigfoot_ua
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
O

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L  wrote:

> Hi Alexander, I don't agree with your statements
>
> >> [1] - I just uses <% and %> to substitute values.
>
> It's what templating is about, you have some text preprocessor to
> substitute values.
>

Network templates feature don't mean any  "text preprocessor" actions. Only
value substitutions


> >> That is not ERB style template language.
>
> ERB uses the same syntax, hence it Is ERB style.
>

... hence it looks like ERB. not more.
Not only ruby used for programming. Non only EBD -- is template language. ;)


> >> [2] - We are not using Jinja templating (it is just yaml file, not html
> template), we are using Jinja placeholder substitution.
>
> We *are using* jinja templating (I don't understand why you mention here
> html),
> with all it's features and here is the proof [1].
>

We don't promise use Junja (or whatever) template language for this feature.
If some jinja features allowed for parsing Network template -- it's a bug.
We should check it and fix it.
Only value substitutions should allow in the network templates.


> >> [3] - Templates are for people who do not care about Jinja/ERB (maybe
> some familiar with Puppet/Chef), so no confusion.
>
> That is not correct, every template has it's own syntax, so people have to
> care about
> specific implementation i.e. Jinja or ERB, and there will be confusion
> when somebody will
> try to use ERB specific features, and she/he will fail because you hide
> Jinja under ERB
> syntax.
>

I, partially, agree with you. But please honored to following facts:
* In the deployers world used Jinja and ERB syntax.
* ERB used more often, because Ansible (I don't know another popular
deployers tools with Jinja templating) is to young.
* Plenty of syntax features is a really hell.

In the Network templates we don't suppose anything other than a simple
substitution variable values.
All logic of template processing implementing on Nailgun side. Now on the
template parsing, later -- on the network manipulation class.
Allowance of mix template language and Nailgun logic may lead to heavy
diagnostic issues.
Meantime I don't see any cases, where required something more, than
substitution.



/sv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

[Kekane, Abhishek]

Hi Jordan,

The patch [4] is abandoned by the owner because as of now as it’s not an 
appropriate way to fix this issue and it need to be fixed using some other way.
Nova members please let us know your suggestions about the same.

Thank you,

Abhishek Kekane

From: Jordan Pittier [mailto:jordan.pitt...@scality.com]
Sent: 28 July 2015 14:24
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend

Hi

The patch [4] has been abandoned but it's not clear why. I too think that 
having a full fledged NFS driver would be great !

[4] https://review.openstack.org/#/c/149037/

Jordan

On Tue, Jul 28, 2015 at 10:00 AM, Kekane, Abhishek 
mailto:abhishek.kek...@nttdata.com>> wrote:
Hi Devs,

There is an NFS backend driver for cinder, which supports only limited volume 
handling features. Specifically, "snapshot" and "cloning" features are missing.

Eric Harney has proposed a feature of "NFS driver snapshot" [1][2][3], which 
was approved on Dec 2014 but not implemented yet.

[1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots
[2] cinder-specs https://review.openstack.org/#/c/133074/  - merged for Kilo 
but moved to Liberty
[3] implementation https://review.openstack.org/#/c/147186/  - WIP

As of now [4] nova patch is a blocker for this feature.
I have tested this feature by applying [4] nova patch and it is working as per 
expectation.

[4] https://review.openstack.org/#/c/149037/

IMO this is a very useful feature and I want to know communities 
opinion/direction about getting it merged during liberty time-frame.

Thanks & Regards,

Abhishek Kekane

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [oslo] Suggestion to change verbose=false to true in oslo.log by default

[Dmitry Tantsur]

On 07/27/2015 02:11 PM, Sean Dague wrote:

Honestly, I think deprecating and removing 'verbose' is probably the
best option. INFO is probably the right default behavior, and it's not
really "verbose" in any real openstack usage. It is unlikely that anyone
would want that to be in the off state, and if so, they can do that via
python logging config.


Thanks!

As I saw no objections, I went ahead and proposed 
https://review.openstack.org/#/c/206437/




On 07/27/2015 06:32 AM, Dmitry Tantsur wrote:

Hi all!

I didn't find the discussion on the ML so I feel like starting one.
What was the reason of setting verbose to false by default? The patch
[1] does not provide any reasoning for it.

We all know that software does fail from time to time. While the default
level of WARN might give some signal to an operator that *something* is
wrong, it usually does not give much clues on *what* and *why*. Our logs
guidelines define INFO as units of work, and the default means that
operators/people debugging their logs won't even be able to track
transitions in their system that lead to an error/warning.

Of all people I know 100% are using DEBUG level by default, the only
post I've found here on this topic [2] seems to state the same. I
realize that DEBUG might give too much information to process (though I
always request people to enable debugging log before sending my any bug
reports). But is there really a compelling reason to disable INFO?

Examples of INFO logs from ironic tempest run:
ironic cond:
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-ir-cond.txt.gz?level=INFO

nova cpu:
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-n-cpu.txt.gz?level=INFO

and the biggest one neutron agt:
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-q-agt.txt.gz?level=INFO


As you can see, these logs are so small, you can just read through them
without any tooling! Of course it's not a real world example, but I'm
dealing with hundrer-of-megabytes debug-level text logs from nova +
ironic nearly every day. It's still manangeable for me, grep handles it
pretty well (to say nothing about journalctl).

WDYT about changing this default on oslo.log level?

Thanks,
Dmitry

[1] https://review.openstack.org/#/c/18110/
[2]
http://lists.openstack.org/pipermail/openstack-operators/2014-March/004156.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

[Sebastian Kalinowski]

It looks like most people agree on option C (implement features in fuel and
fuel2) and in the meantime
we should slowly progress with moving fuel to fuel2.

2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk :

> Hi,
>
> Every functionality should be applied to both clients. Core developers
> should set -1 if it's not applied to second version of plugin. Though I
> believe we should completely get rid of first version of CLI in Fuel 8.0
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh 
> wrote:
>
>> FWIW, I'm for option B, combined with clear timeline for porting features
>> of fuel-variant to fuel2. For example, we are developing client-side
>> functions for fuel-octane (cluster upgrade) extensions only for fuel2, and
>> don't plan to implement it for 'fuel'.
>>
>> The main reason why we can't just drop 'fuel', or rather switch it to
>> fuel2 syntax, IMO, is the possibility that someone somewhere uses its
>> current syntax for automation. However, if the function is completely new,
>> the automation of this function should be implemented with the new version
>> of syntax.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev 
>> wrote:
>>
>>> Hi all,
>>>
>>> I think that in current situation the best solution will be to add new
>>> features for the both versions of client. It may cause a little slowing
>>> down of developing each feature, but we won't have to return to them in
>>> future.
>>>
>>> 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky :
>>>
 Hello,

 My 2 cents on it.

 Following plan C requires a huge effort from developer, and it may be
 unacceptable when FF is close and there're a lot of work to do. So it
 looks like the plan B is most convenient for us and eventually we will
 have all features in fuel2.

 Alternatively we can go with C.. but only if implementing support in
 either fuel or fuel2 may be postponed to SCF.

 Thanks,
 Igor

 On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L  wrote:
 > Hi Sebastian, thanks for clarification, in this case I think we
 > should follow plan C, new features should not slow us down
 > in migration from old to new version of the client.
 >
 > On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski
 >  wrote:
 >>
 >> 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin <
 sbogat...@mirantis.com>:
 >>>
 >>> Hi,
 >>>
 >>> can we just add all needed functionality from old fuel client that
 fuel2
 >>> needs, then say that old fuel-client is deprecated now and will not
 support
 >>> some new features, then add new features to fuel2 only? It seems
 like best
 >>> way for me, cause with this approach:
 >>> 1. Clients will can use only one version of client (new one) w/o
 >>> switching between 2 clients with different syntax
 >>> 2. We won't have to add new features to two clients.
 >>
 >>
 >> Stas, of course moving it all to new fuel2 would be the best way to
 do it,
 >> but this refactoring took place in previous release. There is no one
 that
 >> ported a single command (except new ones) since then and there is no
 plan
 >> for doing so since other activities have higher priority. And
 features are
 >> still coming so it would be nice to have a policy for the time all
 commands
 >> will move to new fuel2.
 >>
 >>>
 >>>
 >>> On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L 
 wrote:
 
  Hi,
 
  The best option is to add new functionality to fuel2 only, but I
  don't think that we can do that if there is not enough
 functionality
  in fuel2, we should not ask user to switch between fuel and fuel2
  to get some specific functionality.
  Do we have some list of commands which is not covered in fuel2?
  I'm just wondering how much time will it take to implement all
  required commands in fuel2.
 >>
 >>
 >> So to compare: this is a help message for "old" fuel [1] and "new"
 fuel2
 >> [2]. There are only "node", "env" and "task" actions covered and
 even they
 >> are not covered in 100%.
 >>
 >> [1] http://paste.openstack.org/show/404439/
 >> [2] http://paste.openstack.org/show/404440/
 >>
 >>
 
 
  Thanks,
 
  On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski
   wrote:
 >
 > Hi folks,
 >
 > For a some time in python-fuelclient we have two CLI apps: `fuel`
 and
 > `fuel2`. It was done as an implementation of blueprint [1].
 > Right now there is a situation where some new features are added
 just
 > to old `fuel`, some to just `fuel2`, some to both. We cannot
 simply switch
 > completely to new `fuel2` as it d

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Evgeniy L]

Hi Sergey,

Thanks, now I see why we had misunderstanding. The problem is currently
all set of features which Jinja2 provides is available for the user. As far
as
I know there is no way in Jinja to disable all of the functionality except
just
substitution.

If we need only substitution, probably it's better to use standard
templating
in python [1], there is a way to redefine tokens, so you will be able to use
<% %> syntax if you want to.

[1] https://docs.python.org/2.6/library/string.html#template-strings

[2] http://pymotw.com/2/string/#advanced-templates

On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko 
wrote:

>
> On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L  wrote:
>
>> Hi Alexander, I don't agree with your statements
>>
>> >> [1] - I just uses <% and %> to substitute values.
>>
>> It's what templating is about, you have some text preprocessor to
>> substitute values.
>>
>
> Network templates feature don't mean any  "text preprocessor" actions.
> Only value substitutions
>
>
>> >> That is not ERB style template language.
>>
>> ERB uses the same syntax, hence it Is ERB style.
>>
>
> ... hence it looks like ERB. not more.
> Not only ruby used for programming. Non only EBD -- is template language.
> ;)
>
>
>> >> [2] - We are not using Jinja templating (it is just yaml file, not
>> html template), we are using Jinja placeholder substitution.
>>
>> We *are using* jinja templating (I don't understand why you mention here
>> html),
>> with all it's features and here is the proof [1].
>>
>
> We don't promise use Junja (or whatever) template language for this
> feature.
> If some jinja features allowed for parsing Network template -- it's a bug.
> We should check it and fix it.
> Only value substitutions should allow in the network templates.
>
>
>> >> [3] - Templates are for people who do not care about Jinja/ERB (maybe
>> some familiar with Puppet/Chef), so no confusion.
>>
>> That is not correct, every template has it's own syntax, so people have
>> to care about
>> specific implementation i.e. Jinja or ERB, and there will be confusion
>> when somebody will
>> try to use ERB specific features, and she/he will fail because you hide
>> Jinja under ERB
>> syntax.
>>
>
> I, partially, agree with you. But please honored to following facts:
> * In the deployers world used Jinja and ERB syntax.
> * ERB used more often, because Ansible (I don't know another popular
> deployers tools with Jinja templating) is to young.
> * Plenty of syntax features is a really hell.
>
> In the Network templates we don't suppose anything other than a simple
> substitution variable values.
> All logic of template processing implementing on Nailgun side. Now on the
> template parsing, later -- on the network manipulation class.
> Allowance of mix template language and Nailgun logic may lead to heavy
> diagnostic issues.
> Meantime I don't see any cases, where required something more, than
> substitution.
>
>
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][RabbitMQ][puppet] Kilo status of the heartbeats implementation

[Dmitry Mescheryakov]

Bogdan,

Answering your questions, in MOS 7.0 source code heartbeats are enabled by
default (with heartbeat_timeout_threshold value set to 60). We patched our
version of upstream stable/kilo to do so. So, in installed env heartbeats
are enabled for every component except Neutron, for which puppet manifests
explicitly disable heartbeats, as you already noted.

Regarding how should we proceed, right now we are testing how upstream
implementation performs in our environments. I suggest to postpone the
decision until we have enough data.

Thanks,

Dmitry

2015-07-28 12:06 GMT+03:00 Bogdan Dobrelya :

> Folks, it seems the situation with Kilo support for RabbitMQ heartbeats
> should be elaborated.
> There is a bug [0] and a ML [1] related. The questions are:
>
> a) Should Fuel 7.0 with Kilo *explicitly* disable via puppet the
> upstream implementation of heartbeats for all OpenStack components
> (Neutron example [2]) and keep the MOS specific implementation of
> heartbeats configured the same way as it was for Juno?
>
> b) Or should we change nothing additionally allowing Oslo defaults for
> Kilo being populated for heartbeats settings out of box? Related
> question - what are upstream heartbeat defaults in MOS, do they differ
> to upstream ones?
>
> [0] https://bugs.launchpad.net/fuel/+bug/1477689
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/068751.html
> [2] https://review.openstack.org/#/c/194381/
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon][Neutron] how to configure horizon to use lbaas api v2?

[Wilence Yao]

 Hi all,
In devstack, I configured
enable_plugin neutron-lbaas
https://git.openstack.org/openstack/neutron-lbaas
ENABLED_SERVICES+=,q-lbaasv2

so, I can use lbaasv2 api in neutronclient. But I see the agent that's name
is q-lbaasv2 not q-lbaas in screen, and horizon can  recognize it . So I
cann't use resource about lbaas in horizon.
What should to let horizon recognize q-lbaasv2?

Wilence Yao
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

>
> If we need only substitution, probably it's better to use standard
> templating
> in python [1], there is a way to redefine tokens, so you will be able to
> use
> <% %> syntax if you want to.
>
> [1] https://docs.python.org/2.6/library/string.html#template-strings
> 
> [2] http://pymotw.com/2/string/#advanced-templates
>

I think it's a better solution for this issue.

/sv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Aleksey Kasatkin]

>
> We don't promise use Junja (or whatever) template language for this
> feature.
> If some jinja features allowed for parsing Network template -- it's a bug.
> We should check it and fix it.
> Only value substitutions should allow in the network templates.
>

Yes, we just use jinja for values substitution. We could replace it with
anything else suitable here.
I don't see any reason to stick to jinja anyhow.

That is not correct, every template has it's own syntax, so people have to
> care about
> specific implementation i.e. Jinja or ERB, and there will be confusion
> when somebody will
> try to use ERB specific features, and she/he will fail because you hide
> Jinja under ERB
> syntax.
>

Format of template should be defined in docs finally. It is defined in spec
and there is explanation in slides for Demo.
It is not about jinja or ERB. It is just a token for substitution of
values. There is no jinja nor ERB features granted within template language.



Aleksey Kasatkin


On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko 
wrote:

>
> On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L  wrote:
>
>> Hi Alexander, I don't agree with your statements
>>
>> >> [1] - I just uses <% and %> to substitute values.
>>
>> It's what templating is about, you have some text preprocessor to
>> substitute values.
>>
>
> Network templates feature don't mean any  "text preprocessor" actions.
> Only value substitutions
>
>
>> >> That is not ERB style template language.
>>
>> ERB uses the same syntax, hence it Is ERB style.
>>
>
> ... hence it looks like ERB. not more.
> Not only ruby used for programming. Non only EBD -- is template language.
> ;)
>
>
>> >> [2] - We are not using Jinja templating (it is just yaml file, not
>> html template), we are using Jinja placeholder substitution.
>>
>> We *are using* jinja templating (I don't understand why you mention here
>> html),
>> with all it's features and here is the proof [1].
>>
>
> We don't promise use Junja (or whatever) template language for this
> feature.
> If some jinja features allowed for parsing Network template -- it's a bug.
> We should check it and fix it.
> Only value substitutions should allow in the network templates.
>
>
>> >> [3] - Templates are for people who do not care about Jinja/ERB (maybe
>> some familiar with Puppet/Chef), so no confusion.
>>
>> That is not correct, every template has it's own syntax, so people have
>> to care about
>> specific implementation i.e. Jinja or ERB, and there will be confusion
>> when somebody will
>> try to use ERB specific features, and she/he will fail because you hide
>> Jinja under ERB
>> syntax.
>>
>
> I, partially, agree with you. But please honored to following facts:
> * In the deployers world used Jinja and ERB syntax.
> * ERB used more often, because Ansible (I don't know another popular
> deployers tools with Jinja templating) is to young.
> * Plenty of syntax features is a really hell.
>
> In the Network templates we don't suppose anything other than a simple
> substitution variable values.
> All logic of template processing implementing on Nailgun side. Now on the
> template parsing, later -- on the network manipulation class.
> Allowance of mix template language and Nailgun logic may lead to heavy
> diagnostic issues.
> Meantime I don't see any cases, where required something more, than
> substitution.
>
>
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [murano] eslint cleanup

[Kirill Zaitsev]

Thanks Michael,
I’m actually watching this process closely, and considering switching to these 
rules, as soon as the job goes green. =)

The upside of not doing so is that, since our (murano) js code base is 
significantly smaller than that of horizon — we can impose slightly stricter 
rule set, than horizon currently does. But switching to it completely is 
something, that I do consider and it is on the roadmap =)

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com) wrote:

FYI, those rules have been moved into OpenStack under the QA program. I'm 
currently working on getting npm publish jobs to function so we can release 
those rules as well.

http://git.openstack.org/cgit/openstack/eslint-config-openstack/

Michael

On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev  wrote:
Since there was some interest in my side activity (which is described in 
https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an 
etherpad with files, that are yet to be cleaned up. 

Here is the link https://etherpad.openstack.org/p/murano-escleanup
So I suggest, that if you’re willing to help — add yourself in front of the 
file you’d like to cleanup so that we would not do the same job twice. 

When adding rule configs I try to refer to 
https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc 
(I’m considering switching to it completely, but that is a story for a 
different letter =))
 
-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__  
OpenStack Development Mailing List (not for usage questions)  
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe  
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

[Flavio Percoco]

On 28/07/15 09:15 +, Kuvaja, Erno wrote:

I do agree, we don’t depend or are cleaning the other clients out of the glance
dependencies as well and I think swift should not be there either.



The default store is filesystem store and if something is depending on the
actual store clients it should be either glance_store or deployer (well for
example our gate) glance itself should not have hard dependencies for ‘em.


Agreed!

William, would it be possible for you to spend some more time and
create a single patch that removes all non-required dependencies?

Cheers,
Flavio





-  Erno



From: William M Edmonds [mailto:edmon...@us.ibm.com]
Sent: Monday, July 27, 2015 10:42 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] Removing python-swiftclient from
requirements.txt



python-swiftclient is only needed by operators that are using the swift
backend, so it really doesn't belong in requirements.txt. Listing it in
requirements forces all operators to install it, even if they're not going to
use the swift backend. When I proposed a change [1] to move this from
requirements to test-requirements (would still be needed there because of tests
using the swift backend), others raised concerns about the impact this could
have on operators who use the swift backend today and would be upgrading to
Liberty. I believe everyone agreed this should not be in requirements, but the
fact is that it has been, so operators may have (incorrectly) been depending on
that during upgrades. If we remove it in Liberty, and there are changes in
Liberty that require a newer version of swiftclient, how would those operators
know that they need to upgrade swiftclient?

The optional dependencies spec [2] could definitely help here. I don't think we
should have to wait for that, though. This is an issue we obviously already
have today for other backends, which indicates folks can deal with it without
an optional dependencies implementation.

This would be a new concern for operators using the default swift backend,
though. So how do we get the message out to those operators? And do we need to
put out a message about this change in Liberty and then wait until Mitaka to
actually remove this, or can we go ahead and remove in Liberty?

[1] https://review.openstack.org/#/c/203242
[2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/
optional-deps.html

-Matthew




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


pgpAKKS5Gzx_m.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

[Flavio Percoco]

On 28/07/15 10:29 +0200, Thomas Goirand wrote:

On 07/27/2015 11:42 PM, William M Edmonds wrote:

python-swiftclient is only needed by operators that are using the swift
backend, so it really doesn't belong in requirements.txt. Listing it in
requirements forces all operators to install it, even if they're not
going to use the swift backend. When I proposed a change [1] to move
this from requirements to test-requirements (would still be needed there
because of tests using the swift backend), others raised concerns about
the impact this could have on operators who use the swift backend today
and would be upgrading to Liberty. I believe everyone agreed this should
not be in requirements, but the fact is that it has been, so operators
may have (incorrectly) been depending on that during upgrades. If we
remove it in Liberty, and there are changes in Liberty that require a
newer version of swiftclient, how would those operators know that they
need to upgrade swiftclient?


Even if swiftclient was removed from requirements.txt, I would still
keep it as a hard Depends: in Debian, so it would not change anything
for (Debian) users.


I think this is perfectly find and it's a good thing. Upstream
packages don't need to follow everything that happens downstream. From
a downstream perspective, it's a requirement that is not needed
neither in the CI nor in most of the development environments.

Cheers,
Flavio



Thomas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgppnN17ZocFu.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?

[Murray, Paul (HP Cloud)]

Hi jay,

There are a few Nova people in HP who intend to work on this area (perhaps you 
have heard that from Scott or Duncan). In fact I brought up that this would be 
coming up in Vancouver and that we intend to support it. Unfortunately none of 
us are available that week. I would like to be kept involved and will have to 
catch up with the other HP guys after the event.

In the meantime, if you want names to be involved beyond the cinder mid-cycle 
you can put down as a place holder for HP and I will sort out people to be 
involved when we are all back from vacation.

Paul

-Original Message-
From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net] 
Sent: 24 July 2015 22:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to 
join the Cinder mid-cycle meetup?

All,

I had the opportunity to chat with John Garbutt when he was here in Rochester 
for the Nova mid-cycle meet-up.  We discussed the fact that there was much to 
be gained by improving the communication between the Cinder and Nova teams.

With that idea in mind, it was suggested that the Cinder team open an 
invitation to Nova members to attend our mid-cycle meet-up.  The mid-cycle 
meet-up, of course, is not a secret.  A member of the Nova team has always been 
welcome to join, just hoping that an explicit invitation here may spark some 
interest.  :-)  Note:  John considered attending but is unable to do so.

The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site in Fort 
Collins, CO .  Friday is an optional code sprint day for those who are able to 
stay that long.  Details about the meet-up can be seen on our mid-cycle meetup 
planning etherpad [1].

If you are able to join us and help us work through the various challenges we 
are having between Cinder and Nova it would be greatly appreciated!

Jay

[1] https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?

[Murray, Paul (HP Cloud)]

> In the meantime, if you want names to be involved beyond the cinder mid-cycle 
> you can put down as a place holder for HP and I will sort out people to be 
> involved when we are all back from vacation.

Of course I meant you can put ME down :)

Paul

-Original Message-
From: Murray, Paul (HP Cloud) 
Sent: 28 July 2015 12:52
To: 'jsbry...@electronicjungle.net'; OpenStack Development Mailing List (not 
for usage questions)
Cc: Rosa, Andrea (HP Cloud Services)
Subject: RE: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able 
to join the Cinder mid-cycle meetup?

Hi jay,

There are a few Nova people in HP who intend to work on this area (perhaps you 
have heard that from Scott or Duncan). In fact I brought up that this would be 
coming up in Vancouver and that we intend to support it. Unfortunately none of 
us are available that week. I would like to be kept involved and will have to 
catch up with the other HP guys after the event.

In the meantime, if you want names to be involved beyond the cinder mid-cycle 
you can put down as a place holder for HP and I will sort out people to be 
involved when we are all back from vacation.

Paul

-Original Message-
From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net] 
Sent: 24 July 2015 22:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to 
join the Cinder mid-cycle meetup?

All,

I had the opportunity to chat with John Garbutt when he was here in Rochester 
for the Nova mid-cycle meet-up.  We discussed the fact that there was much to 
be gained by improving the communication between the Cinder and Nova teams.

With that idea in mind, it was suggested that the Cinder team open an 
invitation to Nova members to attend our mid-cycle meet-up.  The mid-cycle 
meet-up, of course, is not a secret.  A member of the Nova team has always been 
welcome to join, just hoping that an explicit invitation here may spark some 
interest.  :-)  Note:  John considered attending but is unable to do so.

The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site in Fort 
Collins, CO .  Friday is an optional code sprint day for those who are able to 
stay that long.  Details about the meet-up can be seen on our mid-cycle meetup 
planning etherpad [1].

If you are able to join us and help us work through the various challenges we 
are having between Cinder and Nova it would be greatly appreciated!

Jay

[1] https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][Neutron] how to configure horizon to use lbaas api v2?

[Jakub Libosvar]

On 07/28/2015 12:09 PM, Wilence Yao wrote:
> Hi all,
> In devstack, I configured
> enable_plugin neutron-lbaas
> https://git.openstack.org/openstack/neutron-lbaas
> ENABLED_SERVICES+=,q-lbaasv2
> 
> so, I can use lbaasv2 api in neutronclient. But I see the agent that's
> name is q-lbaasv2 not q-lbaas in screen, and horizon can  recognize it .
> So I cann't use resource about lbaas in horizon.
> What should to let horizon recognize q-lbaasv2?
> 
> Wilence Yao
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

This question was asked recently:
http://lists.openstack.org/pipermail/openstack-dev/2015-July/070066.html

Related BP: https://blueprints.launchpad.net/horizon/+spec/lbaas-v2-panel

Kuba

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Sebastien Badia]

On Mon, Jul 27, 2015 at 03:06:56PM (-0400), Emilien Macchi wrote:
> I would like to open the vote to promote Yanis part of Puppet OpenStack
> core reviewers.

Hi,

Yes, of course!
A big +1

Seb

-- 
Sebastien Badia


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

[Ryan Moats]

Kevin, doesn't this in itself create technical debt on the nova side in the
sense of what an instance attaches to?
I agree that it looks like less technical debt than conditionally
redefining a network, but without nova buy-in, it looks
like a non-starter...

Ryan

Kevin Benton  wrote on 07/28/2015 02:15:13 AM:

[snip]

> I would rather see something to reference a group of subnets that
> can be used for floating IP allocation and port creation in lieu of
> a network ID than the technical debt that conditionally redefining a
> network will bring.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra][puppet] Keeping common set of file synchronized across puppet modules

[Yanis Guenane]

In PuppetOpenstack we have a common set of filesthat are shared across
all our modules.
We would like to have an easy way to keep those set of filessynchronized.
Based on some discussions on #openstack-infra, infra might also be
interested by this problematic.

They are (at least) two approaches for that matter :

  * The Puppet community have developed a tool specifically for that
matter called modulesync[1] widely used in the Puppet community. One
needs to create a repo[2] with a specific layout, and then running msync
will ensure all files across every modules specified in the
managed_modules.yml file are synchronized, and if not will create a
commit to synchronized them.
  
  * The openstack-infra way : Based on my understanding, we would have
to create a repo much like this one[3] with all the common files in
there. puppet_update.sh[4] would need to be modified so that in the for
loop all the common files are copied and then the regular git workflow
happens.

The advantage I see relying on modulesync is that all the logic is taken
care of by modulesync, and the logic of the hook itself holds in one
line[5], making it pretty simple, to follow, understand and eventually
debug.

A review have been submitted[6] on infra, relying on a
propose_msync_update.sh script rather than the propose_update.sh script,
one of the comment was "I suggest to enhance that file (ie.
jenkins/scripts/propose_update.sh) instead of creating a new syncing 
setup."

As I see it, using msync and propose_update.sh while keeping the pattern
it has today is incompatible - as they overlap a lot (projects.txt vs.
managed_modules.yml, the git worflow, etc..) hence I would rather stick
with the propose_msync_update.sh patch. Using just the bit of modulesync
for its templating feature and relying on propose_update.sh for the git
workflow sounds a bit over complicated here.

Though my hope would be havingboth PuppetOpenstack and Infra to rely on
the same tooling here as it will make it consistent.I'd like to have
your feedbacks/ideas, on how best to deal with  that problematic.

Thank you,

[1] https://github.com/puppet-community/modulesync
[2] https://github.com/openstack/puppet-modulesync-configs
[3] https://github.com/pabelanger/puppet-modules-sync
[4]
https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/propose_update.sh
[5]
https://review.openstack.org/gitweb?p=openstack-infra/project-config.git;a=blob;f=jenkins/scripts/propose_msync_update.sh;h=602615f41a6c09741f953e3310bf1512033dde0c;hb=7ff5fa189392709486bc544273a1949ece4da049#l82
[6] https://review.openstack.org/#/c/189216

--
Yanis Guenane

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Which is the correct way to set ha queues in RabbitMQ

[Alex Schultz]

https://www.rabbitmq.com/ha.html

Both?  I think ha_all/HA is just the policy name and so it can be whatever
you want.

-Alex

On Tue, Jul 28, 2015 at 2:17 AM, Alvise Dorigo 
wrote:

>  Hi,
> I read these two documents:
>
>
> http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
>
> https://www.rdoproject.org/RabbitMQ
>
> To configure the queues in HA mode, the two docs suggests two slightly
> different commands;
>
> The first one says:
>
> rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'
>
>
> while the second one says:
>
> rabbitmqctl set_policy HA '^(?!amq\.).*' '{"ha-mode": "all"}'
>
>
> "ha_all" vs. "HA".
>
> which one is correct ?
>
> thanks,
>
> Alvise
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

[Doug Hellmann]

Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200:
> On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote:
> > Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +:
> > > Hi Devs,
> > > 
> > > X-Openstack-Request-Id. We have analysed python-cinderclient, 
> > > python-glanceclient, python-novaclient, python-keystoneclient and 
> > > python-neutronclient to check the return types.
> > > 
> > > There are 9 ways return values are returned from python clients:
> > > 1. List
> > > 2. Dict
> > > 3. Resource class object
> > > 4. None
> > > 5. Tuple
> > > 6. Exception
> > > 7. Boolean (True/False, for keystoneclient)
> > > 8. Generator (for list api's in glanceclient)
> > > 9. String (for novaclient)
> > > 
> > > Out of 9 we have solution for all return types except generator.
> > > In case of glance-client list api's are returning generator which is 
> > > immutable. So it is not possible to return request-id in this case, which 
> > > is a blocker for adopting the solution.
> > > 
> > > I have added detail analysis for above return types in etherpad [2] as 
> > > solution #3.
> > > 
> > > If you have any suggestion in case of generation type then please let me 
> > > know.
> > 
> > It should be possible to create a new class to wrap the existing
> > generator and implement the iterator protocol [3].
> > 
> > [3] 
> > https://docs.python.org/2/reference/expressions.html#generator-iterator-methods
> > 
> > Doug
> > 
> 
> Unless I'm missing something I think we wouldn't even need to create a
> new class that implements the iterator protocol, we can just return a
> generator that generates from the other one.
> 
> For example, for each of the requests, if we get the generator in
> variable *result* that returns dictionaries and we want to add *headers*
> to each dictionary:
> 
> return (DictWithHeaders(resource, headers) for resource in result)
> 
> Wouldn't that work?

That would work, but it wouldn't be consistent with the way I read
[2] as describing how the other methods are being updated.

For example, a method that now returns a list() will return a
ListWithHeaders(), and only that returned object will have the
headers, not its contents. A caller could do:

  response = client.some_method_returning_a_list()
  print reponse.headers

but could not do

  print response[0].headers

and get the same values.

Creating a GeneratorWithHeaders class mirrors that behavior for
methods that return generators instead of lists.

Doug

> > > [2] https://etherpad.openstack.org/p/request-id

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing HyperStack project

[Jay Lau]

Thanks Matt, though proposed but nova team think that this should belong to
Magnum ;-) We can check where is the best place for hyper.

2015-07-27 16:06 GMT-04:00 Matt Riedemann :

>
>
> On 7/26/2015 11:43 PM, Adrian Otto wrote:
>
>> Peng,
>>
>> For the record, the Magnum team is not yet comfortable with this
>> proposal. This arrangement is not the way we think containers should be
>> integrated with OpenStack. It completely bypasses Nova, and offers no
>> Bay abstraction, so there is no user selectable choice of a COE
>> (Container Orchestration Engine). We advised that it would be smarter to
>> build a nova virt driver for Hyper, and integrate that with Magnum so
>> that it could work with all the different bay types. It also produces a
>>
>
> The nova-hyper virt driver idea has already been proposed:
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/067501.html
>
>  situation where operators can not effectively bill for the services that
>> are in use by the consumers, there is no sensible infrastructure layer
>> capacity management (scheduler), no encryption management solution for
>> the communication between k8s minions/nodes and the k8s master, and a
>> number of other weaknesses. I’m not convinced the single-tenant approach
>> here makes sense.
>>
>> To be fair, the concept is interesting, and we are discussing how it
>> could be integrated with Magnum. It’s appropriate for experimentation,
>> but I would not characterize it as a “solution for cloud providers” for
>> the above reasons, and the callouts I mentioned here:
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html
>>
>> Positioning it that way is simply premature. I strongly suggest that you
>> attend the Magnum team meetings, and work through these concerns as we
>> had Hyper on the agenda last Tuesday, but you did not show up to discuss
>> it. The ML thread was confused by duplicate responses, which makes it
>> rather hard to follow.
>>
>> I think it’s a really bad idea to basically re-implement Nova in Hyper.
>> Your’e already re-implementing Docker in Hyper. With a scope that’s too
>> wide, you won’t be able to keep up with the rapid changes in these
>> projects, and anyone using them will be unable to use new features that
>> they would expect from Docker and Nova while you are busy copying all of
>> that functionality each time new features are added. I think there’s a
>> better approach available that does not require you to duplicate such a
>> wide range of functionality. I suggest we work together on this, and
>> select an approach that sets you up for success, and gives OpenStack
>> could operators what they need to build services on Hyper.
>>
>> Regards,
>>
>> Adrian
>>
>>  On Jul 26, 2015, at 7:40 PM, Peng Zhao >>
>>> > wrote:
>>>
>>> Hi all,
>>> I am glad to introduce the HyperStack project to you.
>>> HyperStack is a native, multi-tenant CaaS solution built on top of
>>> OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper +
>>> Kubernetes + Cinder + Neutron.
>>> HyperStack is different from Magnum in that HyperStack doesn't employ
>>> the Bay concept. Instead, HyperStack pools all bare-metal servers into
>>> one singe cluster. Due to the hypervisor nature in Hyper, different
>>> tenants' applications are completely isolated (no shared kernel), thus
>>> co-exist without security concerns in a same cluster.
>>> Given this, HyperStack is a solution for public cloud providers who
>>> want to offer the secure, multi-tenant CaaS.
>>> Ref:
>>>
>>> https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png
>>> <
>>> https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png
>>> >
>>> The next step is to present a working beta of HyperStack at Tokyo
>>> summit, which we submitted a presentation:
>>>
>>> https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030
>>> .
>>> Please vote if you are interested.
>>> In the future, we want to integrate HyperStack with Magnum and Nova to
>>> make sure one OpenStack deployment can offer both IaaS and native CaaS
>>> services.
>>> Best,
>>> Peng
>>> -- Background
>>>
>>> ---
>>> Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker
>>> images with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different
>>> from the minimalist Linux distros like CoreOS by that Hyper runs on
>>> the physical box and load the Docker images from the metal into the VM
>>> instance, in which no guest OS is present. Instead, Hyper boots a
>>> minimalist kernel in the VM to host the Docker images (Pod).
>>> With this approach, Hyper is able to bring some encouraging results,
>>> which are similar to container:
>>> - 300ms to boot a new HyperVM instance

Re: [openstack-dev] Announcing HyperStack project

[Jay Lau]

Thanks Adrian, we can talk later in the IRC meeting.

2015-07-28 4:07 GMT-04:00 Adrian Otto :

>  Jay,
>
>  Yes, it is on the agenda.
>
>  Thanks,
>
>  Adrian
>
>  On Jul 27, 2015, at 8:32 AM, Jay Lau  wrote:
>
>   Adrian,
>
>  Can we put hyper as a topic for this week's (Tomorrow) meeting? I want to
> have some discussion with you.
>
>  Thanks
>
> 2015-07-27 0:43 GMT-04:00 Adrian Otto :
>
>> Peng,
>>
>>  For the record, the Magnum team is not yet comfortable with this
>> proposal. This arrangement is not the way we think containers should be
>> integrated with OpenStack. It completely bypasses Nova, and offers no Bay
>> abstraction, so there is no user selectable choice of a COE (Container
>> Orchestration Engine). We advised that it would be smarter to build a nova
>> virt driver for Hyper, and integrate that with Magnum so that it could work
>> with all the different bay types. It also produces a situation where
>> operators can not effectively bill for the services that are in use by the
>> consumers, there is no sensible infrastructure layer capacity management
>> (scheduler), no encryption management solution for the communication
>> between k8s minions/nodes and the k8s master, and a number of other
>> weaknesses. I’m not convinced the single-tenant approach here makes sense.
>>
>>  To be fair, the concept is interesting, and we are discussing how it
>> could be integrated with Magnum. It’s appropriate for experimentation, but
>> I would not characterize it as a “solution for cloud providers” for the
>> above reasons, and the callouts I mentioned here:
>>
>>  http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html
>>
>>  Positioning it that way is simply premature. I strongly suggest that
>> you attend the Magnum team meetings, and work through these concerns as we
>> had Hyper on the agenda last Tuesday, but you did not show up to discuss
>> it. The ML thread was confused by duplicate responses, which makes it
>> rather hard to follow.
>>
>>  I think it’s a really bad idea to basically re-implement Nova in Hyper.
>> Your’e already re-implementing Docker in Hyper. With a scope that’s too
>> wide, you won’t be able to keep up with the rapid changes in these
>> projects, and anyone using them will be unable to use new features that
>> they would expect from Docker and Nova while you are busy copying all of
>> that functionality each time new features are added. I think there’s a
>> better approach available that does not require you to duplicate such a
>> wide range of functionality. I suggest we work together on this, and select
>> an approach that sets you up for success, and gives OpenStack could
>> operators what they need to build services on Hyper.
>>
>>  Regards,
>>
>>  Adrian
>>
>>   On Jul 26, 2015, at 7:40 PM, Peng Zhao  wrote:
>>
>> Hi all,
>>  I am glad to introduce the HyperStack project to you.
>>  HyperStack is a native, multi-tenant CaaS solution built on top of
>> OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper +
>> Kubernetes + Cinder + Neutron.
>>  HyperStack is different from Magnum in that HyperStack doesn't employ
>> the Bay concept. Instead, HyperStack pools all bare-metal servers into one
>> singe cluster. Due to the hypervisor nature in Hyper, different tenants'
>> applications are completely isolated (no shared kernel), thus co-exist
>> without security concerns in a same cluster.
>>  Given this, HyperStack is a solution for public cloud providers who want
>> to offer the secure, multi-tenant CaaS.
>>  Ref:
>> https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png
>>  The next step is to present a working beta of HyperStack at Tokyo
>> summit, which we submitted a presentation:
>> https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030.
>> Please vote if you are interested.
>>  In the future, we want to integrate HyperStack with Magnum and Nova to
>> make sure one OpenStack deployment can offer both IaaS and native CaaS
>> services.
>>  Best,
>> Peng
>>  -- Background
>> ---
>>  Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker
>> images with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different from
>> the minimalist Linux distros like CoreOS by that Hyper runs on the physical
>> box and load the Docker images from the metal into the VM instance, in
>> which no guest OS is present. Instead, Hyper boots a minimalist kernel in
>> the VM to host the Docker images (Pod).
>>  With this approach, Hyper is able to bring some encouraging results,
>> which are similar to container:
>> - 300ms to boot a new HyperVM instance with a pod of Docker images
>> - 20MB for min mem footprint of a HyperVM instance
>> - Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for
>> scheduling
>> - Immune from the shared kernel 

Re: [openstack-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance

[Flavio Percoco]

On 27/07/15 19:24 +, Ian Cordasco wrote:



On 7/27/15, 11:29, "Louis Taylor"  wrote:


On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote:

Hi operators,

In Kilo, we added the Catalog Index Service as an experimental API in
Glance.
It soon became apparent this would be better suited as a separate
project, so
it was split into the Searchlight project:

https://wiki.openstack.org/wiki/Searchlight

We've now started the process of removing the service from Glance for
the
Liberty release. Since the service was originally had the status of
being
experimental, we felt it would be okay to remove it without a cycle of
deprecation.

Is this something that would cause issues for any existing deployments?
If you
have any feelings about this one way or the other, feel free to share
your
thoughts on this mailing list or in the review to remove the code:

https://review.openstack.org/#/c/197043/


Some time has passed and no one has complained about this, so I propose
we go
ahead and remove it in liberty.

Cheers,
Louis



+1


Commented on the review! +2



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgpMBSqpUI4k3.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Flavio Percoco]

Greetings,

We recently found a bug in the Nova-Glance interaction that prevents
booting snapshots using Glance's V2 API. The bug is that Nova creates
the snapshot and sets the ramdisk_id/kernel_id to None when it's not
available.

While this was ok in V1, it causes a failure for V2 since the current
schema-properties file doesn't allow both fields to be None. The right
fix would be for Nova not to set these fields at all if no value is
found.

Nonetheless, we have a workaround that would make this work. The
workaround landed in master and it's been proposed for kilo.
Therefore, I'm asking for a stable exception to merge this patch,
which is backwards compatible (unless I'm missing something). The
exception is being requested because it does change the API.

The change proposed is to allow these fields to be None.

The review: https://review.openstack.org/#/c/205432/

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpLJLj9mYSWg.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

[Konstantin Danilov]

Evgene,

I'm sure you understand this, but just to be clear - now FUEL uses
containers on master node,
not on cluster nodes. I'm asking about plugin containers on cluster nodes.

Yep, there a particular example - VSM (Intel ceph management tool). It
requires a set of packages,
like python2.6, old django, etc, which I would rather not install on
master node directly.

Thanks

On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L  wrote:
> Hi Konstantin,
>
> I'm not sure if we track such feature anywhere. But one of the reasons
> to use containers on the master was to deliver plugin specific containers,
> so they don't intersect and don't break Fuel master dependencies.
> Do you have some specific use case for that?
>
> Thanks,
>
> On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov 
> wrote:
>>
>> Hi,
>>
>> Is there a plans to allow plugin to be delivered as docker container
>> images?
>>
>> Thanks
>>
>> --
>> Kostiantyn Danilov aka koder.ua
>> Principal software engineer, Mirantis
>>
>> skype:koder.ua
>> http://koder-ua.blogspot.com/
>> http://mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis

skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Tuesday, July 28, 2015 3:15 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [nova][glance][stable] Stable exception for bug
> #1447215: Allow ramdisk/kernel_id to be None
> 
> Greetings,
> 
> We recently found a bug in the Nova-Glance interaction that prevents
> booting snapshots using Glance's V2 API. The bug is that Nova creates the
> snapshot and sets the ramdisk_id/kernel_id to None when it's not available.
> 
> While this was ok in V1, it causes a failure for V2 since the current schema-
> properties file doesn't allow both fields to be None. The right fix would be 
> for
> Nova not to set these fields at all if no value is found.
> 
> Nonetheless, we have a workaround that would make this work. The
> workaround landed in master and it's been proposed for kilo.
> Therefore, I'm asking for a stable exception to merge this patch, which is
> backwards compatible (unless I'm missing something). The exception is being
> requested because it does change the API.

+1

In my understanding as well we would be backwards compatible and this would 
make the future upgrades so much easier in the case nova starts consuming v2 
Image API.

- Erno

> 
> The change proposed is to allow these fields to be None.
> 
> The review: https://review.openstack.org/#/c/205432/
> 
> Cheers,
> Flavio
> 
> --
> @flaper87
> Flavio Percoco
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican : Unable to create the secret after Integrating Barbican with HSM HA

[Asha Seshagiri]

Hi John ,

Any help would highly be appreciated.

Thanks and Regards,
Asha Seshagiri

On Mon, Jul 27, 2015 at 3:10 PM, Asha Seshagiri 
wrote:

> Hi John ,
>
> Thanks  a lot for providing me the response:)
> I followed the link[1] for configuring the HA SETUP
> [1] : http://docs.aws.amazon.com/cloudhsm/latest/userguide/ha-setup.html
>
> the final step in the above link  is haAdmin command which is run on the
> client side(on Barbican) .
> The slot 6 is the virtual slot(only on the client side and not visible on
> LUNA SA ) and 1 and 2 are actual slots on LUNA SA HSM
>
> Please find the response below :
>
> [root@HSM-Client bin]# ./vtl haAdmin show
>
>
>
>   HA Global Configuration Settings ===
>
>
>  HA Proxy: disabled
>
> HA Auto Recovery: disabled
>
> Maximum Auto Recovery Retry: 0
>
> Auto Recovery Poll Interval: 60 seconds
>
> HA Logging: disabled
>
> Only Show HA Slots: no
>
>
>
>   HA Group and Member Information 
>
>
>  HA Group Label: barbican_ha
>
> HA Group Number: 1489361010
>
> HA Group Slot #: 6
>
> Synchronization: enabled
>
> Group Members: 489361010, 489361011
>
> Standby members: 
>
>
>  Slot # Member S/N Member Label Status
>
> == ==  ==
>
> 1 489361010 barbican2 alive
>
> 2 489361011 barbican3 alive
>
> After knowing the virtual slot HA number , I ran the pkcs11-key-generation
> with slot number 6 which did create mkek and hmac in slot/partition 1 and 2
> automatically . I am not sure why do we have to replicate the keys between
> partitions? Configured the slot 6 on the barbican.conf as mentioned in my
> first email
>
> Not sure what might be the issue and
>
> It would be great if you could tell me the steps or where I would have
> gone wrong.
>
> Thanks and Regards,
>
> Asha Seshagiri
>
> On Mon, Jul 27, 2015 at 2:36 PM, John Vrbanac 
> wrote:
>
>>  Asha,
>>
>> I've used the Safenet HSM "HA" virtual slot setup and it does work.
>> However, the setup is very interesting because you need to generate the
>> MKEK and HMAC on a single HSM and then replicate it to the other HSMs out
>> of band of anything we have in Barbican. If I recall correctly, the Safenet
>> Luna docs mention how to replicate keys or partitions between HSMs.
>>
>>
>> John Vrbanac
>>  --
>> *From:* Asha Seshagiri 
>> *Sent:* Monday, July 27, 2015 2:00 PM
>> *To:* openstack-dev
>> *Cc:* John Wood; Douglas Mendizabal; John Vrbanac; Reller, Nathan S.
>> *Subject:* Barbican : Unable to create the secret after Integrating
>> Barbican with HSM HA
>>
>>Hi All ,
>>
>>  I am working on Integrating Barbican with HSM HA set up.
>>  I have configured slot 1 and slot 2 to be on HA on Luna SA set up . Slot
>> 6 is a virtual slot on the client side which acts as the proxy for the slot
>> 1 and 2. Hence on the Barbican side , I mentioned the slot number 6 and its
>> password which is identical to that of the passwords of slot1 and slot 2 in
>> barbican.conf file.
>>
>>  Please find the contents of the file  :
>>
>> # = Secret Store Plugin ===
>> [secretstore]
>> namespace = barbican.secretstore.plugin
>> enabled_secretstore_plugins = store_crypto
>>
>> # = Crypto plugin ===
>> [crypto]
>> namespace = barbican.crypto.plugin
>> enabled_crypto_plugins = p11_crypto
>>
>> [simple_crypto_plugin]
>> # the kek should be a 32-byte value which is base64 encoded
>> kek = 'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY='
>>
>> [dogtag_plugin]
>> pem_path = '/etc/barbican/kra_admin_cert.pem'
>> dogtag_host = localhost
>> dogtag_port = 8443
>> nss_db_path = '/etc/barbican/alias'
>> nss_db_path_ca = '/etc/barbican/alias-ca'
>> nss_password = 'password123'
>> simple_cmc_profile = 'caOtherCert'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *[p11_crypto_plugin] # Path to vendor PKCS11 library library_path =
>> '/usr/lib/libCryptoki2_64.so' # Password to login to PKCS11 session login =
>> 'test5678' # Label to identify master KEK in the HSM (must not be the same
>> as HMAC label) mkek_label = 'ha_mkek' # Length in bytes of master KEK
>> mkek_length = 32 # Label to identify HMAC key in the HSM (must not be the
>> same as MKEK label) hmac_label = 'ha_hmac' # HSM Slot id (Should correspond
>> to a configured PKCS11 slot). Default: 1 slot_id = 6 *
>> *Was able to create MKEK and HMAC successfully for the slots 1 and 2 on
>> the HSM when we run the *
>> *pkcs11-key-generation script  for slot 6 which should be the expected
>> behaviour. *
>>
>> [root@HSM-Client bin]# python pkcs11-key-generation --library-path
>> '/usr/lib/libCryptoki2_64.so'  --passphrase 'test5678' --slot-id 6 mkek
>> --label 'ha_mkek'
>> Verified label !
>> MKEK successfully generated!
>> [root@HSM-Client bin]# python pkcs11-key-generation --library-path
>> '/usr/lib/libCryptoki2_64.so' --passphrase 'test5678' --slot-id 6 hmac
>> --label 'ha_hmac'
>> HMAC successfully generated!
>> [root@HSM-Client bin]#

Re: [openstack-dev] [murano] eslint cleanup

[Michael Krotscheck]

Well, the reasons those rules are deactivated is because they simply had no
equivalent in the previous tool, and we didn't want to force the Horizon
team to suddenly take on a far more aggressive style correction job than
they'd signed up for. Once their job goes green, I'm going to start
updating those rules one by one to slowly tighten the rules set.

With that in mind though: You can always extend the openstack rules and add
your own additional restrictions. So: Best of both worlds :), just make
sure you keep track of what's coming in from upstream.

Michael

On Tue, Jul 28, 2015 at 3:58 AM Kirill Zaitsev 
wrote:

> Thanks Michael,
> I’m actually watching this process closely, and considering switching to
> these rules, as soon as the job goes green. =)
>
> The upside of not doing so is that, since our (murano) js code base is
> significantly smaller than that of horizon — we can impose slightly
> stricter rule set, than horizon currently does. But switching to it
> completely is something, that I do consider and it is on the roadmap =)
>
> --
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc
>
> On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com)
> wrote:
>
>  FYI, those rules have been moved into OpenStack under the QA program.
> I'm currently working on getting npm publish jobs to function so we can
> release those rules as well.
>
> http://git.openstack.org/cgit/openstack/eslint-config-openstack/
>
> Michael
>
>  On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev 
> wrote:
>
>>  Since there was some interest in my side activity (which is described
>> in https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve
>> created an etherpad with files, that are yet to be cleaned up.
>>
>>  Here is the link https://etherpad.openstack.org/p/murano-escleanup
>>  So I suggest, that if you’re willing to help — add yourself in front of
>> the file you’d like to cleanup so that we would not do the same job twice.
>>
>>  When adding rule configs I try to refer to
>> https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc
>>
>>  (I’m considering switching to it completely, but that is a story for a
>> different letter =))
>>
>>  --
>> Kirill Zaitsev
>> Murano team
>> Software Engineer
>> Mirantis, Inc
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Clayton O'Neill]

+1

On Tue, Jul 28, 2015 at 9:00 AM, Sebastien Badia  wrote:

> On Mon, Jul 27, 2015 at 03:06:56PM (-0400), Emilien Macchi wrote:
> > I would like to open the vote to promote Yanis part of Puppet OpenStack
> > core reviewers.
>
> Hi,
>
> Yes, of course!
> A big +1
>
> Seb
>
> --
> Sebastien Badia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Plugins] Feedback

[Sergii Golovatiuk]

Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

c. There is no documentation how to install fpb from github master branch.
It's very useful for developers who want to use latest version. We should
add something

2. Github repository [2] is messed up
a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://
cd fuel-plugins
pip install .

c. There is no tags as I can see only stable/6.0
d. There are no tests to improve code quality pep8 flask8, code coverage
e. Repository doesn't follow community standards.

3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z
How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a
plan how to address them.

Thank you in advance.

[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [midcycle][kolla] Kolla-Palooza Midcycle Event July 28th, July 29th

[Steven Dake (stdake)]

Today at 10:00 AM PST our Kola-Palooza Midcycle event begins!  Please join us 
remotely if you are not able to make it on site if you have an interest in 
deploying OpenStack using Ansible within Docker container technology.  If you 
are attending in person, please appear before 9:30 so we can get you checked in 
and settled.

The full midcyce information including remote attendance via Webex information 
Is here:
https://wiki.openstack.org/wiki/Sprints/KollaLibertySprint

A map is present in the above link if your Uber driver has trouble finding 
building D.

The full agenda is present here:
https://etherpad.openstack.org/p/liberty-kolla-midcycle

Note if we are running early/late during the day, we wont “block” and wait to 
synchronize times, so if there is only one session your interested in, you may 
try joining our IRC channel #kolla where we will list off the topics as they 
come up so you know when to join.

Looking forward to seeing folks there!

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance

[matt]

yeah that really didn't belong in glance at all.

On Tue, Jul 28, 2015 at 10:05 AM, Flavio Percoco  wrote:

> On 27/07/15 19:24 +, Ian Cordasco wrote:
>
>>
>>
>> On 7/27/15, 11:29, "Louis Taylor"  wrote:
>>
>>  On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote:
>>>
 Hi operators,

 In Kilo, we added the Catalog Index Service as an experimental API in
 Glance.
 It soon became apparent this would be better suited as a separate
 project, so
 it was split into the Searchlight project:

 https://wiki.openstack.org/wiki/Searchlight

 We've now started the process of removing the service from Glance for
 the
 Liberty release. Since the service was originally had the status of
 being
 experimental, we felt it would be okay to remove it without a cycle of
 deprecation.

 Is this something that would cause issues for any existing deployments?
 If you
 have any feelings about this one way or the other, feel free to share
 your
 thoughts on this mailing list or in the review to remove the code:

 https://review.openstack.org/#/c/197043/

>>>
>>> Some time has passed and no one has complained about this, so I propose
>>> we go
>>> ahead and remove it in liberty.
>>>
>>> Cheers,
>>> Louis
>>>
>>
>>
>> +1
>>
>
> Commented on the review! +2
>
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> @flaper87
> Flavio Percoco
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Oleksiy Molchanov]

Hello all,

We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619. I
guess not all of us have an access to this bug, so to be short:

# A "shared secret" that can be used to bootstrap Keystone.
# This "token" does not represent a user, and carries no
# explicit authorization. To disable in production (highly
# recommended), remove AdminTokenAuthMiddleware from your
# paste application pipelines (for example, in keystone-
# paste.ini). (string value)

After removing this and testing we found out that OSTF fails because it
uses admin token.

What do you think if we create ostf user like for workloads, but with wider
permissions?

BR,
Oleksiy.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Mathieu Gagné]

+1

On 2015-07-27 3:06 PM, Emilien Macchi wrote:
> Puppet group,
> 
> Yanis has been working in our group for a while now.
> He has been involved in a lot of tasks, let me highlight some of them:
> 
> * Many times, involved in improving consistency across our modules.
> * Strong focus on data binding, backward compatibility and flexibility.
> * Leadership on cookiebutter project [1].
> * Active participation to meetings, always with actions, and thoughts.
> * Beyond the stats, he has a good understanding of our modules, and
> quite good number of reviews, regularly.
> 
> Yanis is for our group a strong asset and I would like him part of our
> core team.
> I really think his involvement, regularity and strong knowledge in
> Puppet OpenStack will really help to make our project better and stronger.
> 
> I would like to open the vote to promote Yanis part of Puppet OpenStack
> core reviewers.
> 
> Best regards,
> 
> [1] https://github.com/openstack/puppet-openstack-cookiecutter
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][CI] CI on commit message

[Sergii Golovatiuk]

Hi,

It looks like our CI is not configured to set +1/-1 automatically, when
only commit message is changed. It would be nice to have +1 automatically
when I change Commit Message only instead of waiting hours on CI. It would
save some hardware resources to save some energy and help environment
protection movement.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Colleen Murphy]

On Mon, Jul 27, 2015 at 12:06 PM, Emilien Macchi  wrote:

> Puppet group,
>
> Yanis has been working in our group for a while now.
> He has been involved in a lot of tasks, let me highlight some of them:
>
> * Many times, involved in improving consistency across our modules.
> * Strong focus on data binding, backward compatibility and flexibility.
> * Leadership on cookiebutter project [1].
> * Active participation to meetings, always with actions, and thoughts.
> * Beyond the stats, he has a good understanding of our modules, and
> quite good number of reviews, regularly.
>
> Yanis is for our group a strong asset and I would like him part of our
> core team.
> I really think his involvement, regularity and strong knowledge in
> Puppet OpenStack will really help to make our project better and stronger.
>
> I would like to open the vote to promote Yanis part of Puppet OpenStack
> core reviewers.
>
> Best regards,
>
> [1] https://github.com/openstack/puppet-openstack-cookiecutter
> --
> Emilien Macchi
>
>
> +1, Yanis has been a strong contributor for a long time.

Colleen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Aleksey Kasatkin]

AFAIU, string.Template doesn't help.

This seems to be helpful:

import re
def interp(string, params):
  for item in re.findall(r'#\{([^}]*)\}', string):
string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
  return string


Evgeniy, do you know some better options for this?



Aleksey Kasatkin


On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko 
wrote:

> If we need only substitution, probably it's better to use standard
>> templating
>> in python [1], there is a way to redefine tokens, so you will be able to
>> use
>> <% %> syntax if you want to.
>>
>> [1] https://docs.python.org/2.6/library/string.html#template-strings
>> 
>> [2] http://pymotw.com/2/string/#advanced-templates
>>
>
> I think it's a better solution for this issue.
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Emilien Macchi]

On 07/28/2015 11:35 AM, Colleen Murphy wrote:
> 
> 
> On Mon, Jul 27, 2015 at 12:06 PM, Emilien Macchi  > wrote:
> 
> Puppet group,
> 
> Yanis has been working in our group for a while now.
> He has been involved in a lot of tasks, let me highlight some of them:
> 
> * Many times, involved in improving consistency across our modules.
> * Strong focus on data binding, backward compatibility and flexibility.
> * Leadership on cookiebutter project [1].
> * Active participation to meetings, always with actions, and thoughts.
> * Beyond the stats, he has a good understanding of our modules, and
> quite good number of reviews, regularly.
> 
> Yanis is for our group a strong asset and I would like him part of our
> core team.
> I really think his involvement, regularity and strong knowledge in
> Puppet OpenStack will really help to make our project better and
> stronger.
> 
> I would like to open the vote to promote Yanis part of Puppet OpenStack
> core reviewers.
> 
> Best regards,
> 
> [1] https://github.com/openstack/puppet-openstack-cookiecutter
> --
> Emilien Macchi
> 
> 
> +1, Yanis has been a strong contributor for a long time.

5 positive reviews from core-reviewers on my proposal, I guess we can
approve it.

Congratulations Yanis, you're now part of Puppet OpenStack core group!
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Aleksey Kasatkin]

Evgeniy, do we need to remove jinja before July 30th ?


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 6:40 PM, Aleksey Kasatkin 
wrote:

> AFAIU, string.Template doesn't help.
>
> This seems to be helpful:
>
> import re
> def interp(string, params):
>   for item in re.findall(r'#\{([^}]*)\}', string):
> string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
>   return string
>
>
> Evgeniy, do you know some better options for this?
>
>
>
> Aleksey Kasatkin
>
>
> On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko  > wrote:
>
>> If we need only substitution, probably it's better to use standard
>>> templating
>>> in python [1], there is a way to redefine tokens, so you will be able to
>>> use
>>> <% %> syntax if you want to.
>>>
>>> [1] https://docs.python.org/2.6/library/string.html#template-strings
>>> 
>>> [2] http://pymotw.com/2/string/#advanced-templates
>>>
>>
>> I think it's a better solution for this issue.
>>
>> /sv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Sergey Vasilenko]

On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin 
wrote:

> Evgeniy, do we need to remove jinja before July 30th ?
>

I think -- not.
It just a bug, not a key-point of feature.


/sv
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

Hey Sergii –



This is excellent feedback, thank you for taking the time to provide your
thoughts.



#1 I agree that the documentation lag is challenging – I’m not sure how to
best address this.  We could potentially prioritize updates to the Plugin
SDK for soon-to-be-released features ahead of the standard release notes
and user guide updates to ensure that plugin developers have access to this
information earlier?  A number of the docs team members will be getting
together in late August to discuss how to improve documentation, I will add
this as a topic if we don’t feel there is good resolution on the mailing
list.

*+Alexander/Evgeny to cc for their input*



#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in
the tab which should make it significantly easier for a user to find plugin
settings.  Each plugin will create a new sub-group in the Settings tab,
like Access (and others) in the screenshot below.





I don’t have any insight on the GitHub issues, so I will wait for others to
weigh in on your concerns there.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 9:51 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel][Plugins] Feedback



Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

c. There is no documentation how to install fpb from github master branch.
It's very useful for developers who want to use latest version. We should
add something

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a
plan how to address them.

Thank you in advance.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Sergii Golovatiuk]

Hi Oleksiy,

Good catch. Also OSTF should get endpoints from hiera as some plugins may
override the initial deployment settings. There may be cases when keystone
is detached by plugin.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov 
wrote:

> Hello all,
>
> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
> deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
> I guess not all of us have an access to this bug, so to be short:
>
> # A "shared secret" that can be used to bootstrap Keystone.
> # This "token" does not represent a user, and carries no
> # explicit authorization. To disable in production (highly
> # recommended), remove AdminTokenAuthMiddleware from your
> # paste application pipelines (for example, in keystone-
> # paste.ini). (string value)
>
> After removing this and testing we found out that OSTF fails because it
> uses admin token.
>
> What do you think if we create ostf user like for workloads, but with
> wider permissions?
>
> BR,
> Oleksiy.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Evgeniy L]

Aleksey, here is working version [1].

>> Evgeniy, do we need to remove jinja before July 30th ?

With this issue feature can leave, and it won't have huge user impact.
At the same time by design we didn't want to have anything except
substitution, hence it's probably as Sergey mentioned is a bug.
So looks like it can be fixed after 30th of July, and should not be
considered as a blocker. Validation is much more important, so lets
fix it first.

[1] http://paste.openstack.org/show/406104/


On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko 
wrote:

>
> On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin 
> wrote:
>
>> Evgeniy, do we need to remove jinja before July 30th ?
>>
>
> I think -- not.
> It just a bug, not a key-point of feature.
>
>
> /sv
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican : Unable to create the secret after Integrating Barbican with HSM HA

[John Vrbanac]

Asha,

I'm not sure what went wrong. Something must have happened during your HA 
setup. You might check a couple different things, first you might check out 
your HA policies and HA group setup. The other thing you might make sure is 
that you only generate one mkek and hmac on one hsm (I use direct slot and not 
the HA virtual slot for this) and then replicate (vtl haAdmin -synchronize). If 
the HA group is setup properly it should replicate your mkek and hmac across 
the other HSMs in the HA group. As a side note, the pkcs11 plugin in Barbican 
currently retrieves the mkek and hmac by label, so make sure you don't have 
multiple keys in the HSM with the same label.


John Vrbanac

From: Asha Seshagiri 
Sent: Tuesday, July 28, 2015 9:22 AM
To: John Vrbanac
Cc: openstack-dev; John Wood; Douglas Mendizabal; Reller, Nathan S.
Subject: Re: Barbican : Unable to create the secret after Integrating Barbican 
with HSM HA

Hi John ,

Any help would highly be appreciated.

Thanks and Regards,
Asha Seshagiri

On Mon, Jul 27, 2015 at 3:10 PM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi John ,

Thanks  a lot for providing me the response:)
I followed the link[1] for configuring the HA SETUP
[1] : http://docs.aws.amazon.com/cloudhsm/latest/userguide/ha-setup.html

the final step in the above link  is haAdmin command which is run on the client 
side(on Barbican) .
The slot 6 is the virtual slot(only on the client side and not visible on LUNA 
SA ) and 1 and 2 are actual slots on LUNA SA HSM

Please find the response below :

[root@HSM-Client bin]# ./vtl haAdmin show



 HA Global Configuration Settings ===


HA Proxy: disabled

HA Auto Recovery: disabled

Maximum Auto Recovery Retry: 0

Auto Recovery Poll Interval: 60 seconds

HA Logging: disabled

Only Show HA Slots: no



 HA Group and Member Information 


HA Group Label: barbican_ha

HA Group Number: 1489361010

HA Group Slot #: 6

Synchronization: enabled

Group Members: 489361010, 489361011

Standby members: 


Slot # Member S/N Member Label Status

== ==  ==

1 489361010 barbican2 alive

2 489361011 barbican3 alive

After knowing the virtual slot HA number , I ran the pkcs11-key-generation with 
slot number 6 which did create mkek and hmac in slot/partition 1 and 2 
automatically . I am not sure why do we have to replicate the keys between  
partitions? Configured the slot 6 on the barbican.conf as mentioned in my first 
email

Not sure what might be the issue and

It would be great if you could tell me the steps or where I would have gone 
wrong.

Thanks and Regards,

Asha Seshagiri

On Mon, Jul 27, 2015 at 2:36 PM, John Vrbanac 
mailto:john.vrba...@rackspace.com>> wrote:

Asha,

I've used the Safenet HSM "HA" virtual slot setup and it does work. However, 
the setup is very interesting because you need to generate the MKEK and HMAC on 
a single HSM and then replicate it to the other HSMs out of band of anything we 
have in Barbican. If I recall correctly, the Safenet Luna docs mention how to 
replicate keys or partitions between HSMs.


John Vrbanac

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Sent: Monday, July 27, 2015 2:00 PM
To: openstack-dev
Cc: John Wood; Douglas Mendizabal; John Vrbanac; Reller, Nathan S.
Subject: Barbican : Unable to create the secret after Integrating Barbican with 
HSM HA

Hi All ,

I am working on Integrating Barbican with HSM HA set up.
I have configured slot 1 and slot 2 to be on HA on Luna SA set up . Slot 6 is a 
virtual slot on the client side which acts as the proxy for the slot 1 and 2. 
Hence on the Barbican side , I mentioned the slot number 6 and its password 
which is identical to that of the passwords of slot1 and slot 2 in 
barbican.conf file.

Please find the contents of the file  :

# = Secret Store Plugin ===
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = store_crypto

# = Crypto plugin ===
[crypto]
namespace = barbican.crypto.plugin
enabled_crypto_plugins = p11_crypto

[simple_crypto_plugin]
# the kek should be a 32-byte value which is base64 encoded
kek = 'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY='

[dogtag_plugin]
pem_path = '/etc/barbican/kra_admin_cert.pem'
dogtag_host = localhost
dogtag_port = 8443
nss_db_path = '/etc/barbican/alias'
nss_db_path_ca = '/etc/barbican/alias-ca'
nss_password = 'password123'
simple_cmc_profile = 'caOtherCert'

[p11_crypto_plugin]
# Path to vendor PKCS11 library
library_path = '/usr/lib/libCryptoki2_64.so'
# Password to login to PKCS11 session
login = 'test5678'
# Label to identify master KEK in the HSM (must not be the same as HMAC label)
mkek_label = 'ha_mkek'
# Length in bytes of master KEK
mkek_length = 32
# Label to identify HMAC key in the HSM (must not be the same as MKEK label)
hmac_label = 'ha_hmac

[openstack-dev] [GSLB][LBaaS] Call for GSLB project driver nominations

[Michael Johnson]

Hello OpenStack,

We are starting up a project for Global Server Load Balancing (GSLB).
The Wiki page is here: https://wiki.openstack.org/wiki/GSLB

We are soliciting for project driver nominations for the initial team.

Drivers are expected to file, maintain, prioritize, and target
blueprints and bugs for the project in Launchpad.  Our Launchpad page
is: https://launchpad.net/gslb

Please reply to this email with your nominations.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Aleksey Kasatkin]

Okey, will do fix for validation first.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L  wrote:

> Aleksey, here is working version [1].
>
> >> Evgeniy, do we need to remove jinja before July 30th ?
>
> With this issue feature can leave, and it won't have huge user impact.
> At the same time by design we didn't want to have anything except
> substitution, hence it's probably as Sergey mentioned is a bug.
> So looks like it can be fixed after 30th of July, and should not be
> considered as a blocker. Validation is much more important, so lets
> fix it first.
>
> [1] http://paste.openstack.org/show/406104/
>
>
> On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko  > wrote:
>
>>
>> On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin > > wrote:
>>
>>> Evgeniy, do we need to remove jinja before July 30th ?
>>>
>>
>> I think -- not.
>> It just a bug, not a key-point of feature.
>>
>>
>> /sv
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Evgeniy L]

Hi Sergii, thank you for feedback,

>> c. There is no documentation how to install fpb from github master
branch. It's very useful for developers who want to use latest version. We
should add something

We had a documentation, but removed it because the newer fpb was released,
probably we should add this information permanently [1].

>> a. We are doing the same mistake putting all things into one basket.
There should be 2 repositories. One for examples and one for fpb. What's
the goal of keeping fpb in directory and examples on top?

These plugins are the data which are required for integration testing,
we test that plugin build is not broken, which we run when patch gets
published. I see nothing wrong with having the data for integration testing
in the same repository with product which should be tested.
Also in previous release we *removed* all the plugins which are not
related to the builder itself, lbaas and glusterfs.

>> This breaks a couple of things

Having data for testing in the repository doesn't break anything.

>> b. I cannot build fpm with simple

That is a good point, we should move code from fuel_plugin_builder directory
on top level, and move data for testing into examples directory.

>> c. There is no tags as I can see only stable/6.0

Correct, tags should be added.

>> d. There are no tests to improve code quality pep8 flask8, code coverage

That is not true, there are more then one hundreds unit tests which we run
for each patch with python 2.6 and python 2.7, also there are integration
tests
which check that for each patch we don't break validation and that we can
build plugins for previous versions. Plus there are functional tests which
are
written by fuel-qa team, those tests check that we perform deployment
with plugins and required functionality works correctly. Also there *is*
pep8
check [2].

>> e. Repository doesn't follow community standards.

I think this issue should be resolved with moving fuel_plugin_builder
directory
on level higher, if not, please provide more specific description what is
wrong.

>> 3. Setting tab ...

Agree.

[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204
[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21

On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk  wrote:

> Hi,
>
> I have started digging into plugins recently. There are many positive
> things though I would like to point to some problem areas
>
> 1. Documentation
>
> a. It doesn't include the features of 7.0. There are many outstanding
> features, though I needed to ping the developers to ask how these features
> work. It means that it's almost impossible to develop plugins for upcoming
> releases. The external developer needs to wait for documentation so it
> creates a lag between release and plugin release.
>
> b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
> to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
> to 12.04
>
> c. There is no documentation how to install fpb from github master branch.
> It's very useful for developers who want to use latest version. We should
> add something
>
> 2. Github repository [2] is messed up
> a. We are doing the same mistake putting all things into one basket. There
> should be 2 repositories. One for examples and one for fpb. What's the goal
> of keeping fpb in directory and examples on top? This breaks a couple of
> things
>
> b. I cannot build fpm with simple
>
> pip install git+https://
>
> Instead I am forced to do
>
> git clone https://
> cd fuel-plugins
> pip install .
>
> c. There is no tags as I can see only stable/6.0
> d. There are no tests to improve code quality pep8 flask8, code coverage
> e. Repository doesn't follow community standards.
>
> 3. Setting tab
>
> When plugin is installed, it's very hard to find in. In setting tab it's
> somewhere between A and Z
> How is user supposed to find it? There should be a separator between Core
> features and plugins. User must easily find, configure, enable/disable them.
>
> P.S. I am asking everyone to add own concerns so we'll be able to make a
> plan how to address them.
>
> Thank you in advance.
>
> [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
> [2] https://github.com/stackforge/fuel-plugins
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

[Aleksey Kasatkin]

Evgeniy, thank you for solution proposal.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:39 PM, Aleksey Kasatkin 
wrote:

> Okey, will do fix for validation first.
>
>
> Aleksey Kasatkin
>
>
> On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L  wrote:
>
>> Aleksey, here is working version [1].
>>
>> >> Evgeniy, do we need to remove jinja before July 30th ?
>>
>> With this issue feature can leave, and it won't have huge user impact.
>> At the same time by design we didn't want to have anything except
>> substitution, hence it's probably as Sergey mentioned is a bug.
>> So looks like it can be fixed after 30th of July, and should not be
>> considered as a blocker. Validation is much more important, so lets
>> fix it first.
>>
>> [1] http://paste.openstack.org/show/406104/
>>
>>
>> On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko <
>> svasile...@mirantis.com> wrote:
>>
>>>
>>> On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin <
>>> akasat...@mirantis.com> wrote:
>>>
 Evgeniy, do we need to remove jinja before July 30th ?

>>>
>>> I think -- not.
>>> It just a bug, not a key-point of feature.
>>>
>>>
>>> /sv
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][puppet] Keeping common set of file synchronized across puppet modules

[Andreas Jaeger]

On 07/28/2015 03:35 PM, Yanis Guenane wrote:

In PuppetOpenstack we have a common set of filesthat are shared across
all our modules.
We would like to have an easy way to keep those set of filessynchronized.
Based on some discussions on #openstack-infra, infra might also be
interested by this problematic.

They are (at least) two approaches for that matter :

   * The Puppet community have developed a tool specifically for that
matter called modulesync[1] widely used in the Puppet community. One
needs to create a repo[2] with a specific layout, and then running msync
will ensure all files across every modules specified in the
managed_modules.yml file are synchronized, and if not will create a
commit to synchronized them.

   * The openstack-infra way : Based on my understanding, we would have
to create a repo much like this one[3] with all the common files in
there. puppet_update.sh[4] would need to be modified so that in the for
loop all the common files are copied and then the regular git workflow
happens.

The advantage I see relying on modulesync is that all the logic is taken
care of by modulesync, and the logic of the hook itself holds in one
line[5], making it pretty simple, to follow, understand and eventually
debug.

A review have been submitted[6] on infra, relying on a
propose_msync_update.sh script rather than the propose_update.sh script,
one of the comment was "I suggest to enhance that file (ie.
jenkins/scripts/propose_update.sh) instead of creating a new syncing
setup."

As I see it, using msync and propose_update.sh while keeping the pattern
it has today is incompatible - as they overlap a lot (projects.txt vs.
managed_modules.yml, the git worflow, etc..) hence I would rather stick
with the propose_msync_update.sh patch. Using just the bit of modulesync
for its templating feature and relying on propose_update.sh for the git
workflow sounds a bit over complicated here.

Though my hope would be havingboth PuppetOpenstack and Infra to rely on
the same tooling here as it will make it consistent.I'd like to have
your feedbacks/ideas, on how best to deal with  that problematic.

Thank you,

[1] https://github.com/puppet-community/modulesync
[2] https://github.com/openstack/puppet-modulesync-configs
[3] https://github.com/pabelanger/puppet-modules-sync
[4]
https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/propose_update.sh
[5]
https://review.openstack.org/gitweb?p=openstack-infra/project-config.git;a=blob;f=jenkins/scripts/propose_msync_update.sh;h=602615f41a6c09741f953e3310bf1512033dde0c;hb=7ff5fa189392709486bc544273a1949ece4da049#l82
[6] https://review.openstack.org/#/c/189216


Yanis, thanks for the explanation. This helps to understand what you're 
doing. Still I have some questions. I'll also comment in the review with 
some specific comments.


Will this script do the same what propose_update.sh does, especially:

* Send a request to gerrit?
* If there is a proposed change already for a project, reuse that one 
instead of creating a new one?

* Will msync check out the git repositories itself?


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Andrew Woodward]

IIRC the puppet modules, and even the heat domain create script make use of
the token straight from the config file. It not being present could cause
problems for some of the manifests. We would need to ensure that their
usage is minimized or removed.

On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk 
wrote:

> Hi Oleksiy,
>
> Good catch. Also OSTF should get endpoints from hiera as some plugins may
> override the initial deployment settings. There may be cases when keystone
> is detached by plugin.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov <
> omolcha...@mirantis.com> wrote:
>
>> Hello all,
>>
>> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
>> deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
>> I guess not all of us have an access to this bug, so to be short:
>>
>> # A "shared secret" that can be used to bootstrap Keystone.
>> # This "token" does not represent a user, and carries no
>> # explicit authorization. To disable in production (highly
>> # recommended), remove AdminTokenAuthMiddleware from your
>> # paste application pipelines (for example, in keystone-
>> # paste.ini). (string value)
>>
>> After removing this and testing we found out that OSTF fails because it
>> uses admin token.
>>
>> What do you think if we create ostf user like for workloads, but with
>> wider permissions?
>>
>> BR,
>> Oleksiy.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Patrick Petit]

Hi

Additional comments inside.
Thanks
Patrick

On 28 Jul 2015 at 18:33:34, Sheena Gregson (sgreg...@mirantis.com) wrote:
Hey Sergii –

 

This is excellent feedback, thank you for taking the time to provide your 
thoughts.

 

#1 I agree that the documentation lag is challenging – I’m not sure how to best 
address this.  We could potentially prioritize updates to the Plugin SDK for 
soon-to-be-released features ahead of the standard release notes and user guide 
updates to ensure that plugin developers have access to this information 
earlier?  A number of the docs team members will be getting together in late 
August to discuss how to improve documentation, I will add this as a topic if 
we don’t feel there is good resolution on the mailing list.

+Alexander/Evgeny to cc for their input

+1. Yes that’s a huge impediment! Struggling myself with the same issue since 
we are supposed to release Plugins at about the same time as the new Plugins 
SDK released in Fuel. 

It’s also true that Plugins documentation lacks information about how to build 
the fpb builder.
 

#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the 
tab which should make it significantly easier for a user to find plugin 
settings.  Each plugin will create a new sub-group in the Settings tab, like 
Access (and others) in the screenshot below.

That’s certainly a very significant improvement compared to the previous 
version. But, as already stated in a retrospective meeting, going forward we’ll 
need an even more flexible way to link Plugins with settings in that settings 
could be made common to multiple plugins. I am thinking of more logical 
grouping (by feature category) independent of the underlying Plugins breakdown. 
For example, we could have an LMA monitoring settings category common to all 
LMA related plugins. This should be less confusing for users and avoid settings 
duplicates. Hope this is making sense…


 



 

I don’t have any insight on the GitHub issues, so I will wait for others to 
weigh in on your concerns there.

 

Sheena

 

From: Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
Sent: Tuesday, July 28, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Fuel][Plugins] Feedback

 

Hi,

I have started digging into plugins recently. There are many positive things 
though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding features, 
though I needed to ping the developers to ask how these features work. It means 
that it's almost impossible to develop plugins for upcoming releases. The 
external developer needs to wait for documentation so it creates a lag between 
release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 
14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04

c. There is no documentation how to install fpb from github master branch. It's 
very useful for developers who want to use latest version. We should add 
something

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There 
should be 2 repositories. One for examples and one for fpb. What's the goal of 
keeping fpb in directory and examples on top? This breaks a couple of things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .

 

c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.

 

3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's 
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core 
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a plan 
how to address them.

Thank you in advance.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

__ 
OpenStack Development Mailing List (not for usage questions) 
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Matt Riedemann]

On 7/28/2015 9:24 AM, Kuvaja, Erno wrote:

-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Tuesday, July 28, 2015 3:15 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][glance][stable] Stable exception for bug
#1447215: Allow ramdisk/kernel_id to be None

Greetings,

We recently found a bug in the Nova-Glance interaction that prevents
booting snapshots using Glance's V2 API. The bug is that Nova creates the
snapshot and sets the ramdisk_id/kernel_id to None when it's not available.

While this was ok in V1, it causes a failure for V2 since the current schema-
properties file doesn't allow both fields to be None. The right fix would be for
Nova not to set these fields at all if no value is found.

Nonetheless, we have a workaround that would make this work. The
workaround landed in master and it's been proposed for kilo.
Therefore, I'm asking for a stable exception to merge this patch, which is
backwards compatible (unless I'm missing something). The exception is being
requested because it does change the API.


+1

In my understanding as well we would be backwards compatible and this would 
make the future upgrades so much easier in the case nova starts consuming v2 
Image API.

- Erno



The change proposed is to allow these fields to be None.

The review: https://review.openstack.org/#/c/205432/

Cheers,
Flavio

--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Nova doesn't support glance v2 in kilo or liberty, so does it matter to 
nova if this is in stable/kilo or not?  Doesn't seem like it.  This is a 
barrier to getting glance v2 support into nova in mitaka though it seems.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] VM for Openstack Horizon error

[Chandeep Khamba]

Hi Guys,


I have a VM and did a ansible-playbook on main.yaml.

Looks like the Yaml files for the services has a thing  
https://stash.us.cray.com/projects/NEWT/repos/openstack-ansible/browse/openstack.yaml

# FIXME: Anvil does not currently provide the dashboard packages
- include: services/dashboard/main.yaml
  when: not using_anvil
- include: services/heat/main.yaml


It does not let me install the horizon dashboard on my VM..

Does anyone have an idea what an anvil is , and can I disable it ??



Thanks
Chandeep
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

Evgeniy –



For the items which you have listed actions, who should be responsible for
next steps?



Sheena



*From:* Evgeniy L [mailto:e...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 11:54 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



Hi Sergii, thank you for feedback,



>> c. There is no documentation how to install fpb from github master
branch. It's very useful for developers who want to use latest version. We
should add something



We had a documentation, but removed it because the newer fpb was released,

probably we should add this information permanently [1].



>> a. We are doing the same mistake putting all things into one basket.
There should be 2 repositories. One for examples and one for fpb. What's
the goal of keeping fpb in directory and examples on top?



These plugins are the data which are required for integration testing,

we test that plugin build is not broken, which we run when patch gets

published. I see nothing wrong with having the data for integration testing

in the same repository with product which should be tested.

Also in previous release we *removed* all the plugins which are not

related to the builder itself, lbaas and glusterfs.



>> This breaks a couple of things



Having data for testing in the repository doesn't break anything.



>> b. I cannot build fpm with simple



That is a good point, we should move code from fuel_plugin_builder directory

on top level, and move data for testing into examples directory.



>> c. There is no tags as I can see only stable/6.0



Correct, tags should be added.



>> d. There are no tests to improve code quality pep8 flask8, code coverage



That is not true, there are more then one hundreds unit tests which we run

for each patch with python 2.6 and python 2.7, also there are integration
tests

which check that for each patch we don't break validation and that we can

build plugins for previous versions. Plus there are functional tests which
are

written by fuel-qa team, those tests check that we perform deployment

with plugins and required functionality works correctly. Also there *is*
pep8

check [2].



>> e. Repository doesn't follow community standards.



I think this issue should be resolved with moving fuel_plugin_builder
directory

on level higher, if not, please provide more specific description what is
wrong.



>> 3. Setting tab ...



Agree.



[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204

[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk 
wrote:

Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

c. There is no documentation how to install fpb from github master branch.
It's very useful for developers who want to use latest version. We should
add something

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a
plan how to address them.

Thank you in advance.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)

[Eugene Bogdanov]

Good, thanks everyone for your feedback. Konstantin, let's do as 
suggested - merge pb_num calculation as a bugfix and postpone UI part 
for next release. Indeed, we don't need FF exception here.


--
EugeneB




Vitaly Kramskikh 
27 июля 2015 г., 13:57
+1 to Stanislav's proposal.




--
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Stanislav Makar 
27 июля 2015 г., 3:05

Hello
I went through LP-1464656 and I see that it covers two things:
1. Bad pg num calculation algorithm.
2. Add the possibility to set pg num via GUI.

First is the most important and a BUG by itself, second is nice to 
have feature and no more.

Hence we should split it into a bug and a feature.

As the main part is a bug it does not impact FF at all.

My +1 to close bad pg num calculation algorithm as a bug and postpone 
specifying pg_num via GUI to the next release.


/All the best
Stanislav Makar

+1 for FFE
Given how borken pg_num calculations are now, this is essential to the 
ceph story and there is no point in testing ceph at scale with out it.


The only work-around for not having this is to delete all of the pools 
by hand after deployment and calculate the values by hand, and 
re-create the pools by hand. The story from that alone makes it high 
on the UX scale, which means we might as well fix it as a bug.


The scope of impact is limited to only ceph, the testing plan needs 
more detail, and we are still comming to turns with some of the data 
format to process between nailgun calculating and puppet consuming.


We would need about 1.2 week to get these landed.

--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Andrew Woodward 
25 июля 2015 г., 1:58
+1 for FFE
Given how borken pg_num calculations are now, this is essential to the 
ceph story and there is no point in testing ceph at scale with out it.


The only work-around for not having this is to delete all of the pools 
by hand after deployment and calculate the values by hand, and 
re-create the pools by hand. The story from that alone makes it high 
on the UX scale, which means we might as well fix it as a bug.


The scope of impact is limited to only ceph, the testing plan needs 
more detail, and we are still comming to turns with some of the data 
format to process between nailgun calculating and puppet consuming.


We would need about 1.2 week to get these landed.

--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Konstantin Danilov 
24 июля 2015 г., 13:46
Team,

I would like to request an exception from the Feature Freeze for [1]
fix. It requires changes in
fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already
tested, I'm fixing UT now.
BP - [4]

Code has backward-compatibility mode. I need one more week to finish 
it. Also
I'm asking someone to be an assigned code-reviewer for this ticket to 
speed-up

review process.

Thanks

[1] https://bugs.launchpad.net/fuel/+bug/1464656
[2] https://review.openstack.org/#/c/204814
[3] https://review.openstack.org/#/c/204811
[4] https://review.openstack.org/#/c/203062



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Fox, Kevin M]

+1. Our production system hit this on Juno -> Kilo upgrade.

Thanks,
Kevin

From: Flavio Percoco [fla...@redhat.com]
Sent: Tuesday, July 28, 2015 7:15 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][glance][stable] Stable exception for bug 
#1447215: Allow ramdisk/kernel_id to be None

Greetings,

We recently found a bug in the Nova-Glance interaction that prevents
booting snapshots using Glance's V2 API. The bug is that Nova creates
the snapshot and sets the ramdisk_id/kernel_id to None when it's not
available.

While this was ok in V1, it causes a failure for V2 since the current
schema-properties file doesn't allow both fields to be None. The right
fix would be for Nova not to set these fields at all if no value is
found.

Nonetheless, we have a workaround that would make this work. The
workaround landed in master and it's been proposed for kilo.
Therefore, I'm asking for a stable exception to merge this patch,
which is backwards compatible (unless I'm missing something). The
exception is being requested because it does change the API.

The change proposed is to allow these fields to be None.

The review: https://review.openstack.org/#/c/205432/

Cheers,
Flavio

--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Sean Dague]

On 07/28/2015 01:39 PM, Matt Riedemann wrote:

> 
> Nova doesn't support glance v2 in kilo or liberty, so does it matter to
> nova if this is in stable/kilo or not?  Doesn't seem like it.  This is a
> barrier to getting glance v2 support into nova in mitaka though it seems.

It matters for the following reason. If you create an image via Nova in
Kilo (image proxy, snapshot, etc), that image is not accessible over
glance v2 (which is the default for glanceclient in the kilo timeframe).
It just explodes instead.

I'd consider this pretty critical failure of compatibility between v2
and v1 in glance. It also points at a missing set of test cases which is
to create images via 1 API and be able to access them over the other. I
don't know if that is in process or not, but it would be really good to
deliver those test cases as part of this work.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] propose adding Robert Collins to requirements-core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-07-24 12:21:16 -0400:
> Requirements reviewers,
> 
> I propose that we add Robert Collins (lifeless) to the requirements-core
> review team.
> 
> Robert has been doing excellent work this cycle with updating pip and
> our requirements repository to support constraints. As a result he has a
> full understanding of the sorts of checks we should be doing for new
> requirements, and I think he would make a good addition to the team.
> 
> Please indicate +1 or -1 with concerns on this thread, as usual.

After 4 days with only positive responses, I went ahead and added Robert
to the team in gerrit.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Shraddha Pandhe]

Hi,

I started working on this patch for bug [0], but it doesn't seem as
straightforward as Kevin and I initially thought. Here's why:

Initially we thought that a simple self.cache.push_port will work as
follows:

In __init__ [1], in _populate_network_cache [2], get all existing active
networks from neutron using plugin_rpc similar to [3]. Then, for each of
those networks, go through all the subnets and ports and add them in [4]
before updating the cache.

But I realized that this will not work because, if we try to get all active
subnets and ports and populate those in cache, we may miss the delta.
Consider following scenario:

Cache state before agent stopped:
networks 1
subnets 4
ports 10

While the agent was down:
networks 1
subnets 6
ports 12

Now, then the agent comes back up, if we follow the above method, the
network cache will immediately populate itself to the new state, without
actually creating those subnets and ports in dhcp config. So if we want to
follow this route, we need a mechanism to get known_subnet_ids and
known_port_ids from dhcp driver, just like we get known_network_ids at [5]
&[6]. To me, that seems too much work for what it does.

Any better ideas to solve this problem?



[0] https://bugs.launchpad.net/neutron/+bug/1470612
[1]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L54
[2]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L75
[3]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L156
[4]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L85
[5]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L78
[6]
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L293-L302

On Wed, Jul 1, 2015 at 11:28 AM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:

> Hi,
>
> I had a discussion about this with Kevin Benton on IRC. Filed a bug:
> https://bugs.launchpad.net/neutron/+bug/1470612
>
> Thanks!
>
>
> On Wed, Jul 1, 2015 at 11:03 AM, Shraddha Pandhe <
> spandhe.openst...@gmail.com> wrote:
>
>> Hi Shihan,
>>
>> I think the problem is slightly different. Does your patch take care of
>> the scenario where a port was deleted  AFTER agent restart (not when agent
>> was down)?
>>
>> My problem is that, when the agent restarts, it loses its previous
>> network cache. As soon as the agent starts, as part of "__init__", it
>> rebuilds that cache [1]. But it does not put the ports in there [2].
>>
>> In sync_state, Neutron tries to enable/disable networks, by checking the
>> diff between Neutron's state and its own network cache that it just built
>> [3]. It enables any NEW networks and disables any DELETED networks, but it
>> does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
>> remain empty lists.
>>
>> Now, if such a port is deleted, [4] will return None and the port will
>> never get deleted from the config.
>>
>> [1]
>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
>> [2]
>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
>> [3]
>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
>> [4]
>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>>
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Shraddha Pandhe]

Hi,

I have added few more questions to the bug [1]. Please confirm my
understanding.


[1] https://bugs.launchpad.net/neutron/+bug/1470612/comments/12

On Tue, Jul 28, 2015 at 12:14 PM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:

> Hi,
>
> I started working on this patch for bug [0], but it doesn't seem as
> straightforward as Kevin and I initially thought. Here's why:
>
> Initially we thought that a simple self.cache.push_port will work as
> follows:
>
> In __init__ [1], in _populate_network_cache [2], get all existing active
> networks from neutron using plugin_rpc similar to [3]. Then, for each of
> those networks, go through all the subnets and ports and add them in [4]
> before updating the cache.
>
> But I realized that this will not work because, if we try to get all
> active subnets and ports and populate those in cache, we may miss the
> delta. Consider following scenario:
>
> Cache state before agent stopped:
> networks 1
> subnets 4
> ports 10
>
> While the agent was down:
> networks 1
> subnets 6
> ports 12
>
> Now, then the agent comes back up, if we follow the above method, the
> network cache will immediately populate itself to the new state, without
> actually creating those subnets and ports in dhcp config. So if we want to
> follow this route, we need a mechanism to get known_subnet_ids and
> known_port_ids from dhcp driver, just like we get known_network_ids at [5]
> &[6]. To me, that seems too much work for what it does.
>
> Any better ideas to solve this problem?
>
>
>
> [0] https://bugs.launchpad.net/neutron/+bug/1470612
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L54
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L75
> [3]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L156
> [4]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L85
> [5]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L78
> [6]
> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L293-L302
>
> On Wed, Jul 1, 2015 at 11:28 AM, Shraddha Pandhe <
> spandhe.openst...@gmail.com> wrote:
>
>> Hi,
>>
>> I had a discussion about this with Kevin Benton on IRC. Filed a bug:
>> https://bugs.launchpad.net/neutron/+bug/1470612
>>
>> Thanks!
>>
>>
>> On Wed, Jul 1, 2015 at 11:03 AM, Shraddha Pandhe <
>> spandhe.openst...@gmail.com> wrote:
>>
>>> Hi Shihan,
>>>
>>> I think the problem is slightly different. Does your patch take care of
>>> the scenario where a port was deleted  AFTER agent restart (not when agent
>>> was down)?
>>>
>>> My problem is that, when the agent restarts, it loses its previous
>>> network cache. As soon as the agent starts, as part of "__init__", it
>>> rebuilds that cache [1]. But it does not put the ports in there [2].
>>>
>>> In sync_state, Neutron tries to enable/disable networks, by checking the
>>> diff between Neutron's state and its own network cache that it just built
>>> [3]. It enables any NEW networks and disables any DELETED networks, but it
>>> does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
>>> remain empty lists.
>>>
>>> Now, if such a port is deleted, [4] will return None and the port will
>>> never get deleted from the config.
>>>
>>> [1]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
>>> [2]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
>>> [3]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
>>> [4]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>>>
>>>
>>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

I'm going to reply to several emails in this thread - but separately,
because they're from separate people and with separate POV, and I think it
will be even harder to discern what I'm saying if I merge the contexts
before replying... so bear with me ...


On Mon, Jul 27, 2015 at 1:36 PM Jim Rollenhagen 
wrote:

> Hi friends.
>
> Ironic implemented API "micro" versions in Kilo. We originally did this
> to allow for breaking changes in the API while allowing users to opt in
> to the breakage.
>
> Since then, we've had a "default version" for our client that we bump to
> something sensible with each release. Currently it is at 1.8.
> Negotiation is done with the server to figure out what is supported and
> adjust accordingly.
>
> Now we've landed a patch[0] with a new version (1.11) that is not
> backward compatible.


No, that patch isn't backwards compatible -- ** but it could be **.

That's the biggest reason that I disagree with what's proposed here -- it
would be trivially easy for us to make this change be backwards compatible
by allowing an optional parameter in the POST command that changes the
initial state of a node from AVAILABLE to ENROLL.

Allow users to opt-in to the new behavior *and* discover its presence from
the API version header. There is simply no reason for this to be a breaking
change. I simply do not understand how folks think "we can version the API"
means "we should break users even when we don't have to".

Anyway, I've said that before. There are other points I want to respond to
as well, so I'll carry on...



> It causes newly added Node objects to begin life in
> the ENROLL state, rather than AVAILABLE. This is a good thing, and
> people should want this! However, it is a breaking change. Automation
> that adds nodes to Ironic will need to do different things after the
> node-create call.
>
> Our API versioning scheme makes this opt-in (by specifying the API
> version). However, some folks have a problem with releasing this change
> as-is. The logic is that we might release a client that defaults to 1.11
> or higher, or the user may request 1.12 later to get a new feature, thus
> breaking their application that enrolls nodes.
>

The current approach is supposed to allow users "to make use of new
features as they become available, while also ensuring they don’t break due
to incompatibilities" [0] However, you're advocating against providing that
right now -- if a user wants a feature added in 1.12, they will be forced
to accept the breaking change in 1.11.

While I have proposed some changes to our specification for API versioning
[1], removing this statement of intent is not one of the changes I've
proposed.

[0]
http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#problem-description

[1]
https://review.openstack.org/#/c/196320/2/specs/devref/api-version-negotiation.rst,cm


>
> This is clearly backwards. Users should read release notes and be aware
> of what changes between versions in the API. Users need to be aware of
> the fact that our API is versioned, and use that to their advantage.
>

You're conflating "user" and "operator" -- which I understand, because you
are both. But not everyone is, and I'm concerned about the impact on "users
who are not operators". I'd say maybe we have none of those, except then I
hear from folks like Clint that they care about this sort of change and how
it affects them.


>
> It seems to me that the goal of the version negotiation in our client
> has been to pretend that our API versions don't exist, from a user
> perspective. We need to stop doing this and force users to think about
> what they are doing when they interact with our API.
>

The intent is to allow users' tooling to continue working while we evolve
the REST API *and* to give users the ability to work with both old and new
service installations (eg, because the user doesn't control what version of
server they are using).

Again, that goal is based on the assumption that some users are not also
operators.


>
> It seems to me we have a few options here:
>
> 1) Default the python client and CLI to the earliest supported version.
> This will never break users by default.
>
> 2) Default the python client and CLI to use the special version
> 'latest'. This will always use the latest API version, and always
> break people when a new server version (that is not backwards
> compatible) is deployed.
>

In an environment where a user is interacting with >1 Ironic service of
different versions, this default would lead to what I'll just call "odd"
behavior. It ends up being your option 4 implicitly, to avoid frustration.


>
> 3) Do what Nova does[1]. Default CLI to latest and python client to
> earliest. This assumes that CLI is typically used for one-time commands
> (and it isn't a big deal if we break a one-off command once), and the
> python client is used for applications.
>
> 4) Require a version to use the client at all. This would be a one-time
> brea

[openstack-dev] [puppet] Liberty support in Puppet modules: blocked by packaging

[Emilien Macchi]

Our current modules are officially supporting Kilo.
We would like to move our master branch forward to Liberty support but
since we rely on RDO/UCO packages [1] and RDO is AFIK not providing
'stable enough' liberty packages, we can't merge any feature that is
'liberty only', since we can't actually test it.

That's the current situation and we are working to get this solved as
soon as possible so we can go ahead.
I would ask our contributors to understand this situation and make their
patch work in progress when then break Kilo configuration.

Thanks,

[1]
http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/master-policy.html#proposed-change
---
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

On Mon, Jul 27, 2015 at 1:41 PM Sean Dague  wrote:

> Consider the CLI an auto negotiating microversion application of the
> python API client. And, realistically, should solve some of the issues
> of people running "nova foo" and getting cryptic errors from the server
> when they are hitting an old version of Nova that doesn't know how to foo.
>
> So the CLI should actually break less often, and will expose the most
> functionality you can get out of your cloud.
>
>
Not a lot to add here -- except to agree and say that the client breaking
in predictable and helpful ways (like giving a useful error message about a
feature not being available in an older service) is far better for users,
and easier for developers to implement with version headers than it was
before. And that's a win for users, IMO.

-Deva
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Andrew Woodward]

Keystone authtoken is also used by radosgw to validate users

On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward 
wrote:

> IIRC the puppet modules, and even the heat domain create script make use
> of the token straight from the config file. It not being present could
> cause problems for some of the manifests. We would need to ensure that
> their usage is minimized or removed.
>
> On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi Oleksiy,
>>
>> Good catch. Also OSTF should get endpoints from hiera as some plugins may
>> override the initial deployment settings. There may be cases when keystone
>> is detached by plugin.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov <
>> omolcha...@mirantis.com> wrote:
>>
>>> Hello all,
>>>
>>> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
>>> deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
>>> I guess not all of us have an access to this bug, so to be short:
>>>
>>> # A "shared secret" that can be used to bootstrap Keystone.
>>> # This "token" does not represent a user, and carries no
>>> # explicit authorization. To disable in production (highly
>>> # recommended), remove AdminTokenAuthMiddleware from your
>>> # paste application pipelines (for example, in keystone-
>>> # paste.ini). (string value)
>>>
>>> After removing this and testing we found out that OSTF fails because it
>>> uses admin token.
>>>
>>> What do you think if we create ostf user like for workloads, but with
>>> wider permissions?
>>>
>>> BR,
>>> Oleksiy.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> --
> Andrew Woodward
> Mirantis
> Fuel Community Ambassador
> Ceph Community
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

On Mon, Jul 27, 2015 at 4:58 PM Sean Dague  wrote:

> On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> >>> So the CLI should actually break less often, and will expose the most
> >>> functionality you can get out of your cloud.
> >>>
> >>
> >> What I find odd about this is that I want the CLI to be a faithful
> >> representation of the API, because many times the CLI is the only way I
> >> can access the API for integration purposes.
> >
> > "Faithful representation of the API" is an interesting way to put it; it
> > is a "faithful representation" either way. This way is a representation
> > of the newest state of the API. It sounds like you're expecting a
> > representation of the oldest state, or the state that you're used to
> > (the hardest to predict).
> >
> >>
> >> So lets say I just want a very simple bash script to do something with
> >> nodes:
> >>
> >> id=$(ironic node-create ...|getid)
> >> while true ; do
> >>   state=$(ironic node-get $id | get_state)
> >>   case $state in
> >>   AVAILABLE)
> >> break;;
> >>   ERROR)
> >> # retry or something
> >> ;;
> >>   *)
> >> splode("UNKNOWN STATE")
> >> ;;
> >>   esac
> >> done
> >>
> >> Then the script is going to start exploding with a CLI that shows me
> >> ENROLL state.
> >>
> >> So I'm not sure having the CLI go faster than the python client is a
> >> great way to avoid breakage. It might be the opposite of that, and that
> >> might just be a large burden on users.
> >
> > I tend to think that folks using the CLI for automation should be
> > pinning the version in that automation. A quick IRONIC_API_VERSION=1.8
> > or whatever would solve this problem. When new versions are available,
> > read the notes for that version and adjust your code as necessary. Or
> > just leave it at the same version until it breaks. :)
>
> Yeh, it's a cli, not a bash API. Having had to maintain devstack
> exercise code for a while, I'll tell you that the above is just a time
> bomb waiting to go off. None of the CLIs have that kind of contract, nor
> should they. Inflicting the bad UX of today on future generations
> because someone thinks, incorrectly, that it's a bash SDK is not a good
> trade off.
>
>
And people script against that CLI all. the. time.

Is it pretty? No. But is it something that people do? Yep.

Does that mean we should try to care? Yea, I think so, and I think that
means we should try to avoid breaking it when reasonably possible.


> If you want to pin things, explicitly, like jroll said, do that. And
> microversions lets you until your clouds uplift past your legacy code.
>

"if you want to pin the version" != "all users must explicitly specify the
version"

I believe Jim is advocating for the latter. I'm advocating for the former.


-Deva
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Kevin Benton]

After it starts back up and populates the cache, isn't that when it
generates all of the dnsmasq lease files? If so, why would it miss anything?

On Tue, Jul 28, 2015 at 1:14 PM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:

> Hi,
>
> I started working on this patch for bug [0], but it doesn't seem as
> straightforward as Kevin and I initially thought. Here's why:
>
> Initially we thought that a simple self.cache.push_port will work as
> follows:
>
> In __init__ [1], in _populate_network_cache [2], get all existing active
> networks from neutron using plugin_rpc similar to [3]. Then, for each of
> those networks, go through all the subnets and ports and add them in [4]
> before updating the cache.
>
> But I realized that this will not work because, if we try to get all
> active subnets and ports and populate those in cache, we may miss the
> delta. Consider following scenario:
>
> Cache state before agent stopped:
> networks 1
> subnets 4
> ports 10
>
> While the agent was down:
> networks 1
> subnets 6
> ports 12
>
> Now, then the agent comes back up, if we follow the above method, the
> network cache will immediately populate itself to the new state, without
> actually creating those subnets and ports in dhcp config. So if we want to
> follow this route, we need a mechanism to get known_subnet_ids and
> known_port_ids from dhcp driver, just like we get known_network_ids at [5]
> &[6]. To me, that seems too much work for what it does.
>
> Any better ideas to solve this problem?
>
>
>
> [0] https://bugs.launchpad.net/neutron/+bug/1470612
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L54
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L75
> [3]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L156
> [4]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L85
> [5]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L78
> [6]
> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L293-L302
>
> On Wed, Jul 1, 2015 at 11:28 AM, Shraddha Pandhe <
> spandhe.openst...@gmail.com> wrote:
>
>> Hi,
>>
>> I had a discussion about this with Kevin Benton on IRC. Filed a bug:
>> https://bugs.launchpad.net/neutron/+bug/1470612
>>
>> Thanks!
>>
>>
>> On Wed, Jul 1, 2015 at 11:03 AM, Shraddha Pandhe <
>> spandhe.openst...@gmail.com> wrote:
>>
>>> Hi Shihan,
>>>
>>> I think the problem is slightly different. Does your patch take care of
>>> the scenario where a port was deleted  AFTER agent restart (not when agent
>>> was down)?
>>>
>>> My problem is that, when the agent restarts, it loses its previous
>>> network cache. As soon as the agent starts, as part of "__init__", it
>>> rebuilds that cache [1]. But it does not put the ports in there [2].
>>>
>>> In sync_state, Neutron tries to enable/disable networks, by checking the
>>> diff between Neutron's state and its own network cache that it just built
>>> [3]. It enables any NEW networks and disables any DELETED networks, but it
>>> does nothing to PREVIOUSLY KNOWN NETWORKS. So those subnets and ports
>>> remain empty lists.
>>>
>>> Now, if such a port is deleted, [4] will return None and the port will
>>> never get deleted from the config.
>>>
>>> [1]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L68
>>> [2]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L79-L86
>>> [3]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L154-L171
>>> [4]
>>> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>>>
>>>
>>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

[Andrew Woodward]

I'm still confused are you wanting to add a container to the master node,
or a deployed env?

For the master node, the latest fuel-plugin-builder allows for post-install
scripts, you could load a container image from here
For nodes in a deployed ENV, there is no formal target to support
containers, you would need to install the container manager and containers
yourself.

However I would note that not packaging the applications dependencies
because it's in a container is not a good practice as it quickly becomes
very difficult to work with versioning and updates. It may be acceptable
for a dev build of the plugin, but should be avoided in validated versions
of the plugin. The container its self should also be contained within a
package so that it's versioning can be tracked with operator familiar
tools. Lastly, containers with python are quite large, so if you can get
the versioning to work I'd avoid putting it into a container all together
as you will end up with 150-300mb container mostly just because of python.

On Tue, Jul 28, 2015 at 7:26 AM Konstantin Danilov 
wrote:

> Evgene,
>
> I'm sure you understand this, but just to be clear - now FUEL uses
> containers on master node,
> not on cluster nodes. I'm asking about plugin containers on cluster nodes.
>
> Yep, there a particular example - VSM (Intel ceph management tool). It
> requires a set of packages,
> like python2.6, old django, etc, which I would rather not install on
> master node directly.
>
> Thanks
>
> On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L  wrote:
> > Hi Konstantin,
> >
> > I'm not sure if we track such feature anywhere. But one of the reasons
> > to use containers on the master was to deliver plugin specific
> containers,
> > so they don't intersect and don't break Fuel master dependencies.
> > Do you have some specific use case for that?
> >
> > Thanks,
> >
> > On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov <
> kdani...@mirantis.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> Is there a plans to allow plugin to be delivered as docker container
> >> images?
> >>
> >> Thanks
> >>
> >> --
> >> Kostiantyn Danilov aka koder.ua
> >> Principal software engineer, Mirantis
> >>
> >> skype:koder.ua
> >> http://koder-ua.blogspot.com/
> >> http://mirantis.com
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kostiantyn Danilov aka koder.ua
> Principal software engineer, Mirantis
>
> skype:koder.ua
> http://koder-ua.blogspot.com/
> http://mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

On Tue, Jul 28, 2015 at 1:01 AM Dmitry Tantsur  wrote:

> On 07/27/2015 10:41 PM, Sean Dague wrote:
> > On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
> >> Hi friends.
> >>
> >> Ironic implemented API "micro" versions in Kilo. We originally did this
> >> to allow for breaking changes in the API while allowing users to opt in
> >> to the breakage.
> >>
> >> Since then, we've had a "default version" for our client that we bump to
> >> something sensible with each release. Currently it is at 1.8.
> >> Negotiation is done with the server to figure out what is supported and
> >> adjust accordingly.
> >>
> >> Now we've landed a patch[0] with a new version (1.11) that is not
> >> backward compatible. It causes newly added Node objects to begin life in
> >> the ENROLL state, rather than AVAILABLE. This is a good thing, and
> >> people should want this! However, it is a breaking change. Automation
> >> that adds nodes to Ironic will need to do different things after the
> >> node-create call.
> >>
> >> Our API versioning scheme makes this opt-in (by specifying the API
> >> version). However, some folks have a problem with releasing this change
> >> as-is. The logic is that we might release a client that defaults to 1.11
> >> or higher, or the user may request 1.12 later to get a new feature, thus
> >> breaking their application that enrolls nodes.
> >>
> >> This is clearly backwards. Users should read release notes and be aware
> >> of what changes between versions in the API. Users need to be aware of
> >> the fact that our API is versioned, and use that to their advantage.
> >>
> >> It seems to me that the goal of the version negotiation in our client
> >> has been to pretend that our API versions don't exist, from a user
> >> perspective. We need to stop doing this and force users to think about
> >> what they are doing when they interact with our API.
> >>
> >> It seems to me we have a few options here:
> >>
> >> 1) Default the python client and CLI to the earliest supported version.
> >> This will never break users by default.
> >>
> >> 2) Default the python client and CLI to use the special version
> >> 'latest'. This will always use the latest API version, and always
> >> break people when a new server version (that is not backwards
> >> compatible) is deployed.
> >>
> >> 3) Do what Nova does[1]. Default CLI to latest and python client to
> >> earliest. This assumes that CLI is typically used for one-time commands
> >> (and it isn't a big deal if we break a one-off command once), and the
> >> python client is used for applications.
> >
> > Actually what Nova is doing is slight different than this, the CLI will
> > default to "latest" on the server. There will be an extra round trip to
> > figure out what that is. And the CLI will (long term) just not present
> > commands that aren't available at the server level you are talking to.
> >
> > Consider the CLI an auto negotiating microversion application of the
> > python API client. And, realistically, should solve some of the issues
> > of people running "nova foo" and getting cryptic errors from the server
> > when they are hitting an old version of Nova that doesn't know how to
> foo.
> >
> > So the CLI should actually break less often, and will expose the most
> > functionality you can get out of your cloud.
>
> What I find weird about this and similar approaches is that we treat CLI
> and any different from other ways to use API. And I *suspect* this is
> because we, the developers, use it the most and point newcomers to it.
> And I agree it's troublesome to explain that to use "manage" provision
> verb you have to provide --ironic-api-version 1.6. Or was 1.6 for
> inspect? Hmm, I really don't remember.
>
> CLI is not different, CLI is not special and CLI is not "an auto
> negotiating microversion application of the python API client". By
> saying any of these we just refusing it eat our dog's food. If we
> consciously believe (I personally don't) that versioning is the right
> thing to do for people using our API - lets stop dodging it ourselves.
> Otherwise it looks like we've invented an architecture that people
> presumably dream of, but we don't know if it's even usable (to say
> nothing about useful). I tried writing versioning-aware code for our
> devstack yesterday, and it wasn't that nice and shiny.
>
> If our versioning requires negotiations, lets have it on API level, so
> that all users get it. Actually, server has the same level of
> information as the client. Let's have "X-OpenStack-XXX-Version:
> negotiate" figure out a proper version for us - or refuse to process a
> request if it's not possible. And if we think that versioning as it is
> now is unusable at all, lets rework the whole idea.
>
> tl;dr my vote if for CLI to strictly follow whatever server API does.
> That is, default to the lowest version, require explicit version
> argument to get new features. (it's up to a follow up discussion what to
> do during the deprecation period).
>

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Jim Rollenhagen]

On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> On Mon, Jul 27, 2015 at 4:58 PM Sean Dague  wrote:
> 
> > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> > >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> > >>> So the CLI should actually break less often, and will expose the most
> > >>> functionality you can get out of your cloud.
> > >>>
> > >>
> > >> What I find odd about this is that I want the CLI to be a faithful
> > >> representation of the API, because many times the CLI is the only way I
> > >> can access the API for integration purposes.
> > >
> > > "Faithful representation of the API" is an interesting way to put it; it
> > > is a "faithful representation" either way. This way is a representation
> > > of the newest state of the API. It sounds like you're expecting a
> > > representation of the oldest state, or the state that you're used to
> > > (the hardest to predict).
> > >
> > >>
> > >> So lets say I just want a very simple bash script to do something with
> > >> nodes:
> > >>
> > >> id=$(ironic node-create ...|getid)
> > >> while true ; do
> > >>   state=$(ironic node-get $id | get_state)
> > >>   case $state in
> > >>   AVAILABLE)
> > >> break;;
> > >>   ERROR)
> > >> # retry or something
> > >> ;;
> > >>   *)
> > >> splode("UNKNOWN STATE")
> > >> ;;
> > >>   esac
> > >> done
> > >>
> > >> Then the script is going to start exploding with a CLI that shows me
> > >> ENROLL state.
> > >>
> > >> So I'm not sure having the CLI go faster than the python client is a
> > >> great way to avoid breakage. It might be the opposite of that, and that
> > >> might just be a large burden on users.
> > >
> > > I tend to think that folks using the CLI for automation should be
> > > pinning the version in that automation. A quick IRONIC_API_VERSION=1.8
> > > or whatever would solve this problem. When new versions are available,
> > > read the notes for that version and adjust your code as necessary. Or
> > > just leave it at the same version until it breaks. :)
> >
> > Yeh, it's a cli, not a bash API. Having had to maintain devstack
> > exercise code for a while, I'll tell you that the above is just a time
> > bomb waiting to go off. None of the CLIs have that kind of contract, nor
> > should they. Inflicting the bad UX of today on future generations
> > because someone thinks, incorrectly, that it's a bash SDK is not a good
> > trade off.
> >
> >
> And people script against that CLI all. the. time.
> 
> Is it pretty? No. But is it something that people do? Yep.
> 
> Does that mean we should try to care? Yea, I think so, and I think that
> means we should try to avoid breaking it when reasonably possible.
> 
> 
> > If you want to pin things, explicitly, like jroll said, do that. And
> > microversions lets you until your clouds uplift past your legacy code.
> >
> 
> "if you want to pin the version" != "all users must explicitly specify the
> version"
> 
> I believe Jim is advocating for the latter. I'm advocating for the former.

The problem that I'm now seeing is you're advocating not just that
people should be able to pin a version. You're advocating for:

1. People don't need to pin the version. Fine.
   1.1. Side note: perhaps you're actually advocating for "people should
not need to pin the version"? It's starting to sound that way.
2. The client should always default to the most recent compatible
  version. Fine.
3. We should never break a user. Fine.
4. 1-3 must all be true always. Not fine.

We can't reasonably make progress while having the latest API version be
compatible with the previous API version. The combination above breaks
down when we also want to continue to produce software (preferably
quickly). We need to let one of those things go; they can't all be true
at the same time.

I think the best thing to let go is 1 or 2, personally. Where we are
today is letting 3 go, and that's why we're stuck here.

// jim

> 
> 
> -Deva

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Sergii Golovatiuk]

Why can't radosgw use own own credentials? If it's technical debt we need
to put it on plate to address in next release.


--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward  wrote:

> Keystone authtoken is also used by radosgw to validate users
>
> On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward 
> wrote:
>
>> IIRC the puppet modules, and even the heat domain create script make use
>> of the token straight from the config file. It not being present could
>> cause problems for some of the manifests. We would need to ensure that
>> their usage is minimized or removed.
>>
>> On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Hi Oleksiy,
>>>
>>> Good catch. Also OSTF should get endpoints from hiera as some plugins
>>> may override the initial deployment settings. There may be cases when
>>> keystone is detached by plugin.
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov <
>>> omolcha...@mirantis.com> wrote:
>>>
 Hello all,

 We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
 deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
 I guess not all of us have an access to this bug, so to be short:

 # A "shared secret" that can be used to bootstrap Keystone.
 # This "token" does not represent a user, and carries no
 # explicit authorization. To disable in production (highly
 # recommended), remove AdminTokenAuthMiddleware from your
 # paste application pipelines (for example, in keystone-
 # paste.ini). (string value)

 After removing this and testing we found out that OSTF fails because it
 uses admin token.

 What do you think if we create ostf user like for workloads, but with
 wider permissions?

 BR,
 Oleksiy.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> --
>> Andrew Woodward
>> Mirantis
>> Fuel Community Ambassador
>> Ceph Community
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen 
wrote:

> On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague  wrote:
> >
> > > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> > > >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> > > >>> So the CLI should actually break less often, and will expose the
> most
> > > >>> functionality you can get out of your cloud.
> > > >>>
> > > >>
> > > >> What I find odd about this is that I want the CLI to be a faithful
> > > >> representation of the API, because many times the CLI is the only
> way I
> > > >> can access the API for integration purposes.
> > > >
> > > > "Faithful representation of the API" is an interesting way to put
> it; it
> > > > is a "faithful representation" either way. This way is a
> representation
> > > > of the newest state of the API. It sounds like you're expecting a
> > > > representation of the oldest state, or the state that you're used to
> > > > (the hardest to predict).
> > > >
> > > >>
> > > >> So lets say I just want a very simple bash script to do something
> with
> > > >> nodes:
> > > >>
> > > >> id=$(ironic node-create ...|getid)
> > > >> while true ; do
> > > >>   state=$(ironic node-get $id | get_state)
> > > >>   case $state in
> > > >>   AVAILABLE)
> > > >> break;;
> > > >>   ERROR)
> > > >> # retry or something
> > > >> ;;
> > > >>   *)
> > > >> splode("UNKNOWN STATE")
> > > >> ;;
> > > >>   esac
> > > >> done
> > > >>
> > > >> Then the script is going to start exploding with a CLI that shows me
> > > >> ENROLL state.
> > > >>
> > > >> So I'm not sure having the CLI go faster than the python client is a
> > > >> great way to avoid breakage. It might be the opposite of that, and
> that
> > > >> might just be a large burden on users.
> > > >
> > > > I tend to think that folks using the CLI for automation should be
> > > > pinning the version in that automation. A quick
> IRONIC_API_VERSION=1.8
> > > > or whatever would solve this problem. When new versions are
> available,
> > > > read the notes for that version and adjust your code as necessary. Or
> > > > just leave it at the same version until it breaks. :)
> > >
> > > Yeh, it's a cli, not a bash API. Having had to maintain devstack
> > > exercise code for a while, I'll tell you that the above is just a time
> > > bomb waiting to go off. None of the CLIs have that kind of contract,
> nor
> > > should they. Inflicting the bad UX of today on future generations
> > > because someone thinks, incorrectly, that it's a bash SDK is not a good
> > > trade off.
> > >
> > >
> > And people script against that CLI all. the. time.
> >
> > Is it pretty? No. But is it something that people do? Yep.
> >
> > Does that mean we should try to care? Yea, I think so, and I think that
> > means we should try to avoid breaking it when reasonably possible.
> >
> >
> > > If you want to pin things, explicitly, like jroll said, do that. And
> > > microversions lets you until your clouds uplift past your legacy code.
> > >
> >
> > "if you want to pin the version" != "all users must explicitly specify
> the
> > version"
> >
> > I believe Jim is advocating for the latter. I'm advocating for the
> former.
>
> The problem that I'm now seeing is you're advocating not just that
> people should be able to pin a version. You're advocating for:
>
> 1. People don't need to pin the version. Fine.
>1.1. Side note: perhaps you're actually advocating for "people should
> not need to pin the version"? It's starting to sound that way.
> 2. The client should always default to the most recent compatible
>   version. Fine.
> 3. We should never break a user. Fine.
> 4. 1-3 must all be true always. Not fine.
>
> We can't reasonably make progress while having the latest API version be
> compatible with the previous API version. The combination above breaks
> down when we also want to continue to produce software (preferably
> quickly). We need to let one of those things go; they can't all be true
> at the same time.
>
> I think the best thing to let go is 1 or 2, personally. Where we are
> today is letting 3 go, and that's why we're stuck here.
>
>
Mmmm, close. I think I expanded on that in my last email (replying to
Dmitry) ... but... tldr;

1. yes
2. no -- the client should default to the minimum supported version. We got
that wrong previously, and that's what is hurting us now.
3. not quite -- we should be very intentional when ever we're going to
break a user AND we should only do it when there is no other option AND we
must provide a lot of warning and deprecation period.

-Deva



> // jim
>
> >
> >
> > -Deva
>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Andrew Woodward]

It's literally how radosgw goes about verifying users, it has no scheme of
using a user or working with auth-tokens. It would have to fixed in the
ceph-radosgw codebase. PKI tokens (which we don't use) rely on this less,
but its still used.

On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk 
wrote:

> Why can't radosgw use own own credentials? If it's technical debt we need
> to put it on plate to address in next release.
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward 
> wrote:
>
>> Keystone authtoken is also used by radosgw to validate users
>>
>> On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward 
>> wrote:
>>
>>> IIRC the puppet modules, and even the heat domain create script make use
>>> of the token straight from the config file. It not being present could
>>> cause problems for some of the manifests. We would need to ensure that
>>> their usage is minimized or removed.
>>>
>>> On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
 Hi Oleksiy,

 Good catch. Also OSTF should get endpoints from hiera as some plugins
 may override the initial deployment settings. There may be cases when
 keystone is detached by plugin.

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov <
 omolcha...@mirantis.com> wrote:

> Hello all,
>
> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
> deployment. This came from
> https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us
> have an access to this bug, so to be short:
>
> # A "shared secret" that can be used to bootstrap Keystone.
> # This "token" does not represent a user, and carries no
> # explicit authorization. To disable in production (highly
> # recommended), remove AdminTokenAuthMiddleware from your
> # paste application pipelines (for example, in keystone-
> # paste.ini). (string value)
>
> After removing this and testing we found out that OSTF fails because
> it uses admin token.
>
> What do you think if we create ostf user like for workloads, but with
> wider permissions?
>
> BR,
> Oleksiy.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>> --
>>> --
>>> Andrew Woodward
>>> Mirantis
>>> Fuel Community Ambassador
>>> Ceph Community
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>>
>> --
>>
>> Andrew Woodward
>>
>> Mirantis
>>
>> Fuel Community Ambassador
>>
>> Ceph Community
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Sergii Golovatiuk]

Hi,

Let's ask our Ceph developers how much time/resources they need to
implement such functionality.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Jul 28, 2015 at 11:21 PM, Andrew Woodward 
wrote:

> It's literally how radosgw goes about verifying users, it has no scheme of
> using a user or working with auth-tokens. It would have to fixed in the
> ceph-radosgw codebase. PKI tokens (which we don't use) rely on this less,
> but its still used.
>
> On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Why can't radosgw use own own credentials? If it's technical debt we need
>> to put it on plate to address in next release.
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward 
>> wrote:
>>
>>> Keystone authtoken is also used by radosgw to validate users
>>>
>>> On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward 
>>> wrote:
>>>
 IIRC the puppet modules, and even the heat domain create script make
 use of the token straight from the config file. It not being present could
 cause problems for some of the manifests. We would need to ensure that
 their usage is minimized or removed.

 On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk <
 sgolovat...@mirantis.com> wrote:

> Hi Oleksiy,
>
> Good catch. Also OSTF should get endpoints from hiera as some plugins
> may override the initial deployment settings. There may be cases when
> keystone is detached by plugin.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov <
> omolcha...@mirantis.com> wrote:
>
>> Hello all,
>>
>> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
>> deployment. This came from
>> https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us
>> have an access to this bug, so to be short:
>>
>> # A "shared secret" that can be used to bootstrap Keystone.
>> # This "token" does not represent a user, and carries no
>> # explicit authorization. To disable in production (highly
>> # recommended), remove AdminTokenAuthMiddleware from your
>> # paste application pipelines (for example, in keystone-
>> # paste.ini). (string value)
>>
>> After removing this and testing we found out that OSTF fails because
>> it uses admin token.
>>
>> What do you think if we create ostf user like for workloads, but with
>> wider permissions?
>>
>> BR,
>> Oleksiy.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
 --
 --
 Andrew Woodward
 Mirantis
 Fuel Community Ambassador
 Ceph Community

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>> --
>>>
>>> --
>>>
>>> Andrew Woodward
>>>
>>> Mirantis
>>>
>>> Fuel Community Ambassador
>>>
>>> Ceph Community
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> --
> Andrew Woodward
> Mirantis
> Fuel Community Ambassador
> Ceph Community
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Jim Rollenhagen]

On Tue, Jul 28, 2015 at 08:05:49PM +, Devananda van der Veen wrote:
> I'm going to reply to several emails in this thread - but separately,
> because they're from separate people and with separate POV, and I think it
> will be even harder to discern what I'm saying if I merge the contexts
> before replying... so bear with me ...
> 
> 
> On Mon, Jul 27, 2015 at 1:36 PM Jim Rollenhagen 
> wrote:
> 
> > Hi friends.
> >
> > Ironic implemented API "micro" versions in Kilo. We originally did this
> > to allow for breaking changes in the API while allowing users to opt in
> > to the breakage.
> >
> > Since then, we've had a "default version" for our client that we bump to
> > something sensible with each release. Currently it is at 1.8.
> > Negotiation is done with the server to figure out what is supported and
> > adjust accordingly.
> >
> > Now we've landed a patch[0] with a new version (1.11) that is not
> > backward compatible.
> 
> 
> No, that patch isn't backwards compatible -- ** but it could be **.
> 
> That's the biggest reason that I disagree with what's proposed here -- it
> would be trivially easy for us to make this change be backwards compatible
> by allowing an optional parameter in the POST command that changes the
> initial state of a node from AVAILABLE to ENROLL.
> 
> Allow users to opt-in to the new behavior *and* discover its presence from
> the API version header. There is simply no reason for this to be a breaking
> change. I simply do not understand how folks think "we can version the API"
> means "we should break users even when we don't have to".

I tend to think specifying that version *is* opting in.

> 
> Anyway, I've said that before. There are other points I want to respond to
> as well, so I'll carry on...
> 
> 
> 
> > It causes newly added Node objects to begin life in
> > the ENROLL state, rather than AVAILABLE. This is a good thing, and
> > people should want this! However, it is a breaking change. Automation
> > that adds nodes to Ironic will need to do different things after the
> > node-create call.
> >
> > Our API versioning scheme makes this opt-in (by specifying the API
> > version). However, some folks have a problem with releasing this change
> > as-is. The logic is that we might release a client that defaults to 1.11
> > or higher, or the user may request 1.12 later to get a new feature, thus
> > breaking their application that enrolls nodes.
> >
> 
> The current approach is supposed to allow users "to make use of new
> features as they become available, while also ensuring they don’t break due
> to incompatibilities" [0] However, you're advocating against providing that
> right now -- if a user wants a feature added in 1.12, they will be forced
> to accept the breaking change in 1.11.

I believe stating that users won't put in work to make their software
work with the breaking change in 1.11, but will put in work to use a
feature in 1.12, is a bit of a logical fallacy. However, even if someone
gets themselves into that situation, there's nothing wrong with them
using <1.11 for the call that breaks them, and 1.12 for the others.

> 
> While I have proposed some changes to our specification for API versioning
> [1], removing this statement of intent is not one of the changes I've
> proposed.
> 
> [0]
> http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html#problem-description
> 
> [1]
> https://review.openstack.org/#/c/196320/2/specs/devref/api-version-negotiation.rst,cm
> 
> 
> >
> > This is clearly backwards. Users should read release notes and be aware
> > of what changes between versions in the API. Users need to be aware of
> > the fact that our API is versioned, and use that to their advantage.
> >
> 
> You're conflating "user" and "operator" -- which I understand, because you
> are both. But not everyone is, and I'm concerned about the impact on "users
> who are not operators". I'd say maybe we have none of those, except then I
> hear from folks like Clint that they care about this sort of change and how
> it affects them.

In an admin-only API, I tend to think operators and users are very
close, if not the same.

I also think that:

1) API version things, especially incompatibilities, should also be in
   the release notes for the client.
2) Operators should be distributing release notes that affect users to
   the users. When I deploy a new version of Ironic, I certainly
   distribute a note with any changes other users/operators should be
   aware of.

> 
> 
> >
> > It seems to me that the goal of the version negotiation in our client
> > has been to pretend that our API versions don't exist, from a user
> > perspective. We need to stop doing this and force users to think about
> > what they are doing when they interact with our API.
> >
> 
> The intent is to allow users' tooling to continue working while we evolve
> the REST API *and* to give users the ability to work with both old and new
> service installations (eg, because t

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Jim Rollenhagen]

On Tue, Jul 28, 2015 at 09:19:46PM +, Devananda van der Veen wrote:
> On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen 
> wrote:
> 
> > On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> > > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague  wrote:
> > >
> > > > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > > > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> > > > >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> > > > >>> So the CLI should actually break less often, and will expose the
> > most
> > > > >>> functionality you can get out of your cloud.
> > > > >>>
> > > > >>
> > > > >> What I find odd about this is that I want the CLI to be a faithful
> > > > >> representation of the API, because many times the CLI is the only
> > way I
> > > > >> can access the API for integration purposes.
> > > > >
> > > > > "Faithful representation of the API" is an interesting way to put
> > it; it
> > > > > is a "faithful representation" either way. This way is a
> > representation
> > > > > of the newest state of the API. It sounds like you're expecting a
> > > > > representation of the oldest state, or the state that you're used to
> > > > > (the hardest to predict).
> > > > >
> > > > >>
> > > > >> So lets say I just want a very simple bash script to do something
> > with
> > > > >> nodes:
> > > > >>
> > > > >> id=$(ironic node-create ...|getid)
> > > > >> while true ; do
> > > > >>   state=$(ironic node-get $id | get_state)
> > > > >>   case $state in
> > > > >>   AVAILABLE)
> > > > >> break;;
> > > > >>   ERROR)
> > > > >> # retry or something
> > > > >> ;;
> > > > >>   *)
> > > > >> splode("UNKNOWN STATE")
> > > > >> ;;
> > > > >>   esac
> > > > >> done
> > > > >>
> > > > >> Then the script is going to start exploding with a CLI that shows me
> > > > >> ENROLL state.
> > > > >>
> > > > >> So I'm not sure having the CLI go faster than the python client is a
> > > > >> great way to avoid breakage. It might be the opposite of that, and
> > that
> > > > >> might just be a large burden on users.
> > > > >
> > > > > I tend to think that folks using the CLI for automation should be
> > > > > pinning the version in that automation. A quick
> > IRONIC_API_VERSION=1.8
> > > > > or whatever would solve this problem. When new versions are
> > available,
> > > > > read the notes for that version and adjust your code as necessary. Or
> > > > > just leave it at the same version until it breaks. :)
> > > >
> > > > Yeh, it's a cli, not a bash API. Having had to maintain devstack
> > > > exercise code for a while, I'll tell you that the above is just a time
> > > > bomb waiting to go off. None of the CLIs have that kind of contract,
> > nor
> > > > should they. Inflicting the bad UX of today on future generations
> > > > because someone thinks, incorrectly, that it's a bash SDK is not a good
> > > > trade off.
> > > >
> > > >
> > > And people script against that CLI all. the. time.
> > >
> > > Is it pretty? No. But is it something that people do? Yep.
> > >
> > > Does that mean we should try to care? Yea, I think so, and I think that
> > > means we should try to avoid breaking it when reasonably possible.
> > >
> > >
> > > > If you want to pin things, explicitly, like jroll said, do that. And
> > > > microversions lets you until your clouds uplift past your legacy code.
> > > >
> > >
> > > "if you want to pin the version" != "all users must explicitly specify
> > the
> > > version"
> > >
> > > I believe Jim is advocating for the latter. I'm advocating for the
> > former.
> >
> > The problem that I'm now seeing is you're advocating not just that
> > people should be able to pin a version. You're advocating for:
> >
> > 1. People don't need to pin the version. Fine.
> >1.1. Side note: perhaps you're actually advocating for "people should
> > not need to pin the version"? It's starting to sound that way.
> > 2. The client should always default to the most recent compatible
> >   version. Fine.
> > 3. We should never break a user. Fine.
> > 4. 1-3 must all be true always. Not fine.
> >
> > We can't reasonably make progress while having the latest API version be
> > compatible with the previous API version. The combination above breaks
> > down when we also want to continue to produce software (preferably
> > quickly). We need to let one of those things go; they can't all be true
> > at the same time.
> >
> > I think the best thing to let go is 1 or 2, personally. Where we are
> > today is letting 3 go, and that's why we're stuck here.
> >
> >
> Mmmm, close. I think I expanded on that in my last email (replying to
> Dmitry) ... but... tldr;
> 
> 1. yes
> 2. no -- the client should default to the minimum supported version. We got
> that wrong previously, and that's what is hurting us now.

So if we do this, simply shipping the code doesn't break anyone. Nobody
has disagreed on this yet, best I can tell.

So let's ship some code. :)

// jim

> 3.

Re: [openstack-dev] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Sean M. Collins]

All,

My suggestion was as follows:

>  I'd say maybe an e-mail to the ML, with the results of this 
> meeting, and say that we want to try and converge where
> there is commonality

I think there is overlap between the two APIs. Let's keep collaborating
on both the networking-sfc and packet forwarding APIs, to see where we
have commonality. I think Cathy's initial e-mail may have ruffled
feathers - and I'd like to smooth them out again. I think the statement
"we only need one API" is far too premature.

Let's play nice with the other API proposals, yes?


-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights

[Znoinski, Waldemar]

Hi Kyle, Neutron Cores and Infra Team,


a)  Was there a final decision/conclusion on the matter?

b)  Do we make jodavidg’s suggestion[1] a rule and we change it in Neutron 
third party policy[2].

c)   I can’t see any recent changes in policy[2] and if there are no plans 
to change the guidelines on how/whether to get voting rights Infra please 
continue with the setup of the voting rights for Intel Networking CI. I’ll 
disable -1 voting depending on b).

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068202.html
[2] 
http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/thirdparty-ci.rst


From: Znoinski, Waldemar
Sent: Friday, June 26, 2015 9:58 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: RE: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating 
intel-networking-ci for voting rights

Thanks Kyle.

Yes, I’d wait with further processing of this request till we have a consensus 
on the thread.

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Thursday, June 25, 2015 8:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating 
intel-networking-ci for voting rights

On Wed, Jun 24, 2015 at 12:22 PM, Znoinski, Waldemar 
mailto:waldemar.znoin...@intel.com>> wrote:
Hi Kyle and Neutron Cores,

I would like to nominate Intel-Networking-CI 
(https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-Networking-CI) to have 
voting (non-gating) rights.
It’s been commenting on each proposed patch-set in Neutron since Feb 10 ’15: 
https://review.openstack.org/#/q/reviewer:%22Intel+Networking+CI+%253Copenstack-networking-ci%2540intel.com%253E%22,n,00333e9b0002530a
Any issues with it were resolved within 1-2 working days.

A recent cut from history – although a full one is at 
https://review.openstack.org/#/q/reviewer:%22Intel+Networking+CI+%253Copenstack-networking-ci%2540intel.com%253E%22,n,z
 :

https://review.openstack.org/#/c/194441/ - 
http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/41/194441/6/
https://review.openstack.org/#/c/173001/ - 
http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/01/173001/14/
https://review.openstack.org/#/c/195218/ - 
http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/18/195218/1/
https://review.openstack.org/#/c/194455/ - 
http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/55/194455/4/
https://review.openstack.org/#/c/195045/ - 
http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/45/195045/1/

Let me know if there are any other requirements we should be fulfilling and/or 
approve if no questions.



+1 from me. See the recent thread [1] about this topic, however, and decide if 
you really want to vote or not.
Thanks!
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067992.html

Waldek


--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev