date:20150818

Note for myself: do not take a day off before Cross-project meeting so I
can send the agenda on time :-)

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

We'll have a cross-project meeting today at 21:00 UTC, with the
following agenda:

* Team announcements (horizontal, vertical, diagonal)
* How to generate .Z version increments on stable/liberty commits
* How to autogenerate release notes on stable/liberty commits
* Return request ID to caller
* Open discussion

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
-- 
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] [TripleO] Encapsulating logic and state in the client

2015-08-18 Thread Zane Bitter


On 18/08/15 02:33, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2015-08-17 09:25:36 -0700:

It occurs to me that there has never been a detailed exposition of the
purpose of the tripleo-common library here, and that this might be a
good time to rectify that.

Basically, there are two things that it sucks to have in the client:

First, logic - that is, any code that is not related to the core client
functionality of taking input from the user, making ReST API calls, and
returning output to the user. This sucks because anyone needing to
connect to a ReST API using a language other than Python has to
reimplement the logic in their own language. It also creates potential
versioning issues, because there's nothing to guarantee that the client
code and anything it interacts with on the server are kept in sync.

Secondly, state. This sucks because the state is contained in a user's
individual session, which not only causes all sorts of difficulties for
anyone trying to implement a web UI but also means that you're at risk
of losing some state if you e.g. accidentally Ctrl-C the CLI client.

Unfortunately, as undesirable as these are, they're sometimes necessary
in the world we currently live in. The only long-term solution to this
is to put all of the logic and state behind a ReST API where it can be
accessed from any language, and where any state can be stored
appropriately, possibly in a database. In principle that could be
accomplished either by creating a tripleo-specific ReST API, or by
finding native OpenStack undercloud APIs to do everything we need. My
guess is that we'll find a use for the former before everything is ready
for the latter, but that's a discussion for another day. We're not there
yet, but there are things we can do to keep our options open to make
that transition in the future, and this is where tripleo-common comes in.

I submit that anything that adds logic or state to the client should be
implemented in the tripleo-common library instead of the client plugin.
This offers a couple of advantages:

- It provides a defined boundary between code that is CLI-specific and
code that is shared between the CLI and GUI, which could become the
model for a future ReST API once it has stabilised and we're ready to
take that step.
- It allows for an orderly transition when that happens - we can have a
deprecation period during which the tripleo-common library is imported
into both the client and the (future, hypothetical) ReST API.



I agree with most everything you've said above. But as someone mostly
disconnected from TripleO for the last 6 months, I have no idea what
you're talking about, specifically. Can you provide a specific example?


I can provide a specific example of what's in tripleo-common today: the 
workflow which drives package updates on the overcloud nodes. It works 
by kicking off a Heat stack-update and using hooks/breakpoints to 
shepherd it through the correct workflow - so this incorporates both 
logic and state.


In terms of what additional stuff might be added in the future, I was 
intentionally being somewhat generic in the hope that people would 
recognise their own situation in this description rather than try to 
predict what changes people might want to make in the future. I can 
imagine something like additional verification of input parameters (i.e. 
verifying them in combination, in a way that is application-specific and 
therefore cannot be done by Heat) would be an example we might hit.


cheers,
Zane.

__
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] [tripleo] Upgrades, Releases Branches

2015-08-18 Thread Zane Bitter


On 17/08/15 15:29, James Slagle wrote:


I'd like propose we take a somewhat modified release branch approach,
which combines many of the advantages of the stable-branch model, but
allows for a somewhat more liberal approach to backports, where most things
are considered valid backports provided they work with the currently
released OpenStack services (e.g right now, a t-h-t release/kilo branch
would have to maintain compatibility with a kilo Heat in the undercloud)

I like the idea, it seems reasonable to me.

I do think we should clarify if the rule is:

We*can*  backport anything to release/kilo that doesn't break
compatibility with kilo Heat.

Or:

We*must*  backport anything to release/kilo that doesn't break
compatibility with kilo Heat.


I think of it like this: there are theoretically 4 potential models for 
how to combine TripleO and OpenStack:


1) trunk TripleO deploys trunk OpenStack
2) trunk TripleO deploys stable OpenStack
3) stable TripleO deploys trunk OpenStack
4) stable TripleO deploys stable OpenStack

(You could double the size of this list by assuming a user was willing 
to use a different version of OpenStack in the undercloud than they're 
installing in the overcloud. However, I believe we are working on the 
assumption that they are not.)


To date, TripleO has supported only (1). This is a proposal to support 
(2). I'll hazard a guess that nobody cares about (3) right now. This is 
explicitly *not* a proposal to support (4) - i.e. it is not a stable/ 
branch (we'll continue to leave that job to downstream distros).


So we should think of this as a development branch that allows users to 
consume the latest TripleO features without breaking compatibility with 
the stable OpenStack packages. So, in RFC2119 terms, I believe the 
correct policy is we SHOULD backport anything to release/kilo (or 
whatever we call it) that doesn't break compatibility with kilo OpenStack.


cheers,
Zane.

__
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][bgpvpn] Service Plugin vs Service driver

2015-08-18 Thread Mathieu Rohon

Adding the related subject :)

On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon mathieu.ro...@gmail.com
wrote:

 Hi all,

 The current bgpvpn implementation is using the service type framework,
 with a service plugin and one or more service providers.

 After registering the bug [1], I wonder if we would rather use a service
 plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which
 handles API calls, instead of having one service plugin which forwards API
 calls to a service driver depending on the provider chosen by the end
 user.

 I would like to better understand what would be the main drawbacks of such
 a move apart from the fact that a deployment would be tightly coupled to a
 bgpvpn plugin, and multiple implementations of the plugin couldn't coexist.

 Thanks,

 Mathieu

 [1]https://bugs.launchpad.net/bgpvpn/+bug/1485515

__
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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-18 Thread Timur Sufiev

IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity-Users, since most likely production-grade OpenStack installations
will have LDAP instead of MySQL storage. So I'm for gathering more
operators/deployers feedback on the pagination (Users panel particularly).

I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but because
LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of course,
'unavoidable' thing is open to discussion.

On Tue, Aug 18, 2015 at 6:30 AM Adam Young ayo...@redhat.com wrote:

On 08/17/2015 09:53 PM, David Lyle wrote:

I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3 API. Since
this is purely a keystone construct it seems implausible to me that ldap or
the IdP of choice would be limiting the ability to return a paginated list
of all projects. Or groups or domains or roles for that matter.

Yeah, SQL can support it. LDAP assignment can't. But that is not going
to have a long life.

With Hierarchical projects, we'll probably also have to keep nesting in
mind for how we display a project list: do we always show a flat list, or
is a tree closer to what users expect?

Both are going to work poorly for some deployments and work well for
others.

There is no reason to punt on pagination across the API for one resource
type, which actually would also work with select backends. Give me
something that I can exhaustively list in the API I can build from.

David
On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov wrote:

1. yes, but probably only if its a short list. It may be feasible to show
it only if there are 5 or less pages, and maybe just load all pages of data
and paginate it on the client. If too big, ask the user to refine their
search? Or always paginate to 5, and then the 6th page have a page
requesting further refinement?

2. Not sure what the difference between searching and filtering is in
this context? something like facets? If so, probably the 5 or less thing
would work here too.

3. Yes, but again, probably within a smaller set of pages?

Thanks,
Kevin

From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
Sent: Sunday, August 16, 2015 9:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
for Identity dashboard entities

I like Michael’s response because it moved the thread towards identifying
actual user needs before digging into the technical feasibility. IMHO, it
would be helpful to have a few people on the list answer his questions:

1 - Do users want to page through search results?

2 - Do users want to page through filter results? (do they use filter
results?)

3 - If they want to page, do they want to be able to go back a page
and/or know their current page?

I understand that even if we answer “yes” to all three questions that
there could be issues around implementation, but at least we’ll know a gap
exists.

Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

For every complex problem, there is a solution that is simple, neat and
wrong.”

H L Menken

__
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:unsubscribehttp://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] [Tacker][NFV] No weekly IRC meeting this week

2015-08-18 Thread Sridhar Ramaswamy

Heads up.

Tacker team is holding a Liberty mid-cycle meetup this week [1]. Hence we
are cancelling our weekly IRC meeting this week on Aug 20th. The meeting
will resume next week (on Aug 27th).

[1] https://etherpad.openstack.org/p/liberty-tacker-midcycle
__
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][bgpvpn] Service Plugin vs Service driver

2015-08-18 Thread Brandon Logan

?So let me make sure I understand this. You want to do a separate service 
plugin for what would normally be separate drivers under one service plugin.  
The reasons for this are:


1. You dont want users the ability to choose the type, you want it always to be 
the same one

2. Some types do want to be the source of truth of the data stored, instead of 
it being the service plugin database.


First, let me address the possibility of a solution using one service plugin 
and multiple drivers per type:


I think that you can overcome #1 in the instantiation of the service plugin to 
check if there are more than 1 provider active, if so you can just throw an 
exception saying you can only have 1.  I'd have to look at it more to see if 
there are any caveats to this, but I think that would work.


For #2, assuming #1 works, then the drivers that are defined can have some 
boolean that they set that will tell the plugin whether they are the source of 
truth or not, and depending on that you can store the data in the service 
plugin's db or just pass the data along, also pass GET requests to the drivers 
as well.


As for making a service plugin for each type, I don't see why that wouldn't 
work.  It seems a bit overkill to me though because you'd probably end up 
having 2 base classes for every service plugin type, one for using the service 
plugin database and another for the data source of truth being external.  
Probably a better way to do this, I'm sure I'm oversimplifying.  I don't see 
much technical reasons why you couldn't do this, though.  It's just 
inconsistent and might cause some confusion.  I'd need to spend some time on it 
to really have an educated opinion.


Thanks,
Brandon


From: Mathieu Rohon mathieu.ro...@gmail.com
Sent: Tuesday, August 18, 2015 7:13 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

Adding the related subject :)

On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon 
mathieu.ro...@gmail.commailto:mathieu.ro...@gmail.com wrote:
Hi all,

The current bgpvpn implementation is using the service type framework, with a 
service plugin and one or more service providers.

After registering the bug [1], I wonder if we would rather use a service plugin 
per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which handles 
API calls, instead of having one service plugin which forwards API calls to a 
service driver depending on the provider chosen by the end user.

I would like to better understand what would be the main drawbacks of such a 
move apart from the fact that a deployment would be tightly coupled to a bgpvpn 
plugin, and multiple implementations of the plugin couldn't coexist.

Thanks,

Mathieu

[1]https://bugs.launchpad.net/bgpvpn/+bug/1485515

__
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] New API for node create, specifying initial provision state

Hi,

I want to start a different thread on this topic because I don't think this
is about whether/how to do API microversions. Rather, given that we are
going to support microversioning, how to deal with the non-backward
compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
being the provision state that a node is in, after being created/registered
in ironic.

(This was from 'Let's talk about API versions,
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html.)

I want to think about this before replying but others are more than welcome
to reply first so that I may not feel the need to reply :-)

--ruby
maybe chop off this and above when replying :-)

On 17 August 2015 at 20:20, Robert Collins robe...@robertcollins.net
wrote:

 On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com wrote:
  Hi, sorry for the delay. I vote no. I understand the rationale of trying
 to
  do things so that we don't break our users but that's what the
 versioning is
  meant for and more importantly -- I think adding the ENROLL state is
 fairly
  important wrt the lifecycle of a node. I don't particularly want to hide
  that and/or let folks opt out of it in the long term.
 
  From a reviewer point-of-view, my concern is me trying to remember all
 the
  possible permutations/states etc that are possible to make sure that new
  code doesn't break existing behavior. I haven't thought out whether
 adding
  this new API would make that worse or not, but then, I don't really want
 to
  have to think about it. So KISS as much as we can! :)

 I'm a little surprised by this, to be honest.

 Here's why: allowing the initial state to be chosen from
 ENROLL/AVAILABLE from the latest version of the API is precisely as
 complex as allowing two versions of the API {old, new} where old
 creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
 difference I can see is that eventually someday if {old} stops being
 supported, then and only then we can go through the code and clean
 things up.

 It seems to me that the costs to us of supporting graceful transitions
 for users here are:

 1) A new version NEWVER of the API that supports node state being one
 of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
 AVAILABLE when not supplied.
 2) Supporting the initial state of AVAILABLE indefinitely rather than
 just until we *delete* version 1.10.
 3) CD deployments that had rolled forward to 1.11 will need to add the
 state parameter to their scripts to move forward to NEWVER.
 4) Don't default the client to the veresions between 1.10 and NEWVER
 versions at any point.

 That seems like a very small price to pay on our side, and the
 benefits for users are that they can opt into the new functionality
 when they are ready.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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] [neutron] New networking-calico project

2015-08-18 Thread Neil Jerram

No, still not, I'm afraid.

  Original Message
From: Sean M. Collins
Sent: Tuesday, 18 August 2015 19:15
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] New networking-calico project

Jenkins came back with a +1 about 20 minutes after your +1 - see if you
can +2 it now? Totally a guess.
--
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

__
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] [ironic] Re: New API for node create, specifying initial provision state

Apologies, forgot to add [ironic] to the subject.

On 18 August 2015 at 13:27, Ruby Loo rlooya...@gmail.com wrote:

 Hi,

 I want to start a different thread on this topic because I don't think
 this is about whether/how to do API microversions. Rather, given that we
 are going to support microversioning, how to deal with the non-backward
 compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
 being the provision state that a node is in, after being created/registered
 in ironic.

 (This was from 'Let's talk about API versions,
 http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html
 .)

 I want to think about this before replying but others are more than
 welcome to reply first so that I may not feel the need to reply :-)

 --ruby
 maybe chop off this and above when replying :-)

 On 17 August 2015 at 20:20, Robert Collins robe...@robertcollins.net
 wrote:

 On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com wrote:
  Hi, sorry for the delay. I vote no. I understand the rationale of
 trying to
  do things so that we don't break our users but that's what the
 versioning is
  meant for and more importantly -- I think adding the ENROLL state is
 fairly
  important wrt the lifecycle of a node. I don't particularly want to hide
  that and/or let folks opt out of it in the long term.
 
  From a reviewer point-of-view, my concern is me trying to remember all
 the
  possible permutations/states etc that are possible to make sure that new
  code doesn't break existing behavior. I haven't thought out whether
 adding
  this new API would make that worse or not, but then, I don't really
 want to
  have to think about it. So KISS as much as we can! :)

 I'm a little surprised by this, to be honest.

 Here's why: allowing the initial state to be chosen from
 ENROLL/AVAILABLE from the latest version of the API is precisely as
 complex as allowing two versions of the API {old, new} where old
 creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
 difference I can see is that eventually someday if {old} stops being
 supported, then and only then we can go through the code and clean
 things up.

 It seems to me that the costs to us of supporting graceful transitions
 for users here are:

 1) A new version NEWVER of the API that supports node state being one
 of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
 AVAILABLE when not supplied.
 2) Supporting the initial state of AVAILABLE indefinitely rather than
 just until we *delete* version 1.10.
 3) CD deployments that had rolled forward to 1.11 will need to add the
 state parameter to their scripts to move forward to NEWVER.
 4) Don't default the client to the veresions between 1.10 and NEWVER
 versions at any point.

 That seems like a very small price to pay on our side, and the
 benefits for users are that they can opt into the new functionality
 when they are ready.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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] [neutron] New networking-calico project

2015-08-18 Thread Neil Jerram

On 17/08/15 18:47, Neil Jerram wrote:
 I'd like to announce networking-calico [...]

 Then the plan for networking-calico is that it will contain docs, an ML2
 mechanism driver, a DHCP interface driver, and a Devstack plugin for
 Calico.  These aren't yet at [10], but I will be getting on with that
 shortly, [...]

 [10] https://git.openstack.org/cgit/openstack/networking-calico


I've hit a Gerrit/infrastructure problem related to this, and wonder if
someone can see the problem.

I have an initial cookiecutter skeleton for networking-calico at
https://review.openstack.org/#/c/211452/, and I'd like to +2 and approve
it, but I don't see any +2 or -2 options in my Gerrit page for that
change.  I _am_ a member of the networking-calico-core group [1], so I
think I should be able to do this - but as I say, I don't see the options.

[1] https://review.openstack.org/#/admin/groups/1014,members

Can anyone see the problem?  Or am I misunderstanding what I should be
able to do?

Thanks,
Neil


__
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] New networking-calico project

2015-08-18 Thread Sean M. Collins

Jenkins came back with a +1 about 20 minutes after your +1 - see if you
can +2 it now? Totally a guess.
-- 
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] [tripleo] Upgrades, Releases Branches

2015-08-18 Thread James Slagle

On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy sha...@redhat.com wrote:
 On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
 On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy sha...@redhat.com wrote:
  Hi all,
 
  Recently I had some discussion with folks around the future strategy for
  TripleO wrt upgrades, releases and branches, specifically:
 
  - How do we support a stable TripleO release/branch that enables folks to
easily deploy the current stable release of OpenStack
  - Related to the above, how do we allow development of TripleO components
(and in particular t-h-t) to proceed without imposing undue constraints
on what new features may be used (e.g new-for-liberty Heat features which
aren't present in the current released OpenStack version)
  - We're aiming to provide upgrade support, thus from and to which versions?
 
  I know historically TripleO has taken something of a developer and/or
  continuous deployment model for granted, but I'd like to propose that we
  revisit that discusion, such that we move towards something that's more
  consumable by users/operators that are consuming the OpenStack coordinated
  releases.
 
  The obvious answer is a stable branch for certain TripleO components, and
  in particular for t-h-t, but this has disadvantages if we take the
  OpenStack wide no feature backports approach - for example upgrade
  support to liberty could be considered a feature, and many other TripleO
  features are really more about making features of the deployed OpenStack
  services consumable.
 
  I'd like propose we take a somewhat modified release branch approach,
  which combines many of the advantages of the stable-branch model, but
  allows for a somewhat more liberal approach to backports, where most things
  are considered valid backports provided they work with the currently
  released OpenStack services (e.g right now, a t-h-t release/kilo branch
  would have to maintain compatibility with a kilo Heat in the undercloud)

 I like the idea, it seems reasonable to me.

 I do think we should clarify if the rule is:

 We *can* backport anything to release/kilo that doesn't break
 compatibility with kilo Heat.

 Or:

 We *must* backport anything to release/kilo that doesn't break
 compatibility with kilo Heat.

 I think I was envisaging something closer to the must, but as Zane said,
 more a should, which if automated would become an opt-out thing, e.g
 through a commit tag nobackport or whatever.

 Ideally, for the upstream branch we should probably be backporting most
 things which don't break compatibility with the currently released
 OpenStack services, and don't introduce gratuitous interface changes or
 other backwards incompatibilities.

 I know our template interfaces are fuzzily defined but here are some
 ideas of things we might not backport in addition to the must work with
 kilo rule:

 - Removing parameters or resource types used to hook in external/optional
   code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
   the descriptions, docs and release notes, then have them removed only
   when moving between TripleO releases (same as deprecation policy for most
   other projects)

 - Adding support for new services which either don't exist or weren't
   considered stable in the current released version

 If it's the former, I think we'd get into a lot of subjective
 discussions around if we want certain things backported or not.
 Essentially it's the same discussion that happens for stable/*, except
 we consider features as well. This could become quite difficult to
 manage, and lead to a lot of reviewer opinionated inconsistency into
 what actually ends up getting backported.

 True, but this decision making ends up happening sometime regardless, e.g
 what patches do you carry in a downstream package etc?  But you're right
 defining the process early should help with consistency.


 For instance, there could be a very large and disruptive feature that
 doesn't break compatibility at all, but some users may not want to see
 it in release/kilo. Or, something like the recent proposed patch to
 rename a bunch of templates by dropping the -puppet. That doesn't
 break compatibility with a kilo Heat at all, however it could break
 compatibility with someone's scripts or external tooling, and might be
 a considered an API incompatible change. The consuming downstreams
 (RDO) may not want to consume such a change. I know we don't have any
 official published API for tripleo-heat-templates, I'm just trying
 to think about how people consume the templates, and what they might
 find surprising if they were to be using release/kilo.

 Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
 maintain a fork downstream, and to improve the experience for folks wanting
 to consume upstream tripleo directly to deploy the coordinated release.

 So IMO we should consider the requirements of both those groups of users -
 some

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

2015-08-18 Thread Jeremy Stanley

On 2015-08-18 10:34:35 +0200 (+0200), Thierry Carrez wrote:
 Dave Walker wrote:
[...]
  Maybe this is a perfect use-case for git-notes?  This means the commit
  itself isn't touched and the non-scale git-tag space isn't wasted?
 
 It definitely seems to be the perfect match: adding notes to commits
 lets us document release notes both during and after backports, without
 altering commit messages.
 
 The trick is that like git tags, git notes do not appear to be
 code-reviewable using Gerrit, they are directly pushed by people with
 Push Refs rights (or by Gerrit itself on merge to store approval
 details). So ideally we want to generate them from properly
 code-reviewed data.
[...]

Well, that's not the _only_ challenge with git notes. Unlike tags,
they're not easily cloned/fetched from a remote (you need to modify
your local configuration to explicitly fetch their refspace).

 Then pbr would just parse git notes instead of commit messages to
 generate releasenotes files in the code tarballs.

It strikes me as an over-specialized feature for PBR. Basically
unless the end user modifies their local Git configuration, they
won't have a copy of these Git notes and so their PBR-generated
release notes would be substantially more hollow (or nonexistent?)
than those we're publishing. We can of course work around this in
our own automation, but at that point why bother to teach PBR about
Git notes at all?
-- 
Jeremy Stanley

__
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] [Monasca] Minutes for Monasca 8-18-2015

2015-08-18 Thread Hochmuth, Roland M

Minutes for the Monasca Weekly Meeting 8-18-2015.

https://etherpad.openstack.org/p/Monasca_Weekly_Meeting_8-18-2015

__
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

2015-08-18 Thread Lucas Alvares Gomes

HI

 Hi, I'd like to make sure I understand. Is it the case that ideally, if we
 could go back in time, we'd like to change the client so it defaults to 1.1?

AFAIUI, yes

 But since we can't, the next client that we ship/release will have the most
 reasonable oldest version? If so, then since the most recent client shipped
 is at 1.6, then I think we should put it back to 1.6 even though it is 1.9
 on master. Regardless of whether there are no backwards incompatible changes
 between 1.6  1.9 -- because we need to stick to some way-of-doing-things,
 and if we use 1.9, I suspect it will be confusing. At least 1.6 was what we
 had at the end of kilo.


The reason why I think we should release with 1.9 is because:

1) It's already on master and people may be using it already

2) It's compatible with the previous version that has been released
already (1.6).

So it won't break neither users that just get it from pip nor users
that clone the git repository.

 What we're saying is that for M*, N*, O*, ..., the version used in the
 client will be the higher of server's MIN_VER_STR or 1.6, right?


It's a suggestion, if we all agree that the minimal version (1.1) is
the ideal version to the client to be pinned with when no other
version is specified, how can we best warn the users that we are going
to pin to this version for the future releases ?

Maybe we don't need to do that, but would be good to discuss and have
a consensus about it.


 Hey Lucas, Maybe I missed something about the client. If no version is
 specified to the (next-released) client, won't it use 1.6? How are we going
 to move it back to 1.1?


Yeah *right now* with the last released version if you don't specify a
version it will use 1.6. With the current code in the git repository
the version will used will be 1.9 if no other is specified.

About how we are going to move it back was my question as well. If we
all agree in moving it to 1.1 when no version is specified how we can
best warn the users that we are going to do that? Since it might break
their workflow. Maybe we shouldn't move it back, but let's keep the
conversation going so we can solve this.

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] [all][api] New API Guidelines ready for cross project review

2015-08-18 Thread michael mccune


On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 18.


these are slated for merge today, but each has a few comments 
surrounding minor nit-type improvements. should we merge these as is and 
create fix patches, or can we add the changes and merge?


i realize that according to our process[1], these are technically good 
to merge as there is not enough -1 consensus to stop them. i just wanted 
to ask the group before pushing ahead.


mike

[1]: http://specs.openstack.org/openstack/api-wg/process.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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-18 Thread Jay Pipes

How about a settings.py switch that would simply allow the deployer to 
entirely disable the list users functionality?


Best,
-jay

On 08/18/2015 12:52 PM, Timur Sufiev wrote:

IMO, if that's impossible to provide Users pagination/indexing for LDAP
from technical point of view, we'd better revise the current UI of
Identity-Users, since most likely production-grade OpenStack
installations will have LDAP instead of MySQL storage. So I'm for
gathering more operators/deployers feedback on the pagination (Users
panel particularly).

I'm inclined to revising existing UI not because I think the Keystone
community is adamant in doing things the way they're going to, but
because LDAP storage backend seems to be unavoidable for large OpenStack
deployments and Horizon shouldn't ignore this fact (what's the point in
having fancy UI when it's broken for real-world installations?). Of
course, 'unavoidable' thing is open to discussion.

On Tue, Aug 18, 2015 at 6:30 AM Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:

On 08/17/2015 09:53 PM, David Lyle wrote:


I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3
API. Since this is purely a keystone construct it seems
implausible to me that ldap or the IdP of choice would be limiting
the ability to return a paginated list of all projects. Or groups
or domains or roles for that matter.



Yeah, SQL can support it.  LDAP assignment can't.  But that is not
going to have a long life.

With Hierarchical projects, we'll probably also have to keep nesting
in mind for how we display a project list:  do we always show a flat
list, or is a tree closer to what users expect?

Both are going to work poorly for some deployments and work well for
others.



There is no reason to punt on pagination across the API for one
resource type, which actually would also work with select
backends. Give me something that I can exhaustively list in the
API I can build from.

David

On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov
mailto:kevin@pnnl.gov wrote:

1. yes, but probably only if its a short list. It may be
feasible to show it only if there are 5 or less pages, and
maybe just load all pages of data and paginate it on the
client. If too big, ask the user to refine their search? Or
always paginate to 5, and then the 6th page have a page
requesting further refinement?

2. Not sure what the difference between searching and
filtering is in this context? something like facets? If so,
probably the 5 or less thing would work here too.

3. Yes, but again, probably within a smaller set of pages?

Thanks,
Kevin

From: Kruithof, Piet [pieter.c.kruithof...@hp.com
mailto:pieter.c.kruithof...@hp.com]
Sent: Sunday, August 16, 2015 9:41 AM
To: openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon]
Pagination support for Identity dashboard entities

I like Michael’s response because it moved the thread towards
identifying actual user needs before digging into the
technical feasibility.  IMHO, it would be helpful to have a
few people on the list answer his questions:

1 - Do users want to page through search results?


2 - Do users want to page through filter results? (do they use
filter results?)


3 - If they want to page, do they want to be able to go back a
page and/or know their current page?


I understand that even if we answer “yes” to all three
questions that there could be issues around implementation,
but at least we’ll know a gap exists.


Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

For every complex problem, there is a solution that is
simple, neat and wrong.”

H L Menken



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

Re: [openstack-dev] [tripleo] Upgrades, Releases Branches

On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
 On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy sha...@redhat.com wrote:
  Hi all,
 
  Recently I had some discussion with folks around the future strategy for
  TripleO wrt upgrades, releases and branches, specifically:
 
  - How do we support a stable TripleO release/branch that enables folks to
easily deploy the current stable release of OpenStack
  - Related to the above, how do we allow development of TripleO components
(and in particular t-h-t) to proceed without imposing undue constraints
on what new features may be used (e.g new-for-liberty Heat features which
aren't present in the current released OpenStack version)
  - We're aiming to provide upgrade support, thus from and to which versions?
 
  I know historically TripleO has taken something of a developer and/or
  continuous deployment model for granted, but I'd like to propose that we
  revisit that discusion, such that we move towards something that's more
  consumable by users/operators that are consuming the OpenStack coordinated
  releases.
 
  The obvious answer is a stable branch for certain TripleO components, and
  in particular for t-h-t, but this has disadvantages if we take the
  OpenStack wide no feature backports approach - for example upgrade
  support to liberty could be considered a feature, and many other TripleO
  features are really more about making features of the deployed OpenStack
  services consumable.
 
  I'd like propose we take a somewhat modified release branch approach,
  which combines many of the advantages of the stable-branch model, but
  allows for a somewhat more liberal approach to backports, where most things
  are considered valid backports provided they work with the currently
  released OpenStack services (e.g right now, a t-h-t release/kilo branch
  would have to maintain compatibility with a kilo Heat in the undercloud)
 
 I like the idea, it seems reasonable to me.
 
 I do think we should clarify if the rule is:
 
 We *can* backport anything to release/kilo that doesn't break
 compatibility with kilo Heat.
 
 Or:
 
 We *must* backport anything to release/kilo that doesn't break
 compatibility with kilo Heat.

I think I was envisaging something closer to the must, but as Zane said,
more a should, which if automated would become an opt-out thing, e.g
through a commit tag nobackport or whatever.

Ideally, for the upstream branch we should probably be backporting most
things which don't break compatibility with the currently released
OpenStack services, and don't introduce gratuitous interface changes or
other backwards incompatibilities.

I know our template interfaces are fuzzily defined but here are some
ideas of things we might not backport in addition to the must work with
kilo rule:

- Removing parameters or resource types used to hook in external/optional
  code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
  the descriptions, docs and release notes, then have them removed only
  when moving between TripleO releases (same as deprecation policy for most
  other projects)

- Adding support for new services which either don't exist or weren't
  considered stable in the current released version

 If it's the former, I think we'd get into a lot of subjective
 discussions around if we want certain things backported or not.
 Essentially it's the same discussion that happens for stable/*, except
 we consider features as well. This could become quite difficult to
 manage, and lead to a lot of reviewer opinionated inconsistency into
 what actually ends up getting backported.

True, but this decision making ends up happening sometime regardless, e.g
what patches do you carry in a downstream package etc?  But you're right
defining the process early should help with consistency.

 
 For instance, there could be a very large and disruptive feature that
 doesn't break compatibility at all, but some users may not want to see
 it in release/kilo. Or, something like the recent proposed patch to
 rename a bunch of templates by dropping the -puppet. That doesn't
 break compatibility with a kilo Heat at all, however it could break
 compatibility with someone's scripts or external tooling, and might be
 a considered an API incompatible change. The consuming downstreams
 (RDO) may not want to consume such a change. I know we don't have any
 official published API for tripleo-heat-templates, I'm just trying
 to think about how people consume the templates, and what they might
 find surprising if they were to be using release/kilo.

Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
maintain a fork downstream, and to improve the experience for folks wanting
to consume upstream tripleo directly to deploy the coordinated release.

So IMO we should consider the requirements of both those groups of users -
some degree of stability probably makes sense, e.g not removing parameters
during the life of the

Re: [openstack-dev] [neutron] New networking-calico project

2015-08-18 Thread Sean M. Collins

Are your ACLs set up properly?

https://review.openstack.org/#/admin/projects/openstack/networking-calico,access

I don't see your group - or any actual group that has rights assigned to
the repo - it's empty.

compare that to:

https://review.openstack.org/#/admin/projects/openstack/neutron,access


-- 
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] [Horizon] Update on Angular Identity work

2015-08-18 Thread Thai Q Tran

Hi everyone,Just wanted to keep everyone up to date on the angular panels work. The goal was to set a pattern that others can follow, to that end, there were a few requirements:1. reusable and possibly pluggable2. easy to understand3. reduce code duplicationThese requirements don't always go hand-in-hand, and that is the primary reason why it is taking a bit longer. I believe we are nearing the end of it, here are some items remaining that I believe is crucial to finishing up this work.a. i18n was completed, so we need help moving gettext blobs to HTML templates (example patch:https://review.openstack.org/#/c/210366/ ) volunteers are welcomed! We want others to use the translate directive as the main way to translate text blobs, this was why we went down this road using babel and angular_extractor plugin.b. transfer table supports clone feature ( https://review.openstack.org/#/c/211345/). There were a lot of template duplications, this clone feature reduces the HTML by a considerable amount. Since this is something we use quite often, it made sense to invest time into improving it. We have had complaints that there was too much HTML fragments, this will address a bit of that. One of the challenge was to get it working with existing launch-instance, so I spent about 2 weeks making sure it worked well with the old code while allowing the new clone feature.c. I believe we have a pretty good pattern setup for tables. The final piece of the puzzle was the patterns for various actions. We have wizard (create user), form (edit user), confirmation dialog (delete user), and actions with no modal dialog (enable user). We wanted a general pattern that would address the requirements mentioned above. There were some discussions around extensibility at the midcycle that I think will fit well here as well ( https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ). The actions can follow a similar pattern to workflow. I believe this pattern would address #1 and #3 but making it easy to understand is a bit challenging - I think this is where documentation could help.https://review.openstack.org/#/c/202315/ and a few other patches are going to be ready for review soon (sometime end of this week)!Item #c is the most important piece, it is going to be the general pattern that people will use to build their angular panels with, so the more eyes we can get on it, the better.My aim is to get it in before the feature freeze and I think that is entirely possible with your help. So please help review even if you are not a core!Thanks


__
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] [libvirt-vif] Extend vhost-user interface to support Cisco Nexus 1000v.

2015-08-18 Thread Kyle Mestery

On Tue, Aug 18, 2015 at 11:48 AM, Kiran Chunduri kiran.askl...@gmail.com
wrote:

 Hello All,
 We would like to extend the nova 'vhost-user' plug API to attach the port
 to Cisco Nexus 1000v, which supports vhost-user interface. Currently the
 plug-API supports attaching to OVS. The code I'm referring to is
 'plug_vhostuser()' API in 'nova/virt/libvirt/vif.py'.

 I would like to submit changes for this. But One of my colleague mentioned
 there is a proposal to make the NOVA VIF driver more generic. Can some one
 please elaborate on this (or) point to blue-print? I would like to look and
 discuss on the proposal.


This was discussed at the nova mid-cycle, and the plan of record is for Jay
Pipes to push his os_vif repo [1] out for review once he addresses some
feedback he's received already. This will make it easier to do what you're
looking to do Kiran.

Thanks,
Kyle

[1] https://github.com/jaypipes/os_vif


 thanks in advance,
 Kiran

 __
 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] [stable] [infra] How to auto-generate stable release notes

2015-08-18 Thread Doug Hellmann

Excerpts from Thierry Carrez's message of 2015-08-18 10:34:35 +0200:
 Dave Walker wrote:
  On 17 August 2015 at 15:59, Jeremy Stanley fu...@yuggoth.org wrote:
  On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
  [...]
  OSSA: -ZZZ
  For commits that correspond to vulnerability fixes.
  [...]
 
  I don't think that's going to be feasible. Consider the sequence
  with a public security vulnerability... often the OSSA number isn't
  assigned until after one or more backports have been approved. With
  some careful controls introduced into the VMT process we may be able
  to make sure most of these get updated commit messages before they
  merge, but would still need a plan to solve for the times when
  backported security fixes slip in without an OSSA header in the
  commit message.
 
 That's actually another case where we need to be able to fix up release
 notes after the fact. So my question still stands:
 
  We also might need a mechanism to add to release notes when we realize
  after the fact that a specific commit in past history warrants a
  highlight. Would some kind of no-change commit do the trick ?
 
 Dave suggested:
 
  Maybe this is a perfect use-case for git-notes?  This means the commit
  itself isn't touched and the non-scale git-tag space isn't wasted?
 
 It definitely seems to be the perfect match: adding notes to commits
 lets us document release notes both during and after backports, without
 altering commit messages.
 
 The trick is that like git tags, git notes do not appear to be
 code-reviewable using Gerrit, they are directly pushed by people with
 Push Refs rights (or by Gerrit itself on merge to store approval
 details). So ideally we want to generate them from properly
 code-reviewed data.
 
 We could have a Gerrit plugin (inspired from the reviewnotes plugin)
 that takes specific headers from commit messages and populate a
 releasenote git note accordingly.
 
 For after-the-fact git notes (say, to add an OSSA reference to an
 already-merged commit), we could have a section in the
 openstack/releases proposed change that describes additional
 releasenote git notes to push to old commits when the change is accepted.

We could use the openstack/releases repo to track all of them, so
the process is consistent for all types of stable patches.

Within the releases repo, we want to separate the release notes
from the deliverables files, because we want to support adding notes
independent of creating a release.

OK, I think this could work, but I'm worried about by whom and when.

Would it make sense to start with something simple, like just asking
folks to write RST files with release notes in the releases repository?
That at least *captures* the data, and we can enforce it as we review
stable branch patches.

Doug

 
 Something like:
 
 additional-notes:
   cc6c50ee23f336d08e4fe833070943c0025a205d:
 OSSA: 2015-022
   fcfbf8eb0e0d42ff54bd014bc9e43f5f48bd7a68:
 Release-note: 
   Fixing bug 1237534 actually results in a 10x performance
   improvement listing networks connected to an instance
 
 That way all note content is properly reviewed before they make it to
 the git notes.
 
 Then pbr would just parse git notes instead of commit messages to
 generate releasenotes files in the code tarballs.
 

__
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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

On Tue, Aug 18, 2015 at 05:59:44PM +0200, Jaume Devesa wrote:
Hi Steven/Emilien,

Thanks for the quick responses.

On Tue, 18 Aug 2015 16:10, Steven Hardy wrote:
On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:

I think the pattern for the templates will be similar to the Cisco ML2
plugins which are currently being integrated:

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

The plug-points for third-party configuration is still undergoing some
refinement, but the basic steps are:

1. Ensure you have support in the upstream puppet modules (as mentioned by
Emilien), and figure out the hieradata required to drive puppet as
required.

Yes, we would like to be fully upstream on this. MidoNet plugin support for
Puppet Neutron is already done since Kilo (and backported to Juno). We do have
in mind Emilien's request. So I think that won't be a problem.

2. Create a heat template which creates the hieradata, and defines
parameters for all configurable values, e.g like:

https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml

3. Define a heat environment file, which wires in the template from (2) via
the OS::TripleO::ControllerExtraConfigPre interface:

https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml

4. Add the hieradata file deployed via (2) to the controller hierarchy:

https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml

5. Add conditional logic to the manifiests so the appropriate modules from
(1) are included when your backend is enabled:

https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp

Basically the way this works is the hieradata is deployed via (2) before
puppet runs, and the manifiest changes in (5) consumes that data when we
apply it during deployment.

The links and the steps to follow are so helpful! Thanks again. Couple of
questions here:

* There is no need of `tripleo-puppet-elements`?

It depends, if your additions require additional packages to be installed,
then you may need to either add them to an existing element, or create a
new element which may be specified by those building images with
diskimage-builder, e.g so their images contain what you require.

https://github.com/openstack/tripleo-puppet-elements/blob/master/elements/overcloud-controller/install.d/package-installs-overcloud-controller

If your integration purely requires configuration changes (and the puppet
module already exists in the image), you may not need to do anything.

* Since the integration seems feasible, does it make sense to start opening a
blueprint and start working on it?

Absolutely, a blueprint is probably a good idea (although tbh these haven't
been strictly required lately..) summarising the required changes, then you
can use the examples I linked to work on the template changes.

No, we're moving away from tuskar and it's not required for third-party
integration such as described above (it's also not covered in CI).

Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
stays working, as clearly we don't have the resources in upstream CI to
test it, having third-party CI jobs vote on TripleO changes would be one
way to solve this, but AFAIK we don't yet have a process in place to enable
this.

Even if there is not an official Third Party methodology, it wouldn't be so
hard
to add a Jenkins job on our infrastructure to listen upstream gerrit events
and
make comments instead of voting, right? (maybe I am speaking so quickly, I can
not image right now how a TripleO Jenkins job look like...)

Yes, this was exactly what I had in mind - it'd be great if we could get
some sort of non-voting comments from those contributing third-party
additions - I know this pattern works well for other projects, so I guess
the same approach for TripleO may be reasonable as well.

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

[openstack-dev] [nfv][telcowg] Telco Working Group meeting canceled for Wednesday August 19th

2015-08-18 Thread Steve Gordon

Hi all,

Due to a number of events going on this week (Operators 
Mid-cycle/LinuxCon/KVMForum/etc.) I am canceling the Telco Working Group 
meeting for the 19th.

Thanks!

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] [Neutron][bgpvpn] Service Plugin vs Service driver

2015-08-18 Thread Mathieu Rohon

hi brandon,

thanks for your answer.

my answers inline,



On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 So let me make sure I understand this. You want to do a separate service
 plugin for what would normally be separate drivers under one service
 plugin.  The reasons for this are:


 1. You dont want users the ability to choose the type, you want it always
 to be the same one

 2. Some types do want to be the source of truth of the data stored,
 instead of it being the service plugin database.


 First, let me address the possibility of a solution using one service
 plugin and multiple drivers per type:


 I think that you can overcome #1 in the instantiation of the service
 plugin to check if there are more than 1 provider active, if so you can
 just throw an exception saying you can only have 1.  I'd have to look at it
 more to see if there are any caveats to this, but I think that would work.


 For #2, assuming #1 works, then the drivers that are defined can have some
 boolean that they set that will tell the plugin whether they are the source
 of truth or not, and depending on that you can store the data in the
 service plugin's db or just pass the data along, also pass GET requests to
 the drivers as well.


I agree that those workarounds will surely works but I wonder what is the
meaning of a service plugin/type that can only support one service
provider? can't the service plugin be the service provider directly?

The reasons why I'm considering this change are :

1. I'm not sure we would have some use cases where we would be able to
choose one bgpvpn backend independently from the provider of the core
plugin (or a mech driver in the ML2 case) and/or the router plugin.
If one use ODL to manage its core resources, he won't be able to use nuage
or contrail to manage its bgpvpn connection.
The bgpvpn project is more about having a common API than having the
capacity to mix backends. At least for the moment.

2. I'm also considering that each plugin, which would be backend dependent,
could declare what features it supports through the use of extensions. Each
plugin would be a bgpvpn service type, and would implement the bgpvpn
extension, but some of them could extend the bgpvpn_connection resource
with other extensions also hosted in the bgpvpn project. Since some
backends only support attachment of networks to a bgpvpn_connection, others
support attachment of routers, and others both attachments, I'm considering
having an extension for each type of attachment. Then the bgpvpn plugin
declares what extensions it supports and the end user can act accordingly
depending on the scan of neutron extensions.
By moving to one plugin per backend, the load of extensions would be done
by the neutron framework, natively. We won't have to scan each service
providers to see what extensions it supports, as it is done by the ML2
extension manager.
But I agree that with your workaround, of allowing only one service
provider, we can easily scan this driver for its extensions.


 As for making a service plugin for each type, I don't see why that
 wouldn't work.  It seems a bit overkill to me though because you'd probably
 end up having 2 base classes for every service plugin type, one for using
 the service plugin database and another for the data source of truth being
 external.  Probably a better way to do this, I'm sure I'm oversimplifying.

You're right, and you're not oversimplifying. With this change, the bgpvpn
framework will only manage API extensions and the DB layer if needed. And
we don't want this framework to be complicated, in a first step, we just
want to have a consistent API for every backends.

 I don't see much technical reasons why you couldn't do this, though.  It's
 just inconsistent and might cause some confusion.  I'd need to spend some
 time on it to really have an educated opinion.

The fact that this change will lead to inconsistency between usage of each
service plugins is a valid point and might be enough to not do it and
instead limiting the bgpvpn service plugin to be able to only load one
service driver for the moment. Which is also inconsistent with some other
service plugins, but probably less.

thanks brandon.

Mathieu

Thanks,
 Brandon
 --
 *From:* Mathieu Rohon mathieu.ro...@gmail.com
 *Sent:* Tuesday, August 18, 2015 7:13 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service
 driver

 Adding the related subject :)

 On Tue, Aug 18, 2015 at 10:35 AM, Mathieu Rohon mathieu.ro...@gmail.com
 wrote:

 Hi all,

 The current bgpvpn implementation is using the service type framework,
 with a service plugin and one or more service providers.

 After registering the bug [1], I wonder if we would rather use a service
 plugin per implementation type (bagpipe, ODL, OpenContrail, Nuage...) which
 handles API calls, instead of having one service plugin which forwards

Re: [openstack-dev] [keystone] Liberty SPFE Request - IDP Specific WebSSO

2015-08-18 Thread Lance Bragstad

Just following up the thread; this was voted on during the Keystone meeting
today and the SPFE has been granted [0].

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-08-18.log.html#t2015-08-18T18:03:37

On Thu, Aug 13, 2015 at 9:49 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 To be fair this is pushing late into the cycle for adding a new target for
 Liberty. We already have a very large body of code that has historically
 not received consistent reviewing. My concern is that we're again rushing
 things in at the wire and will get a substandard implementation.

 I wont block this, but as with the other spec freeze exceptions we will
 vote at the next keystone meeting on accepting this spec freeze exception.

 Please make sure to add it to the weekly meeting and feel free to continue
 this discussion here on the ML to cover justifications etc.

 --Morgan

 Sent via mobile

 On Aug 12, 2015, at 16:20, Lance Bragstad lbrags...@gmail.com wrote:

 Hey all,


 I'd like to propose a spec proposal freeze exception for IDP Specific
 WebSSO [0].

 This topic has been discussed, in length, on the mailing list [1], where
 this spec has been referenced as a possible solution [2]. This would allow
 for multiple Identity Providers to use the same protocol. As described on
 the mailing list, this proposal would help with the public cloud cases for
 federated authentication workflows, where Identity Providers can't be
 directly exposed to users.

 The flow would look similar to what we already do for federated
 authentication [3], but it includes adding a call in step 3. Most of the
 code for step 3 already exists in Keystone, it would more or less be adding
 it to the path.


 Thanks!


 [0] https://review.openstack.org/#/c/199339/2
 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2015-August/071131.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2015-August/071571.html
 [3] http://goo.gl/lLbvE1

 __
 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] [openstack-deb] Devstack stable/juno fails to install

2015-08-18 Thread Matt Riedemann




On 8/17/2015 7:59 PM, Tony Breeds wrote:

On Mon, Aug 17, 2015 at 03:51:46PM -0500, Matt Riedemann wrote:


What version of taskflow is installed?  Cinder 2014.2.3 requires this
version of taskflow [1]:

taskflow=0.4,0.7.0

Which should get you taskflow 0.6.2, and taskflow 0.6.2 has this requirement
[2] for futures:

futures=2.2.0,=2.1.6

What version of futures is installed?  Run 'pip show futures'.


---
stack@stack01:~/projects/openstack/openstack-dev/devstack$ pip show futures
---
Metadata-Version: 2.0
Name: futures
Version: 3.0.3
Summary: Backport of the concurrent.futures package from Python 3.2
Home-page: https://github.com/agronholm/pythonfutures
Author: Alex Gronholm
Author-email: alex.gronholm+p...@nextday.fi
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires:
---

I think this is being pulled in by an uncapped dependancy in swiftclient:
---
2015-08-17 23:41:42.287 | Collecting futures=2.1.3 (from 
python-swiftclient=2.3.1,=2.2.0-glance==2014.2.4.dev6)
2015-08-17 23:41:42.326 |   Using cached futures-3.0.3-py2-none-any.whl
---

I know the devstack/juno install worked on Friday last week, so something 
changed over the weekend.

Ahh perhaps this https://review.openstack.org/#/c/212652/ ?

My solution would be to cap futures in swiftclient but I don't knwo that is 
correct.

Yours Tony.



__
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



Yeah, g-r for stable/juno caps python-swiftclient at 2.3.1 [1] and that 
version has an uncapped dependency on futures [2].


You'd have to get a stable/juno branch created for python-swiftclient 
from the 2.3.1 tag probably, then cap futures and release that as 2.3.2. 
 You'd also have to raise the cap on swiftclient in g-r stable/juno to 
python-swiftclient=2.2.0,2.4.0.


[1] 
https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt#L121
[2] 
https://github.com/openstack/python-swiftclient/blob/2.3.1/requirements.txt#L1


--

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

Re: [openstack-dev] [Horizon] Update on Angular Identity work

2015-08-18 Thread Lin Hua Cheng

I think the table setup pattern have some opportunity for reducing code
duplication before it gets re-used by other panels..

We used to just need to write one file to define a table, now we have to
write 9 files [1]. Can we have a table directive to reduce the duplicated
code before moving forward to other panels?

-Lin

[1]
https://github.com/openstack/horizon/tree/master/openstack_dashboard/dashboards/identity/static/dashboard/identity/users/table

On Tue, Aug 18, 2015 at 11:49 AM, Thai Q Tran tqt...@us.ibm.com wrote:

Hi everyone,

Just wanted to keep everyone up to date on the angular panels work. The
goal was to set a pattern that others can follow, to that end, there were a
few requirements:
1. reusable and possibly pluggable
2. easy to understand
3. reduce code duplication

These requirements don't always go hand-in-hand, and that is the primary
reason why it is taking a bit longer. I believe we are nearing the end of
it, here are some items remaining that I believe is crucial to finishing up
this work.

a. i18n was completed, so we need help moving gettext blobs to HTML
templates (example patch: https://review.openstack.org/#/c/210366/ )
volunteers are welcomed! We want others to use the translate directive as
the main way to translate text blobs, this was why we went down this road
using babel and angular_extractor plugin.

b. transfer table supports clone feature (
https://review.openstack.org/#/c/211345/ ). There were a lot of template
duplications, this clone feature reduces the HTML by a considerable amount.
Since this is something we use quite often, it made sense to invest time
into improving it. We have had complaints that there was too much HTML
fragments, this will address a bit of that. One of the challenge was to get
it working with existing launch-instance, so I spent about 2 weeks making
sure it worked well with the old code while allowing the new clone feature.

c. I believe we have a pretty good pattern setup for tables. The final
piece of the puzzle was the patterns for various actions. We have wizard
(create user), form (edit user), confirmation dialog (delete user), and
actions with no modal dialog (enable user). We wanted a general pattern
that would address the requirements mentioned above. There were some
discussions around extensibility at the midcycle that I think will fit well
here as well (
https://blueprints.launchpad.net/horizon/+spec/angular-workflow-plugin ).
The actions can follow a similar pattern to workflow. I believe this
pattern would address #1 and #3 but making it easy to understand is a bit
challenging - I think this is where documentation could help.

https://review.openstack.org/#/c/202315/ and a few other patches are
going to be ready for review soon (sometime end of this week)! Item #c is
the most important piece, it is going to be the general pattern that people
will use to build their angular panels with, so the more eyes we can get on
it, the better. My aim is to get it in before the feature freeze and I
think that is entirely possible with your help. So please help review even
if you are not a core!

Thanks

__
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-deb] Devstack stable/juno fails to install

2015-08-18 Thread Jeremy Stanley

On 2015-08-18 15:48:08 -0500 (-0500), Matt Riedemann wrote:
[...]
 You'd also have to raise the cap on swiftclient in g-r stable/juno
 to python-swiftclient=2.2.0,2.4.0.
[...]

Followed by stable point releases of everything with a stable/juno
branch and a {test-,}requirements.txt entry for python-swiftclient.
Oh, and some of those things might _also_ have overly-strict caps in
global-requirements.txt, so iterate until clean.
-- 
Jeremy Stanley

__
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] [tripleo] Upgrades, Releases Branches

On Tue, Aug 18, 2015 at 02:28:39PM -0400, James Slagle wrote:
 On Tue, Aug 18, 2015 at 2:10 PM, Steven Hardy sha...@redhat.com wrote:
  On Mon, Aug 17, 2015 at 03:29:07PM -0400, James Slagle wrote:
  On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy sha...@redhat.com wrote:
   Hi all,
  
   Recently I had some discussion with folks around the future strategy for
   TripleO wrt upgrades, releases and branches, specifically:
  
   - How do we support a stable TripleO release/branch that enables folks 
   to
 easily deploy the current stable release of OpenStack
   - Related to the above, how do we allow development of TripleO components
 (and in particular t-h-t) to proceed without imposing undue constraints
 on what new features may be used (e.g new-for-liberty Heat features 
   which
 aren't present in the current released OpenStack version)
   - We're aiming to provide upgrade support, thus from and to which 
   versions?
  
   I know historically TripleO has taken something of a developer and/or
   continuous deployment model for granted, but I'd like to propose that we
   revisit that discusion, such that we move towards something that's more
   consumable by users/operators that are consuming the OpenStack 
   coordinated
   releases.
  
   The obvious answer is a stable branch for certain TripleO components, and
   in particular for t-h-t, but this has disadvantages if we take the
   OpenStack wide no feature backports approach - for example upgrade
   support to liberty could be considered a feature, and many other TripleO
   features are really more about making features of the deployed 
   OpenStack
   services consumable.
  
   I'd like propose we take a somewhat modified release branch approach,
   which combines many of the advantages of the stable-branch model, but
   allows for a somewhat more liberal approach to backports, where most 
   things
   are considered valid backports provided they work with the currently
   released OpenStack services (e.g right now, a t-h-t release/kilo branch
   would have to maintain compatibility with a kilo Heat in the undercloud)
 
  I like the idea, it seems reasonable to me.
 
  I do think we should clarify if the rule is:
 
  We *can* backport anything to release/kilo that doesn't break
  compatibility with kilo Heat.
 
  Or:
 
  We *must* backport anything to release/kilo that doesn't break
  compatibility with kilo Heat.
 
  I think I was envisaging something closer to the must, but as Zane said,
  more a should, which if automated would become an opt-out thing, e.g
  through a commit tag nobackport or whatever.
 
  Ideally, for the upstream branch we should probably be backporting most
  things which don't break compatibility with the currently released
  OpenStack services, and don't introduce gratuitous interface changes or
  other backwards incompatibilities.
 
  I know our template interfaces are fuzzily defined but here are some
  ideas of things we might not backport in addition to the must work with
  kilo rule:
 
  - Removing parameters or resource types used to hook in external/optional
code (e.g *ExtraConfig etc) - we should advertise these as deprecated via
the descriptions, docs and release notes, then have them removed only
when moving between TripleO releases (same as deprecation policy for most
other projects)
 
  - Adding support for new services which either don't exist or weren't
considered stable in the current released version
 
  If it's the former, I think we'd get into a lot of subjective
  discussions around if we want certain things backported or not.
  Essentially it's the same discussion that happens for stable/*, except
  we consider features as well. This could become quite difficult to
  manage, and lead to a lot of reviewer opinionated inconsistency into
  what actually ends up getting backported.
 
  True, but this decision making ends up happening sometime regardless, e.g
  what patches do you carry in a downstream package etc?  But you're right
  defining the process early should help with consistency.
 
 
  For instance, there could be a very large and disruptive feature that
  doesn't break compatibility at all, but some users may not want to see
  it in release/kilo. Or, something like the recent proposed patch to
  rename a bunch of templates by dropping the -puppet. That doesn't
  break compatibility with a kilo Heat at all, however it could break
  compatibility with someone's scripts or external tooling, and might be
  a considered an API incompatible change. The consuming downstreams
  (RDO) may not want to consume such a change. I know we don't have any
  official published API for tripleo-heat-templates, I'm just trying
  to think about how people consume the templates, and what they might
  find surprising if they were to be using release/kilo.
 
  Yeah, it's a tricky one, I mean the aim of all this is to avoid having to
  maintain a fork downstream, and to improve the

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-18 Thread Matt Riedemann




On 8/17/2015 10:19 AM, Dan Smith wrote:

Is this documented somewhere?

I did a bit of digging and couldn't find anywhere that explicitly
required that for the J-K upgrade.  Certainly it was documented for the
I-J upgrade.


It's our model, so I don't think we need to document it for each cycle
since we don't expect it to change. We may need more general coverage
for this topic, but I don't expect the release notes to always mention it.

This isn't formal documentation, but it's relevant:

http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/

--Dan

__
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



We have some very loose upgrade docs in the devref [1].  Under the 
Process section, steps 4 and 5 talk about upgrading services in order 
and says conductor (implied controller) first.  Granted we need to clean 
up this page and merge with Dan's more specific blog post, but there is 
*something* in tree docs.


[1] http://docs.openstack.org/developer/nova/upgrade.html

--

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

Re: [openstack-dev] [neutron] New networking-calico project

2015-08-18 Thread Neil Jerram

Although the DHCP-related patches below are I think very close to mergeable, 
Brian Haley on IRC queried what, process-wise, motivates merging them now (for 
Liberty).

I think he's right that something is missing, so I'd like to discuss filling 
that hole here. What has happened so far is this:

- https://review.openstack.org/#/c/198439/ described 'routed networking', which 
is the ultimate motivation for these patches. 

- I realised/was told that there should be an RFE bug, per current process, so 
raised https://bugs.launchpad.net/neutron/+bug/1472704

- Those contributed to the beginning of discussions about supporting 'routed' 
or 'L3' networks in Neutron - which are ongoing and will take Mitaka at least 
to refine. 

- Nevertheless, the DHCP-related patches are still valuable now (as explained 
below) and feasible within the Liberty timescale, so I've continued refining 
those.

- Discussions, which I believe supported this in principle, took place in 
neutron-drivers [1][2] and main Neutron [3] IRC meetings.

[1] 
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-14-15.04.log.html‎

[2]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-07-21-15.00.log.html

[3] discussion between 14:49:44 and 14:56:49 at 
http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-28-14.01.log.html

The specific process issue now is that the patches that (IMO) make sense for 
Liberty reference a bug (1472704) that has a much wider scope and so is quite 
correctly not approved for Liberty. 

So, what to do? My guess is to raise a new RFE bug that just motivates the DHCP 
agent support that I'd like to achieve - by way of the existing patches - in 
the Liberty timescale, ask neutron-drivers to approve that, and update the 
patches to reference that bug instead. 

Does that sound right?

Regards, 
      Neil 


‎
  Original Message  
From: Neil Jerram
Sent: Monday, 17 August 2015 18:47
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] New networking-calico project

I'd like to announce networking-calico, a new project within the Neutron
stadium to provide OpenStack integration pieces for Project Calico
[1][2]. In a sentence, Calico is a backend that uses routing and
iptables to provide IP-level connectivity between VMs, instead of - as
most Neutron backends do - using bridging to provide an effective L2
broadcast domain. You can read about why that might be interesting at
[1][2], or in more OpenStack-centric terms at [3].

Calico's semantics are not fully describable by the current Neutron API,
and I plan to contribute to API and data model work to address this. 
Discussion about that has already begun at [3] and in the email thread
about 'routed, segmented networks' [4], and I hope it will continue
through the end of this cycle, in Tokyo, and during Mitaka.

For a practical deployment, though, and with some semantic caveats [5],
Calico-style connectivity can be used already in an OpenStack cluster - 
and we have several operator partners interested in and trialling that. 
My team has been developing and refining this since Icehouse, using
Calico-specific patches to Nova and Neutron, but we are now within
touching distance, we think, of working with vanilla OpenStack when
Liberty is released. We released our v1.0 milestone of the core Calico
code last week [14], our Nova patches were merged in July, and we have
the following core Neutron patches currently in review.

[6] https://review.openstack.org/#/c/205181/
[7] https://review.openstack.org/#/c/206078/
[8] https://review.openstack.org/#/c/206077/
[9] https://review.openstack.org/#/c/206079/

These patches have been through many cycles of review - thanks in
particular to Cedric and Oleg - and are now, I believe, fully tested and
polished. They make small generalizations to the DHCP agent code so
that a networking-calico-provided interface driver will be able to use
it, instead of having to provide a parallel DHCP agent implementation. 
I would particularly appreciate if Neutron core reviewers would consider
reviewing and approving [6] and [7] now, as they are the changes that
would be messiest if I had to reimplement them out-of-tree using some
kind of subclassing approach.

Then the plan for networking-calico is that it will contain docs, an ML2
mechanism driver, a DHCP interface driver, and a Devstack plugin for
Calico. These aren't yet at [10], but I will be getting on with that
shortly, and you can already see those pieces in other forms (which will
be retired) at [11], [12] and [13]. Hence, within the next few weeks, I
hope that networking-calico and the vanilla Neutron tree (+ the core
Calico project) will provide a complete demonstration of this kind of
networking.

Looking ahead, we will also set up a regular IRC meeting for people
interested in

[openstack-dev] [CI] How to run dsvm_tempest_full without nodepool ?

2015-08-18 Thread Tang Chen


Hi Asselin, Abhishek,
CC: all,

After a long time, I think I failed to setup a nodepool.

I can start nodepool daemon, but when launching nodes with a ready state 
image.




ERROR nodepool.NodeLauncher: Exception launching node id: 7 in provider: 
local_01 error:


Traceback (most recent call last):

  File /usr/local/lib/python2.7/dist-packages/nodepool/nodepool.py, 
line 409, in _run


dt = self.launchNode(session)

  File /usr/local/lib/python2.7/dist-packages/nodepool/nodepool.py, 
line 472, in launchNode


server = self.manager.waitForServer(server_id, self.launch_timeout)

  File 
/usr/local/lib/python2.7/dist-packages/nodepool/provider_manager.py, 
line 458, in waitForServer


return self._waitForResource('server', server_id, timeout)

  File 
/usr/local/lib/python2.7/dist-packages/nodepool/provider_manager.py, 
line 429, in _waitForResource


self.provider.name)):

  File /usr/local/lib/python2.7/dist-packages/nodepool/nodeutils.py, 
line 42, in iterate_timeout


raise Exception(Timeout waiting for %s % purpose)

Exception: Timeout waiting for server 
d7150309-0a33-4338-b4e8-268c719f785b in local_01



Have you ever seen this error before ?


Seeing from the log, I think dsvm-tempest-full test needs nodepool support.

Is dsvm-tempest-full test able to be executed without nodepool ?


Thanks.

__
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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-18 Thread John Griffith

On Tue, Aug 18, 2015 at 7:42 PM, John Griffith john.griffi...@gmail.com
wrote:



 On Tue, Aug 18, 2015 at 2:14 PM, Robert Collins robe...@robertcollins.net
  wrote:

 On 19 August 2015 at 03:51, Sean Dague s...@dague.net wrote:

  So... I'm at Linux Con this week, meaning that things will be slow. I
  think - https://review.openstack.org/#/c/208582/ (slightly updated this
  morning) will get devstack users working again. And I agree, we really
  need devstack and the gate to be convergent on their solution here, not
  divergent.

 So unless something has changed, devstack users are broken only on
 Fedora - and the constraints thing won't protect them at this stage
 because of two things.

 Firstly, the bug isn't a cryptography bug - its a setuptools / pip
 thing resulting in the .so pip installs being in the arch neutral path
 rather than lib64, and this would work except that devstack also
 installs python-cffi, which then masks the pip updated one. I don't
 know why devstack is installing the binary package :/. This is a
 Fedora platform specific bug - it doesn't show up on Ubuntu - either
 because devstack doesn't install the ubuntu python-cffi package, or
 because pip/setuptools on ubuntu don't have the same disconnect with
 system packages in the same way. I'm not sure which.

 Secondly, until we have a gate on openstack/requirements that checks
 devstack-on-fedora, fedora developers will be exposed to this sort of
 thing from time to time :/.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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

 Catching up on this thread, looks like the referenced devstk change above
 (987dc6453e8e3a8a46d748059378564c42bafc5c) merged and broke things.  Seems
 we don't install opt/stack/requirements so stack.sh is failing for third
 party CI's that don't use node-pool (suspect they'll fail when they're
 nodes are rebuilt similar to last weeks issue with keystone).

 Went ahead and confirmed that a fresh download and stack.sh locally fails,
 going to have a look after dinner but thought maybe somebody already knows
 what's up with this.

 Thanks,
 John

 For those that are interested, Clark pointed me to this patch [1] which
in fact the addresses the issue I was running in to.

[1]: https://review.openstack.org/#/c/214409/

Thanks,
John

__
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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-18 Thread Robert Collins

On 19 August 2015 at 03:51, Sean Dague s...@dague.net wrote:

 So... I'm at Linux Con this week, meaning that things will be slow. I
 think - https://review.openstack.org/#/c/208582/ (slightly updated this
 morning) will get devstack users working again. And I agree, we really
 need devstack and the gate to be convergent on their solution here, not
 divergent.

So unless something has changed, devstack users are broken only on
Fedora - and the constraints thing won't protect them at this stage
because of two things.

Firstly, the bug isn't a cryptography bug - its a setuptools / pip
thing resulting in the .so pip installs being in the arch neutral path
rather than lib64, and this would work except that devstack also
installs python-cffi, which then masks the pip updated one. I don't
know why devstack is installing the binary package :/. This is a
Fedora platform specific bug - it doesn't show up on Ubuntu - either
because devstack doesn't install the ubuntu python-cffi package, or
because pip/setuptools on ubuntu don't have the same disconnect with
system packages in the same way. I'm not sure which.

Secondly, until we have a gate on openstack/requirements that checks
devstack-on-fedora, fedora developers will be exposed to this sort of
thing from time to time :/.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
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] [Congress] [Murano] multiple numbers of arguments for table

2015-08-18 Thread Tim Hinrichs

Hi all,

We're contemplating a small syntax change in the Congress policy language
and wanted to see if it would cause anyone problems.

Currently you can write rules that give a single table differing numbers of
columns.  In the following example, the 'error' table has both 1 column and
2 columns.

error(vm) :- blah blah
error(vm, net) :- blah blah

We're contemplating removing this flexibility and making every table have a
fixed number of columns.  (We only support differing numbers of columns in
very special cases anyway.)

Would this cause any problems?  Murano team?

Thanks,
Tim
__
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] Cross-Project meeting, Tue Aug 18th, 21:00 UTC

We did the meeting and you can read the notes here:

http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-08-18-21.01.html

See you next week!

On Tue, Aug 18, 2015 at 8:18 AM, Emilien Macchi emil...@redhat.com wrote:

 Note for myself: do not take a day off before Cross-project meeting so I
 can send the agenda on time :-)

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

 We'll have a cross-project meeting today at 21:00 UTC, with the
 following agenda:

 * Team announcements (horizontal, vertical, diagonal)
 * How to generate .Z version increments on stable/liberty commits
 * How to autogenerate release notes on stable/liberty commits
 * Return request ID to caller
 * Open discussion

 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
 --
 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




-- 
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] [QA][tempest] schema extensions

2015-08-18 Thread Ken'ichi Ohmichi

Hi Viktor,

2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo)
viktor.tikka...@nokia.com:

 I have I question regarding validating responses during API tests.

 Has it been decided some time ago that no additional properties
 are allowed when verifying response schemas during API tests?

There was the related mail:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html

 I have an OpenStack based product that contains few additional
 properties in it's compute API and few tempest cases fail like:

 tempest_lib.exceptions.InvalidHTTPResponseBody: HTTP response body is invalid 
 json or xml
 Details: HTTP response body is invalid (Additional properties are not allowed 
 (u'nics' was unexpected)

 So currently I have to update related schema descriptions located
 under tempest/api_schema/ in order to get those tests passed.

 Just wondering if there is some more convenient way to handle such
 kind of drawbacks. Could this schema validating be more flexible
 (e.g. with posibility to define additional properties in some single
 place like tempest.conf file)?

Is it difficult to make these properties upstream?
Vendor specific properties will make API different between clouds, and
that will make the interoperability difficult.
There was a defcore(interoperability) discussion also related to this:
http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html

As the above mails, current schemas are blocking additional properties for
* (community devs) accidental additional properties without a new microversion
* (interoperability) vendor-specific properties

Technically, it is possible to relax this additional properties
validation on Tempest side because we have implemented similar feature
on Nova side[1].
But before that, I'd like to know whether that is a right direction or not.

Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/193858/

__
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] Midcycle Sprint Summary

2015-08-18 Thread Jay S. Bryant


Great summary.  We covered a lot of ground.

Thanks Mike!

On 08/17/2015 10:53 AM, Mike Perez wrote:

A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
Full meeting notes available [1].

Image Caching
=
Glance Cinder backend store + Cinder Image Caching are so similar, it would
just be confusing to operators. We'll document only about the Cinder Image
Caching since the Glance backend store is limited in comparison.


Revisit Spec Review
===
The PTL in the future will be the only one to +2/A specs after sufficient +1's
have been given, and notice of approval to follow in the Cinder meeting.


When Specs and Blueprints are needed

Done https://wiki.openstack.org/wiki/Cinder/how-to-contribute-new-feature


People can guess UUID's that don't belong to them
=
Who cares. In past security discussions this has been a moot point.


Update Hypervisor about extending attached volumes
==
Add support to os-brick, but the Nova team has to be fine with this only
supporting Libvirt for now.


Microversions
=
We're doing it.


Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


Third Party CI for target drivers and zone manager drivers
==
Yes. This is already happening for Brocade and Cisco in Liberty!


Cinder - Nova API communication
=
Agreed on how the Cinder API should be used. It requires changes and
a Microversion bump on the Nova side. Design summit session to follow.


Out of tree drivers
===
No.


Exposing force-detach of a volumes
==
Yes, this will be in nova-manage in Liberty.


HA and Cinder
=
We need cross project consensus first. There are existing issues that can be
fixed without a DLM. Fix those first. Mike Perez will be leading cross project 
discussion at the summit.


Replication V2
==
John Griffith did extreme programming with the group and posted a review.
A limited replication feature with async and manual failover should be in
Liberty.


ABC classes for each driver feature
===
Keeping the current solution [2].


[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-June/067563.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

Re: [openstack-dev] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-18 Thread John Griffith

On Tue, Aug 18, 2015 at 2:14 PM, Robert Collins robe...@robertcollins.net
wrote:

 On 19 August 2015 at 03:51, Sean Dague s...@dague.net wrote:

  So... I'm at Linux Con this week, meaning that things will be slow. I
  think - https://review.openstack.org/#/c/208582/ (slightly updated this
  morning) will get devstack users working again. And I agree, we really
  need devstack and the gate to be convergent on their solution here, not
  divergent.

 So unless something has changed, devstack users are broken only on
 Fedora - and the constraints thing won't protect them at this stage
 because of two things.

 Firstly, the bug isn't a cryptography bug - its a setuptools / pip
 thing resulting in the .so pip installs being in the arch neutral path
 rather than lib64, and this would work except that devstack also
 installs python-cffi, which then masks the pip updated one. I don't
 know why devstack is installing the binary package :/. This is a
 Fedora platform specific bug - it doesn't show up on Ubuntu - either
 because devstack doesn't install the ubuntu python-cffi package, or
 because pip/setuptools on ubuntu don't have the same disconnect with
 system packages in the same way. I'm not sure which.

 Secondly, until we have a gate on openstack/requirements that checks
 devstack-on-fedora, fedora developers will be exposed to this sort of
 thing from time to time :/.

 -Rob

 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 __
 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

Catching up on this thread, looks like the referenced devstk change above
(987dc6453e8e3a8a46d748059378564c42bafc5c) merged and broke things.  Seems
we don't install opt/stack/requirements so stack.sh is failing for third
party CI's that don't use node-pool (suspect they'll fail when they're
nodes are rebuilt similar to last weeks issue with keystone).

Went ahead and confirmed that a fresh download and stack.sh locally fails,
going to have a look after dinner but thought maybe somebody already knows
what's up with this.

Thanks,
John
__
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-deb] Devstack stable/juno fails to install

2015-08-18 Thread Tony Breeds

On Tue, Aug 18, 2015 at 10:04:56PM +, Jeremy Stanley wrote:
 On 2015-08-18 15:48:08 -0500 (-0500), Matt Riedemann wrote:
 [...]
  You'd also have to raise the cap on swiftclient in g-r stable/juno
  to python-swiftclient=2.2.0,2.4.0.
 [...]
 
 Followed by stable point releases of everything with a stable/juno
 branch and a {test-,}requirements.txt entry for python-swiftclient.
 Oh, and some of those things might _also_ have overly-strict caps in
 global-requirements.txt, so iterate until clean.

Oh boy ;P
 
Yours Tony.


pgpnyytR0nOp5.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] [stable] [infra] How to auto-generate stable release notes

2015-08-18 Thread Robert Collins

On 18 August 2015 at 01:46, Thierry Carrez thie...@openstack.org wrote:

Following on from the IRC discussion about release notes.

 ttx * we want consumers of the stable branch (from random commit
and from tagged versions) to get a valid release notes document
 ttx * Some things in that document (like OSSA numbers) we only know
after the commit is pushed so we need a way to retroactively fix those

So 'random commit' here is a point in time - I think its reasonable to
assert that if a commit isn't tagged, its release notes are not final.

So before I dive into detail, here's the basic design I think we can use.

1) release notes are derived from the tree/git history. We might
eventually use both, for instance.
2) commits are needed to change release notes.
3) Notes are mutable in that a clone today vs a clone tomorrow might
have different release notes about the same change.
4) Notes are immutable in that for a given git hash/tag the release
notes will be the same. Tagging a commit will change the version
description but that is all.

Design assumptions:
- We want to avoid merge hell when sheparding in a lot of
release-note-worthy changes, which we expect to happen on stable
branches always, and at release times on master branches.
- We want writing a release note to be straight forward
- We do not want release notes to be custom ordered within a release.
As long as the ordering is consistent it is ok.
- We must be able to entirely remove a release note.
- We must not make things progressively slow down to a crawl over
years of usage.

Proposed data structure:
- create a top level directory in each repo called release-notes
- within that create a subdirectory called changes.
- within the release-notes dir we place yaml files containing the
release note inputs.
- within the 'changes' subdirectory, the name of the yaml file will be
the gerrit change id in a canonical form.
   E.g. I1234abcd.yaml
   This serves two purposes: it guarantees file name uniqueness (no
merge conflicts) and lets us
   determine which release to group it in (the most recent one, in
case of merge+revert+merge patterns).
- we also create files that roll up all the notes within history
versions - named by the version. e.g. release-notes/1.2.3.yaml.

Yaml schema:
prelude: prelude prose
notes:
 - note1
 - note2
 - note3

Processing:
1) determine the revisions we need to generate release notes for. By
default generate notes for the current minor release. (E.g. if the
tree version is 1.2.3.dev4 we would generate release notes for 1.2.0,
1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]).
2) For each version: scan all the commits to determine gerrit change-id's.
 i) read in all those change ids .yaml files and pull out any notes within them.
 ii) read in any full version yaml file (and merge in its contained notes)
 iii) Construct a markdown document as follows:
  a) Sort any preludes (there should be only one at most, but lets not
error if there are multiple)
  b) sort any notes
  c) for each note transform it into a bullet point by prepending its
first line with '- ' and every subsequent line with '  ' (two spaces
to form a hanging indent).
  d) strip any trailing \n's from everything.
  e) join the result - '\n'.join(chain(preludes, notes))
 iv) we output the resulting file to release-notes/$version.md where
$version is the pbr reported version for the tree (e.g. in the example
above it would be 1.2.3.dev4, *not* 1.2.3).
3) possibly symlink the highest output version to ./RELEASENOTES.md or
something, so other tooling can look for a constant value.

If we want to put release notes in sdists, we can have pbr do this,
otherwise it could just be built entirely separately.

I recommend we start with it entirely separate: part of the
release-management tooling.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

__
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] Re: New API for node create, specifying initial provision state

 On 17 August 2015 at 20:20, Robert Collins robe...@robertcollins.net
 wrote:

 On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com wrote:
  Hi, sorry for the delay. I vote no. I understand the rationale of
 trying to
  do things so that we don't break our users but that's what the
 versioning is
  meant for and more importantly -- I think adding the ENROLL state is
 fairly
  important wrt the lifecycle of a node. I don't particularly want to
 hide
  that and/or let folks opt out of it in the long term.
 
  From a reviewer point-of-view, my concern is me trying to remember all
 the
  possible permutations/states etc that are possible to make sure that
 new
  code doesn't break existing behavior. I haven't thought out whether
 adding
  this new API would make that worse or not, but then, I don't really
 want to
  have to think about it. So KISS as much as we can! :)

 I'm a little surprised by this, to be honest.

 Here's why: allowing the initial state to be chosen from
 ENROLL/AVAILABLE from the latest version of the API is precisely as
 complex as allowing two versions of the API {old, new} where old
 creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
 difference I can see is that eventually someday if {old} stops being
 supported, then and only then we can go through the code and clean
 things up.

 It seems to me that the costs to us of supporting graceful transitions
 for users here are:

 1) A new version NEWVER of the API that supports node state being one
 of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
 AVAILABLE when not supplied.
 2) Supporting the initial state of AVAILABLE indefinitely rather than
 just until we *delete* version 1.10.
 3) CD deployments that had rolled forward to 1.11 will need to add the
 state parameter to their scripts to move forward to NEWVER.
 4) Don't default the client to the veresions between 1.10 and NEWVER
 versions at any point.

 That seems like a very small price to pay on our side, and the
 benefits for users are that they can opt into the new functionality
 when they are ready.

 -Rob


After thinking about this some more, I'm not actually going to address
Rob's points above. What I want to do is go back and discuss... what do
people think about having an API that allows the initial provision state to
be specified, for a node that is created in Ironic. I'm assuming that
enroll state exists :)

Earlier today on IRC, Devananda mentioned that there's a very strong case
for allowing a node to be created in any of the stable states (enroll,
manageable, available, active). Maybe he'll elaborate later on this. I
know that there's a use case where there is a desire to import nodes (with
instances on them) from another system into ironic, and have them be active
right away. (They don't want the nodes to go from
enroll-verifying-manageable-cleaning!!!-available!!!-active).

1. What would the default provision state be, if it wasn't specified?
A. 'available' to be backwards compatible with pre-v1.11
or
B. 'enroll' to be consistent with v1.11+
or
?


2. What would it mean to set the initial provision state to something other
than 'enroll'?

manageable

In our state machinery[0], a node goes from enroll - verifying -
manageable. For manageble to be initial state, does it mean that
A. whatever is needed for enroll and verifying is done and succeeds (under
the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying)
or
C. no enroll or verifying is done, it goes straight to manageble

I'm fine with A.I'm not sure that B makes sense and I definitely don't
think C makes sense. To date, verifying means checking that the conductor
can get the power state on the node, to verify the supplied power
credentials. I don't think it is a big deal if we skip this step; it just
means that the next time some action is taken on the node, it might fail.

available

In our state machinery, a node goes from enroll - verifying - manageable
- cleaning - available. For available to be initial state, does it mean
that
A. whatever is needed for enroll, verifying, cleaning is done and succeeds
(under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
??

active

In our state machinery, a node goes from enroll - verifying - manageable
- cleaning - available-deploying-active. For active to be initial
state, does it mean that
A. whatever is needed for enroll, verifying, cleaning, deploying is done
and succeeds (under the hood)
or
B. whatever is needed for enroll is done and succeeds (but no verifying or
cleaning)
or
C. whatever is needed for enroll and I dunno, any 'takeover' stuff by
conductor or whatever node states need to be updated to be in active?

--ruby

[0] http://docs.openstack.org/developer/ironic/dev/states.html
__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [cinder] Proposing Gorka Eguileor for core

2015-08-18 Thread Jay S. Bryant


+1

He has been doing good reviews and shown a sustained commitment.

Well done!

Jay

On 08/13/2015 02:13 PM, Mike Perez wrote:

It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

Gorka's contributions to Cinder core have been much apprecated:

https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

60/90 day review stats:

http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

Cinder core, please reply with a +1 for approval. This will be left
open until August 19th. Assuming there are no objections, this will go
forward after voting is closed.




__
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] API: Question on 'Retry-After': 0 in HTTPForbidden

2015-08-18 Thread GHANSHYAM MANN

That is nice point. IMO also Retry-After does not looks good for Quota
error (in all three mentioned case) and actually we are trying to tell
user in case of Quota error, retry this request after 0 sec.

Thanks
Ghanshyam

On Wed, Aug 19, 2015 at 12:34 AM, Chen CH Ji jiche...@cn.ibm.com wrote:
 When doing patch[1] Ken'ichi raise a good suggestion on not raise
 Retry-After according to [2]

 seems nova also when doing create[3] and resize[4] a server nova may raise
 those, too
 is this a bug or something made on purpose? Thanks

 [1]https://review.openstack.org/#/c/180469/5/nova/api/openstack/compute/tenant_networks.py
 [2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
 [3]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L591
 [4]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L846

 Best Regards!

 Kevin (Chen) Ji 纪 晨

 Engineer, zVM Development, CSTL
 Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
 Phone: +86-10-82454158
 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
 Beijing 100193, PRC


 __
 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




-- 
Thanks  Regards
Ghanshyam Mann

__
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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

2015-08-18 Thread Aaron Rosen

+1 to both!  (Sorry missed this email the first go around).

On Fri, Aug 14, 2015 at 10:25 AM, Mark McClain m...@mcclain.xyz wrote:

 +1 to Brandon and Russell.

 mark

 On Aug 13, 2015, at 2:47 PM, Kevin Benton blak...@gmail.com wrote:

 +1

 On Wed, Aug 12, 2015 at 10:43 PM, Akihiro Motoki amot...@gmail.com
 wrote:

 +1 for both.

 2015-08-12 22:45 GMT+09:00 Kyle Mestery mest...@mestery.com:

 It gives me great pleasure to propose Russell Bryant and Brandon Logan
 as core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon
 have both been incredible contributors to Neutron for a while now. Their
 expertise has been particularly helpful in the area they are being proposed
 in. Their review stats [1] place them both comfortably in the range of
 existing Neutron core reviewers. I expect them to continue working with all
 community members to drive Neutron forward for the rest of Liberty and into
 Mitaka.

 Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
 please vote +1/-1 for the addition of Russell and Brandon.

 Thanks!
 Kyle

 [1] http://stackalytics.com/report/contribution/neutron-group/90


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://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://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



 __
 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] [QA][tempest] schema extensions

2015-08-18 Thread Tikkanen, Viktor (Nokia - FI/Espoo)

Thank you for the references!

 -Original Message-
 From: ext Ken'ichi Ohmichi [mailto:ken1ohmi...@gmail.com]
 Sent: Wednesday, August 19, 2015 2:48 AM
...
 Is it difficult to make these properties upstream?
 Vendor specific properties will make API different between clouds, and
 that will make the interoperability difficult.
 There was a defcore(interoperability) discussion also related to this:
 http://lists.openstack.org/pipermail/defcore-committee/2015-
 June/000849.html

I'm afraid that not all the currently used additional properties can
be upstreamed as such (some of them contain e.g. references to vendor's
own SW products) but we will probably discuss this possibility with the
vendor in the future.

 As the above mails, current schemas are blocking additional properties for
 * (community devs) accidental additional properties without a new
 microversion
 * (interoperability) vendor-specific properties
 
 Technically, it is possible to relax this additional properties
 validation on Tempest side because we have implemented similar feature
 on Nova side[1].
 But before that, I'd like to know whether that is a right direction or not.
 
 Thanks
 Ken Ohmichi
 ---
 [1]: https://review.openstack.org/#/c/193858/

IMO it is not a right direction to permanently relax additional properties
validation (for the reasons mentioned above). Actually currently I have to
update only the value of additionalProperties in few places. Of course,
a common parameter like allow_additional_api_properties (or so) would ease
the patching but let's see if somebody else is interested in it...

-Viktor


__
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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

On Tue, Aug 18, 2015 at 04:19:08PM +0200, Jaume Devesa wrote:
 Hi all,
 
 We in Midokura are considering to collaborate on TripleO to provide MidoNet 
 as a
 backend technology for Neutron in the overcloud.
 
 We haven't found any vendor plugin image defined on the
 `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
 So my first question is: Is there willingness from the TripleO folks to accept
 code to deploy third-party vendors?  Alternatively (although not desirable): 
 is
 there any plugin system to work out of the tree?
 
 I'm a noob on TripleO, so I would need some guidance for next steps to follow 
 to
 achieve our goal. I understand that work should be done on these three 
 projects:
 
  * `tripleo-puppet-elements`: we do have a puppet module to configure 
 MidoNet, I
 understand an image to install the packages will be needed.
  * `tripleo-heat-templates`: MidoNet and Neutron specific templates.

I think the pattern for the templates will be similar to the Cisco ML2
plugins which are currently being integrated:

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

The plug-points for third-party configuration is still undergoing some
refinement, but the basic steps are:

1. Ensure you have support in the upstream puppet modules (as mentioned by
Emilien), and figure out the hieradata required to drive puppet as
required.

2. Create a heat template which creates the hieradata, and defines
parameters for all configurable values, e.g like:

https://review.openstack.org/#/c/198754/10/puppet/extraconfig/pre_deploy/controller/network-cisco.yaml

3. Define a heat environment file, which wires in the template from (2) via
the OS::TripleO::ControllerExtraConfigPre interface:

https://review.openstack.org/#/c/198754/10/environments/cisco-nexus-ucsm-plugin.yaml

4. Add the hieradata file deployed via (2) to the controller hierarchy:

https://review.openstack.org/#/c/198754/10/puppet/controller-puppet.yaml

5. Add conditional logic to the manifiests so the appropriate modules from
(1) are included when your backend is enabled:

https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller.pp
https://review.openstack.org/#/c/198754/10/puppet/manifests/overcloud_controller_pacemaker.pp

Basically the way this works is the hieradata is deployed via (2) before
puppet runs, and the manifiest changes in (5) consumes that data when we
apply it during deployment.

  * `tuskar`?: will we need tuskar as well?

No, we're moving away from tuskar and it's not required for third-party
integration such as described above (it's also not covered in CI).

Speaking of CI, it'd be good to discuss how you plan to ensure your stuff
stays working, as clearly we don't have the resources in upstream CI to
test it, having third-party CI jobs vote on TripleO changes would be one
way to solve this, but AFAIK we don't yet have a process in place to enable
this.

Let us know if you need any further help - you can drop in to #tripleo on
Freenode to discuss :)

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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud



On 08/18/2015 10:19 AM, Jaume Devesa wrote:
 Hi all,
 
 We in Midokura are considering to collaborate on TripleO to provide MidoNet 
 as a
 backend technology for Neutron in the overcloud.
 
 We haven't found any vendor plugin image defined on the
 `tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
 So my first question is: Is there willingness from the TripleO folks to accept
 code to deploy third-party vendors?  Alternatively (although not desirable): 
 is
 there any plugin system to work out of the tree?
 
 I'm a noob on TripleO, so I would need some guidance for next steps to follow 
 to
 achieve our goal. I understand that work should be done on these three 
 projects:
 
  * `tripleo-puppet-elements`: we do have a puppet module to configure 
 MidoNet, I
 understand an image to install the packages will be needed.
  * `tripleo-heat-templates`: MidoNet and Neutron specific templates.

For this part, please consider using openstack/puppet-neutron:
https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/midonet.pp

TripleO Heat templates tent to use 100% upstream modules, and not custom
modules or forks.
If you miss some configuration parameters in puppet-neutron, please
submit a patch accordingly.

  * `tuskar`?: will we need tuskar as well?
 
 Am I right?
 
 Cheers,
 

-- 
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] [congress] [murano] Congress jenkins job is failing

2015-08-18 Thread Tim Hinrichs

Looks like we merged a database schema change without the migration
script.  I'm on it.  (We'll get our tempest tests running in gate again
ASAP.)

Tim


On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha filip.bl...@hp.com wrote:

 Hi Congress team.

 Our jenkins job testing integration congress and murano is failing.
 Congress fails to start on some DB error [1] . Does anyone know what
 could be the problem?

 [1]

 http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033

 Thanks
 Filip

 __
 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] [congress] [murano] Congress jenkins job is failing

2015-08-18 Thread Filip Blaha


Hi Congress team.

Our jenkins job testing integration congress and murano is failing. 
Congress fails to start on some DB error [1] . Does anyone know what 
could be the problem?


[1] 
http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033


Thanks
Filip

__
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] [TripleO][Tuskar] Steps to follow to provide MidoNet as Neutron backend in TripleO's overcloud

2015-08-18 Thread Jaume Devesa

Hi all,

We in Midokura are considering to collaborate on TripleO to provide MidoNet as a
backend technology for Neutron in the overcloud.

We haven't found any vendor plugin image defined on the
`tripleo-puppet-elements` nor heat template in the `tripleo-heat-templates`...
So my first question is: Is there willingness from the TripleO folks to accept
code to deploy third-party vendors?  Alternatively (although not desirable): is
there any plugin system to work out of the tree?

I'm a noob on TripleO, so I would need some guidance for next steps to follow to
achieve our goal. I understand that work should be done on these three projects:

 * `tripleo-puppet-elements`: we do have a puppet module to configure MidoNet, I
understand an image to install the packages will be needed.
 * `tripleo-heat-templates`: MidoNet and Neutron specific templates.
 * `tuskar`?: will we need tuskar as well?

Am I right?

Cheers,

-- 
Jaume Devesa
Software Engineer at Midokura

__
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] [zaqar] Ryan Brown to join Zaqar's reviewers team

2015-08-18 Thread Victoria Martínez de la Cruz

+1

So glad to hear about this :)

Ryan has been a great addition to the Zaqar team.

His reviews are very useful and he is always willing to share his knowledge
with everyone in Zaqar's IRC channel.

Thanks Ryan!

All the best,

Victoria

2015-08-17 4:45 GMT-03:00 Flavio Percoco fla...@redhat.com:

 Greetings,

 I'm delighted to announce that Ryan Brown (ryansb) has accepted to
 join Zaqar's core-reviewers team.

 After our last summit (Vancouver), Ryan has dedicated a significant
 amount of time to the project by reviewing patches, which has helped
 the team to keep things consistent.

 Ryan has demonstrated he's familiar with the code base and he has also
 provided valuable support on IRC and reviews not only to existing
 members but also to newcomers. This has increased everyone's trust on
 him to the point his feedback is many times requested on general
 discussions.

 I believe Ryan would be a great addition to our team and I'm happy he
 has accepted to join.

 Unless someone disagrees with the above, I'll proceed to give him the
 required permissions on the project.

 Feedback welcome from anyone at anytime. However, this thread will
 remain valid until Friday, August 21st.

 Thanks, Ryan. Keep it up.
 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


__
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] extension implemented by multiple plugins

2015-08-18 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/18/2015 03:11 PM, Bence Romsics wrote:
 Hi Ihar,
 
 Thank you. Just rebased my patch and following the example of the
 qos feature now I can start neutron-server with both the service
 plugin and the ml2 extension driver loaded. However I have noticed
 that I can no longer mark the extension driver as implementing the
 extension alias (the 'extension_alias' property seems to be better
 not used, or I still have the same error). Is that intentional?
 

I think the assumption is that only one plugin is capable of
implementing an extension. We only allowed to implement no extensions
at all. If you think we should allow multiple plugins to claim support
for the same extension, then it's an additional use case on top of
what we needed in qos. Why do you need it?

BTW feature/qos was merged in master yesterday, so it's now available
for all patches.

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV0zrZAAoJEC5aWaUY1u57DIAIAJG+U3sVI/ejvEmETEtbINH+
mm8IFhpwoSzMNcRKfrlobgmu4R/+saGfQsUaQHjh4ko7PVq2eDH9sMPlHjVZXUGi
x5Rt7gKuFCXsPLyXybjAaaWQjI/hO65/V7D1xwQceRl9FL6kSjgxoasu5ufGUR4j
ZMmp0f9nN8v7VVHynhLq0FEYMqMs0fylO2hnyJKyJUk26Xd1GZqv/58jAl6RaB3Z
LzE6Qd6yO0R4ekEhL4DhBbf3+J59ljDhgCbCvScKiL83IZb0FT4vcYMvuHIKezHt
c23ImDJjz9ZCCld0ah39/jEcqOWj8IM41L/1Qjwdk/Fn/s1CUtFY1vJ28z8IOgg=
=rMZ7
-END 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] [cinder] Proposing Gorka Eguileor for core

2015-08-18 Thread Duncan Thomas

+1
On 17 Aug 2015 18:51, Ivan Kolodyazhny e...@e0ne.info wrote:

 +1.

 Gorka, Thanks for your contribution!

 Regards,
 Ivan Kolodyazhny,
 Web Developer,
 http://blog.e0ne.info/,
 http://notacash.com/,
 http://kharkivpy.org.ua/

 On Sat, Aug 15, 2015 at 6:25 AM, John Griffith john.griffi...@gmail.com
 wrote:



 On Fri, Aug 14, 2015 at 6:06 PM, Walter A. Boring IV 
 walter.bor...@hp.com wrote:

 +1

 It gives me great pleasure to nominate Gorka Eguileor for Cinder core.

 Gorka's contributions to Cinder core have been much apprecated:


 https://review.openstack.org/#/q/owner:%22Gorka+Eguileor%22+project:openstack/cinder,p,0035b6410002dd11

 60/90 day review stats:

 http://russellbryant.net/openstack-stats/cinder-reviewers-60.txt
 http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt

 Cinder core, please reply with a +1 for approval. This will be left
 open until August 19th. Assuming there are no objections, this will go
 forward after voting is closed.




 __
 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


 +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



 __
 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] Functional tests for ironicclient

2015-08-18 Thread Jay Pipes


On 08/18/2015 09:04 AM, Anton Arefiev wrote:

Hi folks,

We have plans to write functional tests for ironicclient. And  the
following question arose :

In current realization, functional test environment uses ironicclient
api directly(client managers), this approach has one problem - it
doesn't include command-line interface code. So it would be better to
use tempest-lib for this. It makes call to ironic with Popen, and has
code for parsing results.


Yeah, both approaches have value. If there are no tests in Tempest 
currently that use the python-ironicclient as a CLI tool (via Popen 
calls), then yes, I would think that would be a welcome addition.


Best,
-jay

__
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] should we allow overcommit for a single VM?

2015-08-18 Thread Chris Friesen


On 08/18/2015 06:56 AM, Nikola Đipanov wrote:

On 08/17/2015 08:22 PM, Chris Friesen wrote:



The basic question is, if a host has X CPUs in total for VMs, and a
single instance wants X+1 vCPUs, should we allow it?  (Regardless of
overcommit ratio.)  There is also an equivalent question for RAM.

Currently we have two different answers depending on whether numa
topology is involved or not.  Should we change one of them to make it
consistent with the other?  If so, a) which one should we change, and b)
how would we do that given that it results in a user-visible behaviour
change?  (Maybe a microversion, even though the actual API doesn't
change, just whether the request passes the scheduler filter or not?)



I would say that the correct behavior is what NUMA fitting logic does,
and that is to not allow instance to over-commit against itself, and we
should fix normal (non-NUMA) over-commit. Allowing the instance to
over-commit against itself does not make a lot of sense, however it is
not something that is likely to happen that often in real world usage -
I would imagine operators are unlikely to create flavors larger than
compute hosts.


This is a good point, in any real deployment it likely won't be an issue.  We 
only ran into it because we were testing on a minimal-sized compute node running 
in a VM on a designer box.



I am not sure that this has anything to do with the API thought. This is
mostly a Nova internal implementation detail. Any nova deployment can
fail to boot an instance for any number of reasons, and this does not
affect the API response of the actual boot request.


Arguably it would be changing the behaviour of a boot request.  Currently it 
would pass the scheduler and boot up, and we're talking about making it fail the 
scheduler filter.  That's an externally-visible change in behaviour.  (But as 
you say it's unlikely that it will be hit in the real world.)


Chris

__
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] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

2015-08-18 Thread Asselin, Ramy

HI Abhi,

There are two ways to build images. The preferred way is to use Disk Image 
Builder (DIB).
These images are built on the same VM that nodepool is run.
When you start nodepool, it will automatically do this for you.
The instructions explain how to do it ‘manually’ which is helpful for debugging 
issues, especially the first time you setup.

Ramy

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com]
Sent: Monday, August 17, 2015 11:32 PM
To: Remo Mattei
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack-in...@lists.openstack.org
Subject: Re: [OpenStack-Infra] [openstack-infra][third-paty][CI][nodepool]Using 
Nodepool for creating slaves.

Hi Remo,

I got the solution for creating images, but my question is do we need to create 
the images in CI master VM or some other VM?

On Tue, Aug 18, 2015 at 11:32 AM, Remo Mattei 
r...@italy1.commailto:r...@italy1.com wrote:
There is a webex scheduled for this topic you want to check it out go to 
Solinea.comhttp://solinea.com

Remo

Inviato da iPhone

Il giorno 18 ago 2015, alle ore 07:41, Abhishek Shrivastava 
abhis...@cloudbyte.commailto:abhis...@cloudbyte.com ha scritto:
Hi Folks,

I was going through Ramy's guide for setting up CI, there I found out the 
following:

  *   
https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves
But I don't get the fact on how to create the image, also what major settings 
need to be done to make the config perfect for use. Can anyone help me with 
that?

--
[Image removed by sender.]
Thanks  Regards,
Abhishek
Cloudbyte Inc.http://www.cloudbyte.com
!DSPAM:1,55d2c5ef145828302144768!
___
OpenStack-Infra mailing list
openstack-in...@lists.openstack.orgmailto:openstack-in...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


!DSPAM:1,55d2c5ef145828302144768!



--
[Image removed by sender.]
Thanks  Regards,
Abhishek
Cloudbyte Inc.http://www.cloudbyte.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-dev] [nova] [libvirt-vif] Extend vhost-user interface to support Cisco Nexus 1000v.

2015-08-18 Thread Kiran Chunduri

Hello All,
We would like to extend the nova 'vhost-user' plug API to attach the port
to Cisco Nexus 1000v, which supports vhost-user interface. Currently the
plug-API supports attaching to OVS. The code I'm referring to is
'plug_vhostuser()' API in 'nova/virt/libvirt/vif.py'.

I would like to submit changes for this. But One of my colleague mentioned
there is a proposal to make the NOVA VIF driver more generic. Can some one
please elaborate on this (or) point to blue-print? I would like to look and
discuss on the proposal.

thanks in advance,
Kiran
__
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][api] New API Guidelines ready for cross project review

2015-08-18 Thread michael mccune


On 08/11/2015 10:28 AM, michael mccune wrote:

1. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/186526/

2. Add advice on when to use POST or PUT in create
https://review.openstack.org/#/c/181912/

3. Clarify the return code when server have hard-code length limit
https://review.openstack.org/#/c/181784/


these guidelines have been merged as per the freeze process guidelines.

guidelines #1 and #2, generated comments that should be addressed in 
follow-up patches.


thanks,
mike


__
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

On 18 August 2015 at 13:08, Lucas Alvares Gomes lucasago...@gmail.com
wrote:

 HI

  Hi, I'd like to make sure I understand. Is it the case that ideally, if
 we
  could go back in time, we'd like to change the client so it defaults to
 1.1?

 AFAIUI, yes

  But since we can't, the next client that we ship/release will have the
 most
  reasonable oldest version? If so, then since the most recent client
 shipped
  is at 1.6, then I think we should put it back to 1.6 even though it is
 1.9
  on master. Regardless of whether there are no backwards incompatible
 changes
  between 1.6  1.9 -- because we need to stick to some
 way-of-doing-things,
  and if we use 1.9, I suspect it will be confusing. At least 1.6 was what
 we
  had at the end of kilo.
 

 The reason why I think we should release with 1.9 is because:

 1) It's already on master and people may be using it already

 2) It's compatible with the previous version that has been released
 already (1.6).

 So it won't break neither users that just get it from pip nor users
 that clone the git repository.


The order of my preference is 1.1 (which is unrealistic as I mention
below), 1.6 (because that's what the client had in kilo release and is the
'closest' version to the server's 1.1), then 1.9 for the reasons you
mentioned above, then 1.10 just cuz it is the last version that is
backwards compatible :-)

Devananda has a patch[0] that changes the client to 1.6, but the reviewers'
comments there point to the mailing list (here) wrt deciding what it should
be so what do other folks think?


  What we're saying is that for M*, N*, O*, ..., the version used in the
  client will be the higher of server's MIN_VER_STR or 1.6, right?
 

 It's a suggestion, if we all agree that the minimal version (1.1) is
 the ideal version to the client to be pinned with when no other
 version is specified, how can we best warn the users that we are going
 to pin to this version for the future releases ?

 Maybe we don't need to do that, but would be good to discuss and have
 a consensus about it.


 I think 1.1 (the server's MIN_VER_STR) is the ideal version for the
client, but I think we missed the boat on that. I don't think it makes much
sense to change things so that the client uses that version in some future
release. The reason being is that kilo was released with the client
defaulting to 1.6. For everyone in cloudland not explicitly specifying a
version, they are using 1.6. And what is different in 1.6 than 1.1 -- we
renamed NOSTATE to AVAILABLE state. I don't think it is worth breaking
existing applications to deprecate/go back to 1.1.

(A separate discussion I'd like to have, is when do we want to change the
server's MIN_VER_STR from 1.1 to eg 1.6 or even gasp, 1.11 when ENROLL made
its appearance).

--ruby

[0] https://review.openstack.org/#/c/208102/
__
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] [third-party] ProphetStor CI account

2015-08-18 Thread Asselin, Ramy

Rick,

These files are missing newlines i.e. unreadable for me: [1] [2] [3]

Out of curiosity, any particular reason you don't set up a log server like 
OpenStack Infra?
I have a script to do that [4], which uses the upstream common solution [5]

Ramy

[1] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/devstacklog.txt.gz
[2] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/etc/cinder/cinder.conf.txt.gz
[3] 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/screen-c-vol.txt.gz
[4] 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/install_log_server.sh
]5] 
http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manifests/logserver.pp



-Original Message-
From: Rick Chen [mailto:rick.c...@prophetstor.com] 
Sent: Monday, August 17, 2015 8:22 AM
To: 'Mike Perez'
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Mike:
I completed to refine our CI configuration to follow Ramy's comments. 
Does any missed or other attention I need respect?

[1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all 
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you 
notify to me.
[4] Integrate VMware snapshot revert feature in the Jenkins master to 
clean CI slave machine OS environment that avoid the devstack building failed 
due to previous devstack garbage configuration.
[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account:  prophetstor-ci
   gerrit account email:prophetstor...@prophetstor.com

Many thanks.

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com]
Sent: Friday, August 14, 2015 11:41 PM
To: Rick Chen rick.c...@prophetstor.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI account

On 09:44 Aug 14, Rick Chen wrote:
 HI Mike:
   Sorry again, I already add email alert agent in our CI Jenkins
server 
 to capture each failed build result.
   [1] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0192.h
 tml
   [2] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0193.h
 tml
   Solution 1: Our Jenkins client machine is vmware machine, I already 
 add snapshot revert script in the Jenkins Job script. Each git review job
 trigger the client will revert to  clean environment
 to solve this problem.
   Solution 2: I don't know whiched changed to make keystone unable to

 import pastedeploy. So I try to uninstall python-pastedeploy package 
 in the local to solve some
issue about unable to build devstack issue.
   Sorry again to disturb you.

Rick,

I looked at your CI results directory [1], but it looks like the last time this 
ran was on July 28th according to the last modified dates. This should be 
actively running even if you account is disabled from leaving comments, so I 
can verify from the logs things are running fine again.

In addition, see Ramy's comments with issues with the CI [2].

[1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A
[2] -
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.html

--
Mike Perez


__
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] [congress] [murano] Congress jenkins job is failing

2015-08-18 Thread Tim Hinrichs

Hi Filip,

I just submitted a revert of the problematic change.  Once it merges, all
should be well again.  Sorry for the trouble.

Tim

On Tue, Aug 18, 2015 at 7:57 AM Tim Hinrichs t...@styra.com wrote:

 Looks like we merged a database schema change without the migration
 script.  I'm on it.  (We'll get our tempest tests running in gate again
 ASAP.)

 Tim


 On Tue, Aug 18, 2015 at 7:36 AM Filip Blaha filip.bl...@hp.com wrote:

 Hi Congress team.

 Our jenkins job testing integration congress and murano is failing.
 Congress fails to start on some DB error [1] . Does anyone know what
 could be the problem?

 [1]

 http://logs.openstack.org/08/211608/3/check/gate-murano-congress-devstack-dsvm/db1b682/logs/screen-congress.txt.gz#_2015-08-18_10_17_05_033

 Thanks
 Filip

 __
 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] [devstack] Possible issues cryptography 1.0 and os-client-config 1.6.2

2015-08-18 Thread Sean Dague

On 08/14/2015 02:52 AM, Chris Dent wrote:
 On Fri, 14 Aug 2015, Clint Byrum wrote:
 
 The same is true for these bugs. Yes they're real, yes more orgs should
 devote developers to fixing them.
 
 This may be the root of my concern and something that we're going to
 have to address sooner than later.
 
 Your concerns are valid and appreciated. However, I think the side
 effect of not setting it is wasting developer time on a large scale. The
 side effect of setting it is putting that work into a queue which an
 appropriately sized subset of developers can manage.
 
 Makes sense, for the most part. Thanks to you and Robert for taking
 the thread through its paces and getting the thinking out in the
 open.

So... I'm at Linux Con this week, meaning that things will be slow. I
think - https://review.openstack.org/#/c/208582/ (slightly updated this
morning) will get devstack users working again. And I agree, we really
need devstack and the gate to be convergent on their solution here, not
divergent.

-Sean

-- 
Sean Dague
http://dague.net



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] [puppet] weekly meeting #47