date:20150330

On 03/30/2015 09:25 AM, Assaf Muller wrote:
 
 
 - Original Message -
 On 03/27/2015 11:48 AM, Assaf Muller wrote:


 - Original Message -
 On 03/27/2015 05:22 AM, Thierry Carrez wrote:
 snip
 Part of it is corner (or simplified) use cases not being optimally
 served by Neutron, and I think Neutron could more aggressively address
 those. But the other part is ignorance and convenience: that Neutron
 thing is a scary beast, last time I looked into it I couldn't make sense
 of it, and nova-network just works for me.

 That is why during the Ops Summit we discussed coming up with a
 migration guide that would explain the various ways you can use Neutron
 to cover nova-network use cases, demystify a few dark areas, and outline
 the step-by-step manual process you can go through to migrate from one
 to the other.

 We found a dev/ops volunteer for writing that migration guide but he was
 unfortunately not allowed to spend time on this. I heard we have new
 volunteers, but I'll let them announce what their plans are, rather than
 put words in their mouth.

 This migration guide can happen even if we follow the nova-net spinout
 plan (for the few who want to migrate to Neutron), so this is a
 complementary solution rather than an alternative. Personally I doubt
 there would suddenly be enough people interested in nova-net development
 to successfully spin it out and maintain it. I also agree with Russell
 that long-term fragmentation at this layer of the stack is generally not
 desirable.

 I think if you boil everything down, you end up with 3 really important
 differences.

 1) neutron is a fleet of services (it's very micro service) and every
 service requires multiple and different config files. Just configuring
 the fleet is a beast if it not devstack (and even if it is)

 2) neutron assumes a primary interesting thing to you is tenant secured
 self service networks. This is actually explicitly not interesting to a
 lot of deploys for policy, security, political reasons/restrictions.

 3) neutron open source backend defaults to OVS (largely because #2). OVS
 is it's own complicated engine that you need to learn to debug. While
 Linux bridge has challenges, it's also something that anyone who's
 worked with Linux  Virtualization for the last 10 years has some
 experience with.

 (also, the devstack setup code for neutron is a rats nest, as it was
 mostly not paid attention to. This means it's been 0 help in explaining
 anything to people trying to do neutron. For better or worse devstack is
 our executable manual for a lot of these things)

 so that being said, I think we need to talk about minimum viable
 neutron as a model and figure out how far away that is from n-net. This
 week at the QA Sprint, Dean, Sean Collins, and I have spent some time
 hashing it out, hopefully with something to show the end of the week.
 This will be the new devstack code for neutron (the old lib/neutron is
 moved to lib/neutron-legacy).

 Default setup will be provider networks (which means no tenant
 isolation). For that you should only need neutron-api, -dhcp, and -l2.
 So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
 like to revert back to linux bridge for the base case (though first code
 will probably be OVS because that's the happy path today).


 Looking at the latest user survey, OVS looks to be 3 times as popular as
 Linux bridge for production deployments. Having LB as the default seems
 like an odd choice. You also wouldn't want to change the default before
 LB is tested at the gate.

 Sure, actually testing defaults is presumed here. I didn't think it
 needed to be called out separately.
 
 Quick update about OVS vs LB:
 Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
 https://review.openstack.org/#/c/168423/
 
 So far it's failing pretty badly.
That is the nature of development.

Let's also note that is patchset 1 of a patch marked work in progress.

If we start to make decisions about whether or not a direction is a
reasonable direction on a patch which is expected to fail this early in
the development process we serious injure our ability to foster development.

Please understand and respect the development process prior to expecting
others to make decisions prematurely.

Thank you,
Anita.
 

  -Sean

 --
 Sean Dague
 http://dague.net


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

 
 __
 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][Neutron] Status of the nova-network to Neutron migration work

On 03/26/2015 06:31 PM, Michael Still wrote:
Hi,

I thought it would be a good idea to send out a status update for the
migration from nova-network to Neutron, as there hasn't been as much
progress as we'd hoped for in Kilo. There are a few issues which have
been slowing progress down.

First off, creating an all encompassing turn key upgrade is probably
not possible. This was also never a goal of this effort -- to quote
the spec for this work, Consequently, the process described here is
not a “one size fits all” automated push-button tool but a series of
steps that should be obvious to automate and customise to meet local
needs [1]. The variety of deployment and configuration options
available makes a turn key migration very hard to write, and possibly
impossible to test. We therefore have opted for writing migration
tools, which allow operators to plug components together in the way
that makes sense for their deployment and then migrate using those.

However, talking to operators at the Ops Summit, is has become clear
that some operators simply aren't interested in moving to Neutron --
largely because they either aren't interested in tenant networks, or
have corporate network environments that make deploying Neutron very
hard. So, even if we provide migration tools, it is still likely that
we will end up with loyal nova-network users who aren't interested in
moving. From the Nova perspective, the end goal of all of this effort
is to delete the nova-network code, and if we can't do that because
some people simply don't want to move, then what is gained by putting
a lot of effort into migration tooling?

Therefore, there is some talk about spinning nova-network out into its
own project where it could continue to live on and be better
maintained than the current Nova team is able to do. However, this is
a relatively new idea and we haven't had a chance to determine how
feasible it is given where we are in the release cycle. I assume that
if we did this, we would need to find a core team passionate about
maintaining nova-network, and we would still need to provide some
migration tooling for operators who are keen to move to Neutron.
However, that migration tooling would be less critical than it is now.

Unfortunately, this has all come to a head at a time when the Nova
team is heads down getting the Kilo release out the door. We simply
don't have the time at the moment to properly consider these issues.
So, I'd like to ask for us to put a pause on this current work until
we have Kilo done. These issues are complicated and important, so I
feel we shouldn't rush them at a time we are distracted.

Finally, I want to reinforce that the position we currently find
ourselves in isn't because of a lack of effort. Oleg, Angus and Anita
have all worked very hard on this problem during Kilo, and it is
frustrating that we haven't managed to find a magic bullet to solve
all of these problems. I want to personally thank each of them for
their efforts this cycle on this relatively thankless task.

I'd appreciate other's thoughts on these issues.

Michael

1:
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/migration-from-nova-net.html#impact-limitations

Thank you, Michael, for this post.

It is clear that we need some additional discussion and agreement here,
and I welcome the discussion.

It is disheartening to try to create an implementation that won't
achieve the goal.

I too would like to thank everyone who has worked hard to try to create
a migration path with the understanding we had been operating with, my
thanks to each of you.

I have placed the weekly nova-net to neutron migration meeting on
hold[0], pending the outcome of this or other discussions and some
additional direction.

Thank you to all participating,
Anita.

[0] https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration

__
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] Host maintenance notification

2015-03-30 Thread Tim Gao

Hi, Balázs

I have the same scenario with you. AFAIK, notifications in Nova does not
support some thing like service enable/disable action. These APIs do
nothing more than saving new value to database. But I believe supporting
these kind of notifications will not be very complicated.

To the second question, exactly yes. You can get inspiration from OpenStack
Ceilometer, stacktach. These project have already listened on OpenStack
message bus to get notifications, then do some awesome job. You can find
some thing interesting from here (
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-notifications.html
)

2015-03-30 18:16 GMT+08:00 Balázs Gibizer balazs.gibi...@ericsson.com:

 Hi,

 I have the following scenario. I have an application consisting of
 multiple VMs on different compute hosts. The admin puts one of the hosts
 into maintenance mode (nova-manage service disable ...) because there will
 be some maintenance activity on that host in the near future. Is there a
 way to  get a notification from Nova when a host is put into maintenance
 mode?
 If it is not the case today would the nova community support such an
 addition to Nova?

 As a subsequent question is there a way for an external system to listen
 to such a notification published on the message bus?

 Thanks in advance.
 Cheers,
 Gibi



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




-- 
Best regards,
Tim Gao
__
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] [Sahara] Question about Sahara API v2

2015-03-30 Thread Sergey Lukjanov

Hi,

in a few words - we're finding out some places that were designed not very
well (or our vision changed) and so we'd like to update the API to have a
much better interface to work with Sahara. The blueprint you've listed was
created in Atlanta summit timeframe and so it's not actual now.

My personal opinion for API 2.0 - we should discuss design of all object
and endpoint, review how they are used from Horizon or python-saharaclient
and improve them as much as possible. For example, it includes:

* get rid of tons of extra optional fields
* rename Job - Job Template, Job Execution - Job
* better support for Horizon needs
* hrefs

If you have any ideas ideas about 2.0 - please write them up, there is a
99% chance that we'll discuss an API 2.0 a lot on Vancouver summit.

Thanks.

On Mon, Mar 30, 2015 at 5:34 AM, Chen, Ken ken.c...@intel.com wrote:

  Hi all,

 Recently I have read some contents about Sahara API v2 propose, but I am
 still a bit confused why we are doing so at this stage. I read the bp
 https://blueprints.launchpad.net/sahara/+spec/v2-api-impl and the
 involved gerrit reviews (although already abandoned). However, I did not
 find anything new than current v1+v1.1 APIs. So why do we want v2 API? Just
 to combine v1 and v1.1 APIs? Is there any deeper requirement or background
 needs us to do so? Please let me know that if yes.

 Btw, I also see some comments that we may want to introduce PECAN to
 implement Sahara APIs. Will that be soon in Liberty, or not decided yet?



 Thanks a lot.

 -Ken

 __
 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




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

2015-03-30 Thread Jesse Pretorius

On 25 March 2015 at 15:24, Kevin Carter kevin.car...@rackspace.com wrote:

 I would like to nominate Nolan Brubaker (palendae on IRC) for the
 os-ansible-deployment-core team. Nolan has been involved with the project
 for the last few months and has been an active reviewer with solid reviews.
 IMHO, I think he is ready to receive core powers on the repository.

 References:
   [
 https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z
 ]

 Please respond with +1/-1s or any other concerns.


+1 Nolan's been an active reviewer, provided good feedback and
contributions.
__
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] Liberty Specs are now open!

2015-03-30 Thread Kyle Mestery

Hi all!

The patch to open up Liberty specs in neutron-specs has now merged [1], so
we're now accepting specs for Neutron targeting the Liberty release. Please
note the process has changed slightly, as indicated in this patch [2]. If a
patch was submitted for Kilo and didn't make it, I've got a review out [3]
which moves these specs to a kilo-backlog directory. They will be preserved
there.

If you previously proposed a spec which didn't land in Kilo and you want to
propose it for Liberty, wait for this patch [3] to land (or rebase your
change on top of it) and you can simply propose to move your spec from
kilo-backlog into liberty. We'll review and try to fast-track that one into
Liberty.

Please note Liberty itself isn't open for development yet until we cut the
RC branch sometime soon. I'll send another note when that happens.

Happy coding!

Thanks
Kyle

[1] https://review.openstack.org/#/c/165116/
[2] https://review.openstack.org/#/c/168434/
[3] https://review.openstack.org/#/c/168351/
__
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] meaning of 'Triaged' in bug tracker

2015-03-30 Thread Davanum Srinivas

+1 Sean!

On Mon, Mar 30, 2015 at 10:00 AM, Sean Dague s...@dague.net wrote:
 I've been attempting to clean up the bug tracker, one of the continued
 inconsistencies that are in the Nova tracker is the use of 'Triaged'.


 https://wiki.openstack.org/wiki/BugTriage

 If the bug contains the solution, or a patch, set the bug status to
 Triaged


 In OpenStack the Triaged state means the solution is provided in the bug
 at enough specification that a patch can be spun. We're ignoring the
 Launchpad language here specifically.

 We had about 180 bugs in Triaged this morning, some untouched for 2
 years. I'm moving everything that looks valid without a solution to
 'Confirmed'. A bunch of other issues look like they can be invalidated
 in the process (through code greps).

 In future, please be careful about putting things into Triaged that
 don't have a solution. Triaged should always end up as a pretty small
 number of things.

 -Sean

 --
 Sean Dague
 http://dague.net

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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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][Neutron] Status of the nova-network to Neutron migration work

On 03/26/2015 08:58 PM, Russell Bryant wrote:
 On 03/26/2015 06:31 PM, Michael Still wrote:
 Hi,

 I thought it would be a good idea to send out a status update for the
 migration from nova-network to Neutron, as there hasn't been as much
 progress as we'd hoped for in Kilo. There are a few issues which have
 been slowing progress down.
 
 Thanks for writing up the status!
 
 First off, creating an all encompassing turn key upgrade is probably
 not possible. This was also never a goal of this effort -- to quote
 the spec for this work, Consequently, the process described here is
 not a “one size fits all” automated push-button tool but a series of
 steps that should be obvious to automate and customise to meet local
 needs [1]. The variety of deployment and configuration options
 available makes a turn key migration very hard to write, and possibly
 impossible to test. We therefore have opted for writing migration
 tools, which allow operators to plug components together in the way
 that makes sense for their deployment and then migrate using those.
 
 Yes, I'm quite convinced that it will end up being a fairly custom
 effort for virtually all deployments complex enough where just starting
 over or cold migration isn't an option.
 
 However, talking to operators at the Ops Summit, is has become clear
 that some operators simply aren't interested in moving to Neutron --
 largely because they either aren't interested in tenant networks, or
 have corporate network environments that make deploying Neutron very
 hard. 
 
 I totally get point #1: nova-network has less features, but I don't
 need the rest, and nova-network is rock solid for me.
 
 I'm curious about the second point about Neutron being more difficult to
 deploy than nova-network.  That's interesting because it actually seems
 like Neutron is more flexible when it comes to integration with existing
 networks.  Do you know any more details?  If not, perhaps those with
 that concern could fill in with some detail here?
 
 So, even if we provide migration tools, it is still likely that
 we will end up with loyal nova-network users who aren't interested in
 moving. From the Nova perspective, the end goal of all of this effort
 is to delete the nova-network code, and if we can't do that because
 some people simply don't want to move, then what is gained by putting
 a lot of effort into migration tooling?
 
 To me it comes down to the reasons people don't want to move.  I'd like
 to dig into exactly why people don't want to use Neutron.  If there are
 legitimate reasons why nova-network will work better, then Neutron has
 not met parity and we're certainly not ready to deprecate nova-network.
 
 I still think getting down to a single networking project should be the
 end goal.  The confusion around networking choices has been detrimental
 to OpenStack.
I heartily agree.

Here is my problem. I am getting the feeling from the big tent
discussions (now this could be my fault since I don't know as it is in
the proposal or just the stuff people are making up about it) that we
are allowing more than one networking project in OpenStack. I have been
disappointed with that impression but that has been the impression I
have gotten.

I'm glad to hear you have a different perspective on this, Russell, and
would just like to clarify this point.

Are we saying that OpenStack has one networking option?

Thanks,
Anita.
 
 Therefore, there is some talk about spinning nova-network out into its
 own project where it could continue to live on and be better
 maintained than the current Nova team is able to do. However, this is
 a relatively new idea and we haven't had a chance to determine how
 feasible it is given where we are in the release cycle. I assume that
 if we did this, we would need to find a core team passionate about
 maintaining nova-network, and we would still need to provide some
 migration tooling for operators who are keen to move to Neutron.
 However, that migration tooling would be less critical than it is now.
 
 From a purely technical perspective, it seems like quite a bit of work.
  It reminds me of we'll just split the scheduler out, and we see how
 long that's taking in practice.  I really think all of that effort is
 better spent just improving Neutron.
 
 From a community perspective, I'm not thrilled about long term
 fragmentation for such a fundamental piece of our stack.  So, I'd really
 like to dig into the current state of gaps between Neutron and
 nova-network.  If there were no real gaps, there would be no sensible
 argument to keep the 2nd option.
 
 Unfortunately, this has all come to a head at a time when the Nova
 team is heads down getting the Kilo release out the door. We simply
 don't have the time at the moment to properly consider these issues.
 So, I'd like to ask for us to put a pause on this current work until
 we have Kilo done. These issues are complicated and important, so I
 feel we shouldn't rush them at a time we are

Re: [openstack-dev] [QA] How will Tempest discover/run tests migrated to specific projects?

2015-03-30 Thread Matthew Treinish

On Mon, Mar 30, 2015 at 12:21:18PM +0530, Rohan Kanade wrote:
Since tests can now be removed from Tempest
https://wiki.openstack.org/wiki/QA/Tempest-test-removal and migrated to
their specific projects.

Does Tempest plan to discover/run these tests in tempest gates? If yes, how
is that going to be done? Will there be a discovery mechanism in Tempest
to discover tests from individual projects?

No, the idea behind that wiki page is to outline the procedure for finding
something that is out of scope and doesn't belong in tempest and is also safe
to remove from the tempest jobs. The point of going through that entire
procedure is that the test being removed should not be run in the tempest gates
anymore and will become the domain of the other project.

Also, IMO the moved test ideally won't be in the same pattern of a tempest test
or have the same constraints of a tempest test and would ideally be more coupled
to the project under test's internals. So that wouldn't be appropriate to
include in a tempest run either.

For example, the first test we removed with that procedure was:

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

which removed the flavor negative tests from tempest. These were just testing
operations that would go no deeper than Nova's DB layer. Which was something
we couldn't verify in tempest. They also didn't really belong in tempest because
they were just implicitly verifying Nova's DB layer through API responses. The
replacement tests:

http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/functional/wsgi/test_flavor_manage.py

were able to verify the state of the DB was correct and ensure the correct
behavior both in the api and nova's internals. This kind of testing is something
which doesn't belong in tempest or any other external test suite. It is also
what I feel we should be targeting for with project specific in-tree functional
testing and the kind of thing we should be using the removal process on that
wiki page for.

-Matt Treinish

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

Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

2015-03-30 Thread Assaf Muller



- Original Message -
 On 03/30/2015 09:25 AM, Assaf Muller wrote:
  
  
  - Original Message -
  On 03/27/2015 11:48 AM, Assaf Muller wrote:
 
 
  - Original Message -
  On 03/27/2015 05:22 AM, Thierry Carrez wrote:
  snip
  Part of it is corner (or simplified) use cases not being optimally
  served by Neutron, and I think Neutron could more aggressively address
  those. But the other part is ignorance and convenience: that Neutron
  thing is a scary beast, last time I looked into it I couldn't make
  sense
  of it, and nova-network just works for me.
 
  That is why during the Ops Summit we discussed coming up with a
  migration guide that would explain the various ways you can use Neutron
  to cover nova-network use cases, demystify a few dark areas, and
  outline
  the step-by-step manual process you can go through to migrate from one
  to the other.
 
  We found a dev/ops volunteer for writing that migration guide but he
  was
  unfortunately not allowed to spend time on this. I heard we have new
  volunteers, but I'll let them announce what their plans are, rather
  than
  put words in their mouth.
 
  This migration guide can happen even if we follow the nova-net spinout
  plan (for the few who want to migrate to Neutron), so this is a
  complementary solution rather than an alternative. Personally I doubt
  there would suddenly be enough people interested in nova-net
  development
  to successfully spin it out and maintain it. I also agree with Russell
  that long-term fragmentation at this layer of the stack is generally
  not
  desirable.
 
  I think if you boil everything down, you end up with 3 really important
  differences.
 
  1) neutron is a fleet of services (it's very micro service) and every
  service requires multiple and different config files. Just configuring
  the fleet is a beast if it not devstack (and even if it is)
 
  2) neutron assumes a primary interesting thing to you is tenant secured
  self service networks. This is actually explicitly not interesting to a
  lot of deploys for policy, security, political reasons/restrictions.
 
  3) neutron open source backend defaults to OVS (largely because #2). OVS
  is it's own complicated engine that you need to learn to debug. While
  Linux bridge has challenges, it's also something that anyone who's
  worked with Linux  Virtualization for the last 10 years has some
  experience with.
 
  (also, the devstack setup code for neutron is a rats nest, as it was
  mostly not paid attention to. This means it's been 0 help in explaining
  anything to people trying to do neutron. For better or worse devstack is
  our executable manual for a lot of these things)
 
  so that being said, I think we need to talk about minimum viable
  neutron as a model and figure out how far away that is from n-net. This
  week at the QA Sprint, Dean, Sean Collins, and I have spent some time
  hashing it out, hopefully with something to show the end of the week.
  This will be the new devstack code for neutron (the old lib/neutron is
  moved to lib/neutron-legacy).
 
  Default setup will be provider networks (which means no tenant
  isolation). For that you should only need neutron-api, -dhcp, and -l2.
  So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
  like to revert back to linux bridge for the base case (though first code
  will probably be OVS because that's the happy path today).
 
 
  Looking at the latest user survey, OVS looks to be 3 times as popular as
  Linux bridge for production deployments. Having LB as the default seems
  like an odd choice. You also wouldn't want to change the default before
  LB is tested at the gate.
 
  Sure, actually testing defaults is presumed here. I didn't think it
  needed to be called out separately.
  
  Quick update about OVS vs LB:
  Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
  https://review.openstack.org/#/c/168423/
  
  So far it's failing pretty badly.
 That is the nature of development.
 
 Let's also note that is patchset 1 of a patch marked work in progress.
 
 If we start to make decisions about whether or not a direction is a
 reasonable direction on a patch which is expected to fail this early in
 the development process we serious injure our ability to foster development.
 
 Please understand and respect the development process prior to expecting
 others to make decisions prematurely.
 

I was providing a status report, nothing more.

 Thank you,
 Anita.
  
 
 -Sean
 
  --
  Sean Dague
  http://dague.net
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  
  __
  OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [kolla] Re: Questions about kolla

2015-03-30 Thread Steven Dake (stdake)

From: Chmouel Boudjnah chmo...@chmouel.commailto:chmo...@chmouel.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, March 30, 2015 at 6:52 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Chylinski, Arek 
arek.chylin...@intel.commailto:arek.chylin...@intel.com, Stachowski, 
Michal michal.stachow...@intel.commailto:michal.stachow...@intel.com
Subject: Re: [openstack-dev] [kolla] Re: Questions about kolla

On Mon, Mar 30, 2015 at 3:42 PM, Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:
We plan to dockerize any service needed to deploy OpenStack.  We haven’t 
decided if that includes ceph, since ceph may already be dockerized by someone 
else.  But it does include the HA services we need as well as the rest of the 
OpenStack services.

it is and available here, https://github.com/ceph/ceph-docker

Looks pretty good.  Too bad it uses Ubuntu 14.04 as a userspace – in Kolla we 
want to support both CentOS and Ubuntu as a userspace.  But this gap should be 
easy to solve.

I really dislike the bindmounting of /etc and /var/lib/ceph.  /etc should be 
passed via environment and /var/lib/ceph should be a data container to maintain 
the idempotency, immutability, and declarative nature of containers.

Thanks for the link!

Regards
-steve

(Seb in Cc of this email is the one who have been working on this)

Chmouel
__
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] [kolla] Kolla milestone 3 was busted for Ubuntu 14.04 - fixed in master

2015-03-30 Thread Steven Dake (stdake)

Hey folks,

We got a lot of complaints for folks trying to run Kolla on Ubuntu 14.04 with 
3.13 kernel.  Most of the problems were related to kernel bugs or docker bugs.  
We have worked around them, and now Kolla launches like a champ for me on 14.04.

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

Re: [openstack-dev] [os-ansible-deployment] Nominating Nolan Brubaker for core team

2015-03-30 Thread Kevin Carter

Please join me in welcoming Nolan Brubaker (palendae) to the 
os-ansible-deployment core team.

—

Kevin Carter


 On Mar 30, 2015, at 06:54, Jesse Pretorius jesse.pretor...@gmail.com wrote:
 
 On 25 March 2015 at 15:24, Kevin Carter kevin.car...@rackspace.com wrote:
 I would like to nominate Nolan Brubaker (palendae on IRC) for the 
 os-ansible-deployment-core team. Nolan has been involved with the project for 
 the last few months and has been an active reviewer with solid reviews. IMHO, 
 I think he is ready to receive core powers on the repository.
 
 References:
   [ 
 https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment+reviewer:%22nolan+brubaker%253Cnolan.brubaker%2540rackspace.com%253E%22,n,z
  ]
 
 Please respond with +1/-1s or any other concerns.
 
 +1 Nolan's been an active reviewer, provided good feedback and contributions.
 __
 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




signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Barbican : Usage of mode attribute in storing and order the secret

Hi All ,

What is the use of the mode attribute ? what does the value of this
attribute signify and what are the possible values of this attribute?
For ex :Consider the order request to create the secret :

POST v1/orders

Header: content-type=application/json
X-Project-Id: {project_id}
{
  type: key,
  meta: {
name: secretname,
algorithm: AES,
bit_length: 256,
mode: cbc,
payload_content_type: application/octet-stream
  }
}


What does the mode  value cbc  indicate ?
-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Akihiro Motoki

Hi Neutron folks
(API folks may be interested on this)

We have another discussion on Core vs extension in the subnet pool
feature reivew
https://review.openstack.org/#/c/157597/.
We did the similar discussion on VLAN transparency and MTU for a
network model last week.
I would like to share my concerns on changing the core API directly.
I hope this help us make the discussion productive.
Note that I don't want to discuss the micro-versioning because it
mainly focues on Kilo FFE BP.

I would like to discuss this topic in today's neutron meeting,
but I am not so confident I can get up in time, I would like to send this mail.


The extension mechanism in Neutron provides two points for extensibility:
- (a) visibility of features in API (users can know which features are
available through the API)
- (b) opt-in mechanism in plugins (plugin maintainers can decide to
support some feature after checking the detail)

My concerns mainly comes from the first point (a).
If we have no way to detect it, users (including Horizon) need to do a
dirty work around
to determine whether some feature is available. I believe this is one
important point in API.

On the second point, my only concern (not so important) is that we are
making the core
API change at this moment of the release. Some plugins do not consume
db_base_plugin and
such plugins need to investigate the impact from now on.
On the other hand, if we use the extension mechanism all plugins need to update
their extension list in the last moment :-(


My vote at this moment is still to use an extension, but an extension
layer can be a shim.
The idea is to that all implementation can be as-is and we just add an
extension module
so that the new feature is visible thru the extension list.
It is not perfect but I think it is a good compromise regarding the first point.


I know there was a suggestion to change this into the core API in the
spec review
and I didn't notice it at that time, but I would like to raise this
before releasing it.

For longer term (and Liberty cycle),  we need to define more clear guideline
on Core vs extension vs micro-versioning in spec reviews.

Thanks,
Akihiro

__
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] [Manila] FFE Request: glusterfs_native: negotiate volumes with glusterd

2015-03-30 Thread Csaba Henk

Hi,

I'm applying for an FFE for change

https://review.openstack.org/162542 ,
glusterfs_native: negotiate volumes with glusterd.

The change in question is in the grey zone between
a bugfix and a feature. So, having it discussed with
the Manila community and our PTL, Ben Swartzlander,
we decided to defeat ambiguity by putting it
forward as an FFE.

While there is no explicit errant behavior with the
current glusterfs_native driver code that would be
addressed by this change, the situation is that the
current version of the driver is conceptually buggy
-- it does not meet consensual expectations what one
has against a driver. (It would be an overstatement
to call current create_share implementation a stub,
but the issue is something similar.)

One aspect of the limitation of create_share is
captured by this bug:

https://bugs.launchpad.net/manila/+bug/1437176 ,
glusterfs_native: Unable to create shares using newly
available GlusterFS volumes without restarting manila
share service

We are submitting the change as a fix for this.

Impact: the code adds a new, more general mechanism for
picking GlusterFS volumes for backing shares. The new code
is basically contained in one function, _pop_gluster_vol();
the rest of the diff is refactor to adjust the driver to
the new internal API. The impact is isolated and limited
to the glusterfs_native driver. The operation logic of the
driver is not affected beyond backing resource allocation of
in create_share. Unit test coverage is good.

Csaba Henk
Red Hat, Inc.

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

[openstack-dev] [mistral] Team meeting minutes - 03/30/2015

2015-03-30 Thread Renat Akhmerov

Thanks for joining today’s team meeting!

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-03-30-16.23.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-03-30-16.23.html
Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-03-30-16.23.log.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-03-30-16.23.log.html

The next meeting is scheduled for April 6 at 16.20 UTC (temporarily new time)

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Any help would be appreciated ?
Thanks in advance !

Thanks and Regards,
Asha Seshagiri

On Mon, Mar 30, 2015 at 12:45 PM, Asha Seshagiri asha.seshag...@gmail.com
wrote:

 Hi All ,

 What is the use of the mode attribute ? what does the value of this
 attribute signify and what are the possible values of this attribute?
 For ex :Consider the order request to create the secret :

 POST v1/orders

 Header: content-type=application/json
 X-Project-Id: {project_id}
 {
   type: key,
   meta: {
 name: secretname,
 algorithm: AES,
 bit_length: 256,
 mode: cbc,
 payload_content_type: application/octet-stream
   }
 }


 What does the mode  value cbc  indicate ?
 --
 *Thanks and Regards,*
 *Asha Seshagiri*




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

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

2015-03-30 Thread Douglas Mendizabal

Hi Asha,

Barbican Orders of type “key” are intended to generate keys suitable for 
encryption.  The metadata associated with the key order defines the encryption 
scheme in which the key will be used.  In the example you provided, the order 
is requesting a key that is suitable for use in a block cipher.  Specifically 
you’re requesting a key that will be used with the “AES” block cipher, so the 
“mode describes the mode of operation to be used, which in this case is Cipher 
Block Chaining or “CBC”.

Acceptable values for “mode” are dependent on the value of the “algorithm” 
attribute.  When requesting orders for keys to be used in AES encryption, the 
values for “mode” correspond to the other possible modes of operation for AES, 
such as “ECB”, “CTR”, etc.

-Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

On Mar 30, 2015, at 12:46 PM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:

Any help would be appreciated ?
Thanks in advance !

Thanks and Regards,
Asha Seshagiri

On Mon, Mar 30, 2015 at 12:45 PM, Asha Seshagiri 
asha.seshag...@gmail.commailto:asha.seshag...@gmail.com wrote:
Hi All ,

What is the use of the mode attribute ? what does the value of this attribute 
signify and what are the possible values of this attribute?
For ex :Consider the order request to create the secret :


POST v1/orders

Header: content-type=application/json
X-Project-Id: {project_id}
{
  type: key,
  meta: {
name: secretname,
algorithm: AES,
bit_length: 256,
mode: cbc,
payload_content_type: application/octet-stream
  }
}

What does the mode  value cbc  indicate ?
--
Thanks and Regards,
Asha Seshagiri



--
Thanks and Regards,
Asha Seshagiri

__
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] [Manila] FFE Request: glusterfs_native: negotiate volumes with glusterd

2015-03-30 Thread Ben Swartzlander


On 03/30/2015 12:21 PM, Csaba Henk wrote:

Hi,

I'm applying for an FFE for change

https://review.openstack.org/162542 ,
glusterfs_native: negotiate volumes with glusterd.

The change in question is in the grey zone between
a bugfix and a feature. So, having it discussed with
the Manila community and our PTL, Ben Swartzlander,
we decided to defeat ambiguity by putting it
forward as an FFE.

While there is no explicit errant behavior with the
current glusterfs_native driver code that would be
addressed by this change, the situation is that the
current version of the driver is conceptually buggy
-- it does not meet consensual expectations what one
has against a driver. (It would be an overstatement
to call current create_share implementation a stub,
but the issue is something similar.)

One aspect of the limitation of create_share is
captured by this bug:

https://bugs.launchpad.net/manila/+bug/1437176 ,
glusterfs_native: Unable to create shares using newly
available GlusterFS volumes without restarting manila
share service

We are submitting the change as a fix for this.

Impact: the code adds a new, more general mechanism for
picking GlusterFS volumes for backing shares. The new code
is basically contained in one function, _pop_gluster_vol();
the rest of the diff is refactor to adjust the driver to
the new internal API. The impact is isolated and limited
to the glusterfs_native driver. The operation logic of the
driver is not affected beyond backing resource allocation of
in create_share. Unit test coverage is good.

Csaba Henk
Red Hat, Inc.


Thanks for going through the formal request process with this change.

One question I have that's not answered here is: what is the risk of 
delaying this fix to Liberty? Clearly it needs to be fixed eventually, 
but if we hold off and allow Kilo to ship as-is, will anything bad 
happen? From the description above it sounds like the driver is 
functional, and a somewhat awkward workaround (restarting the backend) 
is required to deal with bug 1437176.


Will users be subjected to any upgrade problems going from Kilo to 
Liberty if we don't fix this in Kilo? Will there be any significant 
maintenance problems in the Kilo code if we don't change it?




__
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] 6.1 Soft Code Freeze moved to April 7th

2015-03-30 Thread Eugene Bogdanov


Hello everyone,

We 
http://lp-reports.vm.mirantis.net/custom_report/6.1?status=Newstatus=Incompletestatus=Confirmedstatus=Triagedstatus=In%20Progressimportance=Mediumcurrently 
have 500+ medium priority bugs assigned to 6.1 release. Obviously we 
won't be able to make a big difference within the next 24 hours, so 
let's move the Soft Code Freeze date (last date when medium bug fixes 
are accepted) [1] to April 7th. This will give us some time to apply 
important bug fixes and complete triaging as appropriate. The shift is 
only about Soft Code Freeze (no changes for Hard Code Freeze / GA 
dates). I have updated the release schedule [2] accordingly.


Thank you.

[1] Soft Code Freeze definition: 
https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze
[2] Release schedule: 
https://wiki.openstack.org/wiki/Fuel/6.1_Release_Schedule


--
EugeneB


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

[openstack-dev] [Fuel] Re: 6.1 Soft Code Freeze moved to April 7th

2015-03-30 Thread Christopher Aedo

Note: Modifying the subject line to add the tag Fuel as this message
has gone out to the OpenStack Dev mailing list.

On Mon, Mar 30, 2015 at 10:50 AM, Eugene Bogdanov
ebogda...@mirantis.com wrote:
 Hello everyone,

 We currently have 500+ medium priority bugs assigned to 6.1 release.
 Obviously we won't be able to make a big difference within the next 24
 hours, so let's move the Soft Code Freeze date (last date when medium bug
 fixes are accepted) [1] to April 7th. This will give us some time to apply
 important bug fixes and complete triaging as appropriate. The shift is only
 about Soft Code Freeze (no changes for Hard Code Freeze / GA dates). I have
 updated the release schedule [2] accordingly.

 Thank you.

 [1] Soft Code Freeze definition:
 https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze
 [2] Release schedule:
 https://wiki.openstack.org/wiki/Fuel/6.1_Release_Schedule

 --
 EugeneB



__
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][Neutron] Status of the nova-network to Neutron migration work

2015-03-30 Thread Russell Bryant

On 03/30/2015 10:34 AM, Anita Kuno wrote:
 On 03/26/2015 08:58 PM, Russell Bryant wrote:
 To me it comes down to the reasons people don't want to move.  I'd like
 to dig into exactly why people don't want to use Neutron.  If there are
 legitimate reasons why nova-network will work better, then Neutron has
 not met parity and we're certainly not ready to deprecate nova-network.

 I still think getting down to a single networking project should be the
 end goal.  The confusion around networking choices has been detrimental
 to OpenStack.
 I heartily agree.
 
 Here is my problem. I am getting the feeling from the big tent
 discussions (now this could be my fault since I don't know as it is in
 the proposal or just the stuff people are making up about it) that we
 are allowing more than one networking project in OpenStack. I have been
 disappointed with that impression but that has been the impression I
 have gotten.
 
 I'm glad to hear you have a different perspective on this, Russell, and
 would just like to clarify this point.
 
 Are we saying that OpenStack has one networking option?

I wouldn't say that exactly.  We clearly have two today.  :-)

I don't think anyone intended to have two for as long as we have, and I
feel that has been detrimental to the OpenStack mission.  I'm very
thankful for the ongoing efforts to rectify that situation.

My general feeling about overlap in OpenStack is that it's more costly
the lower we go in the stack.  If we think about the base compute set
of projects (like Nova, Glance, Neutron, Keystone, Cinder), I feel we
should resist overlap there more strongly than we might at the higher
layers.

I think lacking consensus around a networking direction is harmful to
our mission.  I will not say a new networking API should never happen,
but the bar should be high.

In fact, this very debate is happening right now on whether or not the
group based policy project should be accepted as an OpenStack project:

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

-- 
Russell Bryant

__
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][Neutron] Status of the nova-network to Neutron migration work

2015-03-30 Thread Steve Wormley

On Mon, Mar 30, 2015 at 4:49 AM, Jesse Pretorius jesse.pretor...@gmail.com
wrote:

 On 28 March 2015 at 00:41, Steve Wormley openst...@wormley.com wrote:

 2. Floating IPs managed at each compute node(multi-host) and via the
 standard nova API calls.



 2 meant we can't use pure provider VLAN networks so we had to wait for DVR
 VLAN support to work.


 I'm always confused when I see operators mention that provider VLANs can't
 be used in a Neutron configuration. While at my former employer we had that
 setup with Grizzly, and also note that any instance attached to a VLAN
 tagged tenant network did not go via the L3 agent... the traffic was tagged
 and sent directly from the compute node onto the VLAN.

 All we had to do to make this work was to allow VLAN tagged networks and
 the cloud admin had to setup the provider network with the appropriate VLAN
 tag.

As you say, provider networks and VLANs work fine. Provider networks, VLANs
and Openstack managed Floating IP addresses for the same instances do not.

-Steve wormley
__
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][Neutron] Status of the nova-network to Neutron migration work

On 03/30/2015 12:35 PM, Russell Bryant wrote:
 On 03/30/2015 10:34 AM, Anita Kuno wrote:
 On 03/26/2015 08:58 PM, Russell Bryant wrote:
 To me it comes down to the reasons people don't want to move.  I'd like
 to dig into exactly why people don't want to use Neutron.  If there are
 legitimate reasons why nova-network will work better, then Neutron has
 not met parity and we're certainly not ready to deprecate nova-network.

 I still think getting down to a single networking project should be the
 end goal.  The confusion around networking choices has been detrimental
 to OpenStack.
 I heartily agree.

 Here is my problem. I am getting the feeling from the big tent
 discussions (now this could be my fault since I don't know as it is in
 the proposal or just the stuff people are making up about it) that we
 are allowing more than one networking project in OpenStack. I have been
 disappointed with that impression but that has been the impression I
 have gotten.

 I'm glad to hear you have a different perspective on this, Russell, and
 would just like to clarify this point.

 Are we saying that OpenStack has one networking option?
 
 I wouldn't say that exactly.  We clearly have two today.  :-)
 
 I don't think anyone intended to have two for as long as we have, and I
 feel that has been detrimental to the OpenStack mission.  I'm very
 thankful for the ongoing efforts to rectify that situation.
 
 My general feeling about overlap in OpenStack is that it's more costly
 the lower we go in the stack.  If we think about the base compute set
 of projects (like Nova, Glance, Neutron, Keystone, Cinder), I feel we
 should resist overlap there more strongly than we might at the higher
 layers.
 
 I think lacking consensus around a networking direction is harmful to
 our mission.  I will not say a new networking API should never happen,
 but the bar should be high.
 
 In fact, this very debate is happening right now on whether or not the
 group based policy project should be accepted as an OpenStack project:
 
 https://review.openstack.org/#/c/161902/
 
Thank you, Russell. I agree with you and I am grateful that you took the
time to spell it out for the mailing list.

Lack of clarity hurts our users, every decision we make should keep our
users best interests in mind going forward, as you outline in your reply.

Thanks Russell,
Anita.

__
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][Neutron] Status of the nova-network to Neutron migration work

2015-03-30 Thread Steve Wormley

On Sun, Mar 29, 2015 at 6:45 AM, Kevin Benton blak...@gmail.com wrote:

 Does the decision about the floating IP have to be based on the use of the
 private IP in the original destination, or could you get by with rules on
 the L3 agent to avoid NAT just based on the destination being in a
 configured set of CIDRs?

 If you could get by with the latter it would be a much simpler problem to
 solve. However, I suspect you will want the former to be able to connect to
 floating IPs internally as well.

That's one issue. Having systems like monitoring accessing both addresses.
The other, like many other large organizations, is that we have a fairly
large number of disjoint address spaces between all the groups accessing
our cloud. So trying to create and maintain that sort of list, short of a
routing protocol feed, is not easy.

-Steve Wormley
__
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] Find your discount code for Vancouver and register now

2015-03-30 Thread Stefano Maffulli

Folks,

If you have received your discount code to OpenStack summit Vancouver,
stop whatever you're doing and


register *now* 


Admission prices go up to $900 tomorrow and you'll have to pay the
difference. *There will be absolutely no exceptions*.

If you're in doubt if you should have received an invite check

https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/

and if you think you qualify for an invite reply to
communitym...@openstack.org and provide a URL to your merged
contributions. No link to bugs or blueprints: *only merged contributions
matter* and URL to https://review.openstack.org

thanks,
stef


__
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] [Telco][NFV] Update to weekly meeting time commencing this week.

2015-03-30 Thread Steve Gordon

Hi all,

Since the Paris summit the Telco Working Group has been meeting on an 
alternating basis at 1400 UTC and 2200 UTC. As discussed in the last two 
meetings due to low attendance in the 2200 UTC slot, particularly as DST has 
now kicked in for many participants, we are going to trial a slightly earlier 
slot - 1900 UTC - starting this week. Hopefully this will help out those who 
try to attend both while also still catering to those who can't make the 
earlier meeting.

As a result the upcoming schedule is:

* Wednesday 1st April 2015  1900 UTC#openstack-meeting-alt
* Wednesday 8th April 2015  1400 UTC#openstack-meeting-alt
* Wednesday 15th April 2015 1900 UTC#openstack-meeting-alt

I have updated https://wiki.openstack.org/wiki/Meetings and 
https://wiki.openstack.org/wiki/TelcoWorkingGroup#Upcoming_Meetings with these 
details. Feel free to reach out either here or in #openstack-nfv if there are 
any concerns/questions.

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] [Fuel] Nominate Irina Povolotskaya for fuel-docs core

2015-03-30 Thread Dmitry Borodaenko

I think it's safe to conclude that we have a strong consensus in
favor. Congratulations Irina!

All that's left is to merge https://review.openstack.org/168182 so
that we can actually assign core reviewers separately for fuel-docs.

On Sun, Mar 29, 2015 at 11:13 PM, Nikolay Markov nmar...@mirantis.com wrote:
 +1

 29 Мар 2015 г. 20:42 пользователь Sergey Vasilenko
 svasile...@mirantis.com написал:

 +1


 /sv

 On Fri, Mar 27, 2015 at 5:31 PM, Anastasia Urlapova
 aurlap...@mirantis.com wrote:

 + 10

 On Fri, Mar 27, 2015 at 4:28 AM, Igor Zinovik izino...@mirantis.com
 wrote:

 +1

 On 26 March 2015 at 19:26, Fabrizio Soppelsa fsoppe...@mirantis.com
 wrote:
  +1 definitely
 
 
  On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote:
 
  Fuelers,
 
  I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
  She has contributed thousands of lines of documentation to Fuel over
  the past several months, and has been a diligent reviewer:
 
 
 
  http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs
 
  I believe it's time to grant her core reviewer rights in the
  fuel-docs
  repository.
 
  Core reviewer approval process definition:
  https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
 
 
 
 
  __
  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



 --
 Igor Zinovik
 Deployment Engineer at Mirantis, Inc
 izino...@mirantis.com


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




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



 __
 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




-- 
Dmitry Borodaenko

__
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] [ceilometer] upgrades from juno to kilo

2015-03-30 Thread William M Edmonds



I tracked down the cause of the check-grenade-dsvm failure on
https://review.openstack.org/#/c/167370 . As I understand it, grenade is
taking the previous stable release, deploying it, then upgrading to the
current master (plus the proposed changeset) without changing any of the
config from the stable deployment. Thus the policy.json file used in that
test is the file from stable-juno. Then if we look at oslo_policy/policy.py
we see that if the rule being looked for is missing then the default rule
will be used, but then if that default rule is also missing a KeyError is
thrown. Since the default rule was missing with ceilometer's policy.json
file in Juno, that's what would happen here. I assume that KeyError then
gets turned into the 403 Forbidden that is causing check-grenade-dsvm
failure.

I suspect the author of the already-merged
https://review.openstack.org/#/c/115717 did what they did in
ceilometer/api/rbac.py rather than what is proposed in
https://review.openstack.org/#/c/167370 just to get the grenade tests to
pass. I think they got lucky (unlucky for us), too, because I think they
actually did break what the grenade tests are meant to catch. The patch set
which was merged under https://review.openstack.org/#/c/115717 changed the
rule that is checked in get_limited_to() from context_is_admin to
segregation. But the segregation rule didn't exist in the Juno version
of ceilometer's policy.json, so if a method that calls get_limited_to() was
tested after an upgrade, I believe it would fail with a 403 Forbidden
tracing back to a KeyError looking for the segregation rule... very
similar to what we're seeing in https://review.openstack.org/#/c/167370

Am I on the right track here? How should we handle this? Is there a way to
maintain backward compatibility while fixing what is currently broken (as a
result of https://review.openstack.org/#/c/115717 ) and allowing for a fix
for https://bugs.launchpad.net/ceilometer/+bug/1435855 (the goal of
https://review.openstack.org/#/c/167370)? Or will we need to document in
the release notes that the manual step of modifying ceilometer's
policy.json is required when upgrading from Juno, and then correspondingly
modify grenade's upgrade_ceilometer file?


W. Matthew Edmonds
IBM Systems  Technology Group
Email: edmon...@us.ibm.com
Phone: (919) 543-7538 / Tie-Line: 441-7538__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Salvatore Orlando

Akihiro,
thanks for sharing this on the mailing list.

I have some answers inline, but from a community process perspective I have
a feeling that a majority of contributors feel like well established
guidelines have been violated. This has been exacerbated by the fact that
these changes are landing at the end of the release cycle.
If there is a consensus that no change in our API evolution strategy should
occur in Kilo - because no change in this strategy has been agree upon -
then there is little to discuss - any new addition should be an extension.

I reckon the shortcomings of this approach have been communicated enough so
far, but if we are in a stall condition regarding how to evolve the API
then we should resort to the only mechanism that we've used in the past
extensions. This also means - in my opinion - that we should provisionally
revert or hide all core API changes until they're reproposed as extension.
But your proposal about using the extension mechanism to mark that the
feature is enabled for the sake of the API client makes sense and is worth
exploring too.

Salvatore

On 30 March 2015 at 19:35, Akihiro Motoki amot...@gmail.com wrote:

 Hi Neutron folks
 (API folks may be interested on this)

 We have another discussion on Core vs extension in the subnet pool
 feature reivew
 https://review.openstack.org/#/c/157597/.
 We did the similar discussion on VLAN transparency and MTU for a
 network model last week.
 I would like to share my concerns on changing the core API directly.
 I hope this help us make the discussion productive.
 Note that I don't want to discuss the micro-versioning because it
 mainly focues on Kilo FFE BP.

 I would like to discuss this topic in today's neutron meeting,
 but I am not so confident I can get up in time, I would like to send this
 mail.


 The extension mechanism in Neutron provides two points for extensibility:
 - (a) visibility of features in API (users can know which features are
 available through the API)
 - (b) opt-in mechanism in plugins (plugin maintainers can decide to
 support some feature after checking the detail)

 My concerns mainly comes from the first point (a).
 If we have no way to detect it, users (including Horizon) need to do a
 dirty work around
 to determine whether some feature is available. I believe this is one
 important point in API.


This is true regarding VLAN transparency and MTU.
For the latter, it is clearly something that might be not supported. In the
absence of a better mechanism to detect enabled features, I agree it must
be an extension.
For VLAN transparency, the authors claim (from what I understand) that it's
always ok to set it. For deployments with ML2 an exception will be thrown
if no driver is available for implementing a vlan transparent network.
Plugins that do not support it should just ignore the setting. I don't know
how Horizon (or any other client for that matter) will ever realize that
the settings had no effect.

The subnetpool support instead has been implemented in the IPAM logic
contained in db_base_plugin_v2. This is why I supported its addition to the
core API. Basically, since it does not require specific plugin support, it
should always be available, and implemented by all plugins satisfying both
your criteria.
However, there is always an exception represented by plugins which either
override the base class or do not use it at all. When I reviewed the subnet
pool spec there was no plugin in the first category (at least no known
plugin), while I believe only a single plugin in the latter. My thought was
that I would not worry about plugins not included in the repository, but
now that most are not anymore in openstac/neutron this does not apply,
probably.
I still believe that it is ok to assume subnetpools are part of the core
API, but, as stated earlier, if we feel like we are unable to agree
anything about how evolve the API, then the only alternative is to keep
doing things as we've done today - only by extensions.




 On the second point, my only concern (not so important) is that we are
 making the core
 API change at this moment of the release. Some plugins do not consume
 db_base_plugin and
 such plugins need to investigate the impact from now on.
 On the other hand, if we use the extension mechanism all plugins need to
 update
 their extension list in the last moment :-(


Indeed it is always challenging when API changes land at the last milestone
- and it's probably even harder to handle now that the plugins have been
moved out of the main repo. I think this has been a failure of the drivers
and core team and we should address it with the appropriate changes for the
next release cycle.




 My vote at this moment is still to use an extension, but an extension
 layer can be a shim.
 The idea is to that all implementation can be as-is and we just add an
 extension module
 so that the new feature is visible thru the extension list.

It is not perfect but I think it is a good compromise

Re: [openstack-dev] [Neutron] [ML2] using binding:tun_ip instead of agent_ip for l2pop to support agentless backend

2015-03-30 Thread Mathieu Rohon

hi henry,

thanks for this interesting idea. It would be interesting to think about
how external gateway could leverage the l2pop framework.

Currently l2pop sends its fdb messages once the status of the port is
modified. AFAIK, this status is only modified by agents which send
update_devce_up/down().
This issue has also to be addressed if we want agent less equipments to be
announced through l2pop.

Another way to do it is to introduce some bgp speakers with e-vpn
capabilities at the control plane of ML2 (as a MD for instance). Bagpipe
[1] is an opensource bgp speaker which is able to do that.
BGP is standardized so equipments might already have it embedded.

last summit, we talked about this kind of idea [2]. We were going further
by introducing the bgp speaker on each compute node, in use case B of [2].

[1]https://github.com/Orange-OpenSource/bagpipe-bgp
[2]http://www.slideshare.net/ThomasMorin1/neutron-and-bgp-vpns-with-bagpipe

On Thu, Mar 26, 2015 at 7:21 AM, henry hly henry4...@gmail.com wrote:

 Hi ML2er,

 Today we use agent_ip in L2pop to store endpoints for ports on a
 tunnel type network, such as vxlan or gre. However this has some
 drawbacks:

 1) It can only work with backends with agents;
 2) Only one fixed ip is supported per-each agent;
 3) Difficult to interact with other backend and world outside of Openstack.

 L2pop is already widely accepted and deployed in host based overlay,
 however because it use agent_ip to populate tunnel endpoint, it's very
 hard to co-exist and inter-operating with other vxlan backend,
 especially agentless MD.

 A small change is suggested that the tunnel endpoint should not be the
 attribute of *agent*, but be the attribute of *port*, so if we store
 it in something like *binding:tun_ip*, it is much easier for different
 backend to co-exists. Existing ovs agent and bridge need a small
 patch, to put the local agent_ip into the port context binding fields
 when doing port_up rpc.

 Several extra benefits may also be obtained by this way:

 1) we can easily and naturally create *external vxlan/gre port* which
 is not attached by an Nova booted VM, with the binding:tun_ip set when
 creating;
 2) we can develop some *proxy agent* which manage a bunch of remote
 external backend, without restriction of its agent_ip.

 Best Regards,
 Henry

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

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

Re: [openstack-dev] Barbican : Usage of mode attribute in storing and order the secret

Thanks a lot  Douglas for your response. It helped me .
What are the possible values of algorithm attribute? Is AES only supported
algorithm type for  Barbican or does it support any other algorithm type?

Thanks and Regards,
Asha Seshagiri

On Mon, Mar 30, 2015 at 1:04 PM, Douglas Mendizabal 
douglas.mendiza...@rackspace.com wrote:

  Hi Asha,

  Barbican Orders of type “key” are intended to generate keys suitable for
 encryption.  The metadata associated with the key order defines the
 encryption scheme in which the key will be used.  In the example you
 provided, the order is requesting a key that is suitable for use in a block
 cipher.  Specifically you’re requesting a key that will be used with the
 “AES” block cipher, so the “mode describes the mode of operation to be
 used, which in this case is Cipher Block Chaining or “CBC”.

  Acceptable values for “mode” are dependent on the value of the
 “algorithm” attribute.  When requesting orders for keys to be used in AES
 encryption, the values for “mode” correspond to the other possible modes of
 operation for AES, such as “ECB”, “CTR”, etc.

  -Doug

 
 Douglas Mendizábal
 IRC: redrobot
 PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

  On Mar 30, 2015, at 12:46 PM, Asha Seshagiri asha.seshag...@gmail.com
 wrote:

  Any help would be appreciated ?
 Thanks in advance !

  Thanks and Regards,
 Asha Seshagiri

 On Mon, Mar 30, 2015 at 12:45 PM, Asha Seshagiri asha.seshag...@gmail.com
  wrote:

 Hi All ,

  What is the use of the mode attribute ? what does the value of this
 attribute signify and what are the possible values of this attribute?
 For ex :Consider the order request to create the secret :

  POST v1/orders

 Header: content-type=application/json
 X-Project-Id: {project_id}
 {
   type: key,
   meta: {
 name: secretname,
 algorithm: AES,
 bit_length: 256,
 mode: cbc,
 payload_content_type: application/octet-stream
   }
 }


  What does the mode  value cbc  indicate ?
 --
  *Thanks and Regards,*
 *Asha Seshagiri*




  --
  *Thanks and Regards,*
 *Asha Seshagiri*





-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Carl Baldwin

Akihiro,

If we go with the empty extension you proposed in the patch will that be
acceptable?

We've got to stop killing new functionality on the very last day like this
. It just kills progress.  This proposal isn't new.

Carl
On Mar 30, 2015 11:37 AM, Akihiro Motoki amot...@gmail.com wrote:

 Hi Neutron folks
 (API folks may be interested on this)

 We have another discussion on Core vs extension in the subnet pool
 feature reivew
 https://review.openstack.org/#/c/157597/.
 We did the similar discussion on VLAN transparency and MTU for a
 network model last week.
 I would like to share my concerns on changing the core API directly.
 I hope this help us make the discussion productive.
 Note that I don't want to discuss the micro-versioning because it
 mainly focues on Kilo FFE BP.

 I would like to discuss this topic in today's neutron meeting,
 but I am not so confident I can get up in time, I would like to send this
 mail.


 The extension mechanism in Neutron provides two points for extensibility:
 - (a) visibility of features in API (users can know which features are
 available through the API)
 - (b) opt-in mechanism in plugins (plugin maintainers can decide to
 support some feature after checking the detail)

 My concerns mainly comes from the first point (a).
 If we have no way to detect it, users (including Horizon) need to do a
 dirty work around
 to determine whether some feature is available. I believe this is one
 important point in API.

 On the second point, my only concern (not so important) is that we are
 making the core
 API change at this moment of the release. Some plugins do not consume
 db_base_plugin and
 such plugins need to investigate the impact from now on.
 On the other hand, if we use the extension mechanism all plugins need to
 update
 their extension list in the last moment :-(


 My vote at this moment is still to use an extension, but an extension
 layer can be a shim.
 The idea is to that all implementation can be as-is and we just add an
 extension module
 so that the new feature is visible thru the extension list.
 It is not perfect but I think it is a good compromise regarding the first
 point.


 I know there was a suggestion to change this into the core API in the
 spec review
 and I didn't notice it at that time, but I would like to raise this
 before releasing it.

 For longer term (and Liberty cycle),  we need to define more clear
 guideline
 on Core vs extension vs micro-versioning in spec reviews.

 Thanks,
 Akihiro

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

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

Re: [openstack-dev] [puppet] Coordinator(s)/PTL tasks description

2015-03-30 Thread Emilien Macchi



On 03/26/2015 01:08 PM, Sebastien Badia wrote:
 Hi,
 
 Following our Tuesday meeting, we decided to create a sort of PTL /
 Coordinators tasks list with the essence of
 https://wiki.openstack.org/wiki/PTL_Guide
 
 I list some point here, but feel free to add discuss about them, it's
 not (yet)
 written in stone.
 
 - Community (group) manager:
  The PTL keeps abreast of upcoming meetings ops/other where it would be
 interesting
  for our community to be represented. Maintain an ical?
 
 - Meetings organisation
  We need a chair to ensure that the meeting is correctly orchestrated,
 the PTL
  publish also a meeting agenda a minimum 5days before the meeting (see this
  example in openstack-tc¹). The PTL also publish meeting notes on the ML +
  wiki (for archive / easy search purposes).
 
 - Bug triage / management (bug squashing party ?)
  The subject was raised during the last meeting, maybe a good form was
  something like a BSP (like we made in Debian), or a PR triage like
 puppetlabs
  one's². (This task was not necessarily managed by PTL)
 
 - Maintain a list of active subject and directions like a backlog :)
  This was already managed by our trello board, and have a clear vision
 of where
  we are going on.
 
 By stepping back, maybe we must elect a PTL to fit with OpenStack «
 standards »
 and act in intern with something like a « scrum master » (changing every
 week)

What do you mean by 'changing every week'?

 firstly to distribute tasks, and secondly to involve everyone in the
 process.
 
 These points are just ideas, a kind of cornerstone to discuss.

I +1 all of them.

 
 Seb
 
 ¹http://lists.openstack.org/pipermail/openstack-tc/2015-March/000940.html
 ²https://github.com/puppet-community/community-triage/blob/master/core/notes/2015-03-25.md
 

-- 
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] [Openstack-operators][Openstack-dev][all] how to apply security/back-ported release to Icehouse production

2015-03-30 Thread Daniel Comnea

No thoughts?



On Sat, Mar 28, 2015 at 10:35 PM, Daniel Comnea comnea.d...@gmail.com
wrote:

 Hi all,

 Can anyone shed some light as to how you upgrade/ applies the
 security/back-ported patches?

 E.g  - let's say i already have a production environment running Icehouse
 2014.1 as per the link [1] and i'd like to upgrade it to latest Icehouse
 release 2014.1.4.

 Also do you have to go via sequential process like

 2014.1 - 2014.1.1 - 2014.1.2 - 2014.1.3 - 2014.4 or i can jump from
 2014.1 to 2014.1.4?

 And the last questions is: can i cherry pick which bugs part of a project
 to pull? Can i pull only 1 project - e.g HEAT from latest release 2014.1.4?


 Thanks,
 Dani

 [1] https://wiki.openstack.org/wiki/Releases

__
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] [heat] heat delete woes in Juno

2015-03-30 Thread Zane Bitter


On 26/03/15 15:30, Georgy Okrokvertskhov wrote:

I attached an example of the template which is hanging right now in my
Juno environment. I believe it hangs because of floating ip stuff and
the way how it is attached to a VM.
It is autogenerated, so please don't be disturbed by strange resource names.


There were a bunch of bug fixes required around this, due to the Neutron 
API not being designed for orchestration:


https://bugs.launchpad.net/heat/+bug/1299259
https://bugs.launchpad.net/heat/+bug/1399699
https://bugs.launchpad.net/heat/+bug/1399702

All of those were eventually backported to stable/juno, so it may be 
worth checking that you have the latest stable release. If there's still 
issues then you may need to add dependencies to the template yourself - 
in particularly complex cases, Heat just can't get enough information to 
do the Right Thing.


cheers,
Zane.



Thanks
Gosha

On Thu, Mar 26, 2015 at 12:15 PM, Ala Rezmerita
ala.rezmer...@cloudwatt.com mailto:ala.rezmer...@cloudwatt.com wrote:

Hi Matt

I had similar problems with heat, and the work-around that i used is
to abandon the stack (heat stack-abandon),
and then I delete stack resources created  one by one.

Hope this helps.

Ala Rezmerita
Software Engineer || Cloudwatt
M: (+33) 06 77 43 23 91 tel:%28%2B33%29%2006%2077%2043%2023%2091
Immeuble Etik
892 rue Yves Kermen
92100 Boulogne-Billancourt – France


*De: *Matt Fischer m...@mattfischer.com
mailto:m...@mattfischer.com
*À: *openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
*Envoyé: *Jeudi 26 Mars 2015 19:17:08
*Objet: *[openstack-dev] [heat] heat delete woes in Juno


Nobody on the operators list had any ideas on this, so re-posting here.

We've been having some issues with heatdelete-stack in Juno. The
issues generally fall into three categories:

1) it takes multiple calls to heat to delete a stack. Presumably due
to heat being unable to figure out the ordering on deletion and
resources being in use.

2) undeleteable stacks. Stacks that refuse to delete, get stuck in
DELETE_FAILED state. In this case, they show up in stack-list and
stack-show, yet resource-list and stack-delete deny their existence.
This means I can't be sure whether they have any real resources very
easily.

3) As a corollary to item 1, stacks for which heat can never unwind
the dependencies and stay in DELETE_IN_PROGRESS forever.

Does anyone have any work-arounds for these or recommendations on
cleanup? My main worry is removing a stack from the database that is
still consuming the customer's resources. I also don't just want to
remove stacks from the database and leave orphaned records in the DB.

__
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




--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com http://www.mirantis.com/
Tel. +1 650 963 9828
Mob. +1 650 996 3284


__
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] [barbican] python-barbicanclient 3.0.3 released

2015-03-30 Thread Douglas Mendizabal

The Barbican Project Team would like to announce the release of 
python-barbicanclient 3.0.3.

The release is available via PyPI

* https://pypi.python.org/pypi/python-barbicanclient 
https://pypi.python.org/pypi/python-barbicanclient

For detailed release notes, please visit the milestone page in Launchpad

* https://launchpad.net/python-barbicanclient/+milestone/3.0.3 
https://launchpad.net/python-barbicanclient/+milestone/3.0.3

Many thanks to all the contributors who made this release possible!

- Doug Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Tidwell, Ryan

I will quickly spin another patch set with the shim extension.  Hopefully this 
will be all it takes to get subnet allocation merged.

-Ryan

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, March 30, 2015 2:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool 
feature

Hi Carl,

I am now reading the detail from Salvatore, but would like to response this 
first.

I don't want to kill this useful feature too and move the thing forward.
I am fine with the empty/shim extension approach.
The subnet pool is regarded as a part of Core API, so I think this extension 
can be always enabled even if no plugin declares to use it.
Sorry for interrupting the work at the last stage, and thank for understanding.

Akihiro

2015-03-31 5:28 GMT+09:00 Carl Baldwin c...@ecbaldwin.net:
 Akihiro,

 If we go with the empty extension you proposed in the patch will that 
 be acceptable?

 We've got to stop killing new functionality on the very last day like this .
 It just kills progress.  This proposal isn't new.

 Carl

 On Mar 30, 2015 11:37 AM, Akihiro Motoki amot...@gmail.com wrote:

 Hi Neutron folks
 (API folks may be interested on this)

 We have another discussion on Core vs extension in the subnet pool 
 feature reivew https://review.openstack.org/#/c/157597/.
 We did the similar discussion on VLAN transparency and MTU for a 
 network model last week.
 I would like to share my concerns on changing the core API directly.
 I hope this help us make the discussion productive.
 Note that I don't want to discuss the micro-versioning because it 
 mainly focues on Kilo FFE BP.

 I would like to discuss this topic in today's neutron meeting, but I 
 am not so confident I can get up in time, I would like to send this 
 mail.

 The extension mechanism in Neutron provides two points for extensibility:
 - (a) visibility of features in API (users can know which features 
 are available through the API)
 - (b) opt-in mechanism in plugins (plugin maintainers can decide to 
 support some feature after checking the detail)

 My concerns mainly comes from the first point (a).
 If we have no way to detect it, users (including Horizon) need to do 
 a dirty work around to determine whether some feature is available. I 
 believe this is one important point in API.

 On the second point, my only concern (not so important) is that we 
 are making the core API change at this moment of the release. Some 
 plugins do not consume db_base_plugin and such plugins need to 
 investigate the impact from now on.
 On the other hand, if we use the extension mechanism all plugins need 
 to update their extension list in the last moment :-(

 My vote at this moment is still to use an extension, but an extension 
 layer can be a shim.
 The idea is to that all implementation can be as-is and we just add 
 an extension module so that the new feature is visible thru the 
 extension list.
 It is not perfect but I think it is a good compromise regarding the 
 first point.

 I know there was a suggestion to change this into the core API in the 
 spec review and I didn't notice it at that time, but I would like to 
 raise this before releasing it.

 For longer term (and Liberty cycle),  we need to define more clear 
 guideline on Core vs extension vs micro-versioning in spec reviews.

 Thanks,
 Akihiro

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

--
Akihiro Motoki amot...@gmail.com

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

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

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley doug...@parksidesoftware.com
wrote:

 A few reasons, I’m sure there are others:

 - Broken tests that hardcode something about the ref implementation. The
 test needs to be fixed, of course, but in the meantime, a constantly
 failing CI is worthless (hello, lbaas scenario test.)

Certainly... but that's relatively easy to fix (bug/patch to Tempest).
Although that's not actually the case in this particular context as there
are a handful of third party devices that run the full set of tests that
the ref driver runs with no additional skips or modifications.



 - Test relies on some “optional” feature, like overlapping IP subnets that
 the backend doesn’t support.  I’d argue it’s another case of broken tests
 if they require an optional feature, but it still needs skipping in the
 meantime.


This may be something specific to Neutron perhaps?  In Cinder LVM is
pretty much the lowest common denominator.  I'm not aware of any volume
tests in Tempest that rely on optional features that don't pick this up
automatically out of the config (like multi-backend for example).



 - Some new feature added to an interface, in the presence of
 shims/decomposed drivers/plugins (e.g. adding TLS termination support to
 lbaas.) Those implementations will lag the feature commit, by definition.


Yeah, certainly I think this highlights some of the differences between
Cinder and Neutron perhaps and the differences in complexity.
Thanks for the feedback... I don't disagree per say, however Cinder is set
up a bit different here in terms of expectations for base functionality
requirements and compatibility but your points are definitely well taken. 


 Thanks,
 doug


 On Mar 30, 2015, at 2:54 PM, John Griffith john.griffi...@gmail.com
 wrote:

 This may have already been raised/discussed, but I'm kinda confused so
 thought I'd ask on the ML here.  The whole point of third party CI as I
 recall was to run the same tests that we run in the official Gate against
 third party drivers.  To me that would imply that a CI system/device that
 marks itself as GOOD doesn't do things like add skips locally that aren't
 in the tempest code already?

 In other words, seems like cheating to say My CI passes and all is good,
 except for the tests that don't work which I skip... but pay no attention
 to those please.

 Did I miss something, isn't the whole point of Third Party CI to
 demonstrate that a third parties backend is tested and functions to the
 same degree that the reference implementations do? So the goal (using
 Cinder for example) was to be able to say that any API call that works on
 the LVM reference driver will work on the drivers listed in driverlog; and
 that we know this because they run the same Tempest API tests?

 Don't get me wrong, certainly not saying there's malice or things should
 be marked as no good... but if the practice is to skip what you can't do
 then maybe that should be documented in the driverlog submission, as
 opposed to just stating Yeah, we run CI successfully.

 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



 __
 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] [heat] Network name as a Server properties

2015-03-30 Thread Zane Bitter


On 30/03/15 03:51, BORTMAN, Limor (Limor) wrote:

Hi,
I noticed the we can't use network name under OS::Neutron::Port (only 
network_id) as a valid neutron property, and I was wondering why?


IIRC it was something weird about how python-neutronclient worked at the 
time.



I expected it to be like image under OS::Nova::Server:
  The property name should be network, and it should accept both id and name


It is and it does as of the 2014.2 (Juno) release.

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port-props

- ZB

__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Akihiro Motoki

Hi Carl,

I am now reading the detail from Salvatore, but would like to response
this first.

I don't want to kill this useful feature too and move the thing forward.
I am fine with the empty/shim extension approach.
The subnet pool is regarded as a part of Core API, so I think this
extension can be
always enabled even if no plugin declares to use it.
Sorry for interrupting the work at the last stage, and thank for understanding.

Akihiro

2015-03-31 5:28 GMT+09:00 Carl Baldwin c...@ecbaldwin.net:
 Akihiro,

 If we go with the empty extension you proposed in the patch will that be
 acceptable?

 We've got to stop killing new functionality on the very last day like this .
 It just kills progress.  This proposal isn't new.

 Carl

 On Mar 30, 2015 11:37 AM, Akihiro Motoki amot...@gmail.com wrote:

 Hi Neutron folks
 (API folks may be interested on this)

 We have another discussion on Core vs extension in the subnet pool
 feature reivew
 https://review.openstack.org/#/c/157597/.
 We did the similar discussion on VLAN transparency and MTU for a
 network model last week.
 I would like to share my concerns on changing the core API directly.
 I hope this help us make the discussion productive.
 Note that I don't want to discuss the micro-versioning because it
 mainly focues on Kilo FFE BP.

 I would like to discuss this topic in today's neutron meeting,
 but I am not so confident I can get up in time, I would like to send this
 mail.


 The extension mechanism in Neutron provides two points for extensibility:
 - (a) visibility of features in API (users can know which features are
 available through the API)
 - (b) opt-in mechanism in plugins (plugin maintainers can decide to
 support some feature after checking the detail)

 My concerns mainly comes from the first point (a).
 If we have no way to detect it, users (including Horizon) need to do a
 dirty work around
 to determine whether some feature is available. I believe this is one
 important point in API.

 On the second point, my only concern (not so important) is that we are
 making the core
 API change at this moment of the release. Some plugins do not consume
 db_base_plugin and
 such plugins need to investigate the impact from now on.
 On the other hand, if we use the extension mechanism all plugins need to
 update
 their extension list in the last moment :-(


 My vote at this moment is still to use an extension, but an extension
 layer can be a shim.
 The idea is to that all implementation can be as-is and we just add an
 extension module
 so that the new feature is visible thru the extension list.
 It is not perfect but I think it is a good compromise regarding the first
 point.


 I know there was a suggestion to change this into the core API in the
 spec review
 and I didn't notice it at that time, but I would like to raise this
 before releasing it.

 For longer term (and Liberty cycle),  we need to define more clear
 guideline
 on Core vs extension vs micro-versioning in spec reviews.

 Thanks,
 Akihiro

 __
 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




-- 
Akihiro Motoki amot...@gmail.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] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

This may have already been raised/discussed, but I'm kinda confused so
thought I'd ask on the ML here.  The whole point of third party CI as I
recall was to run the same tests that we run in the official Gate against
third party drivers.  To me that would imply that a CI system/device that
marks itself as GOOD doesn't do things like add skips locally that aren't
in the tempest code already?

In other words, seems like cheating to say My CI passes and all is good,
except for the tests that don't work which I skip... but pay no attention
to those please.

Did I miss something, isn't the whole point of Third Party CI to
demonstrate that a third parties backend is tested and functions to the
same degree that the reference implementations do? So the goal (using
Cinder for example) was to be able to say that any API call that works on
the LVM reference driver will work on the drivers listed in driverlog; and
that we know this because they run the same Tempest API tests?

Don't get me wrong, certainly not saying there's malice or things should be
marked as no good... but if the practice is to skip what you can't do then
maybe that should be documented in the driverlog submission, as opposed to
just stating Yeah, we run CI successfully.

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

[openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type

Hi All ,

I would like to know whether Barbican supports asymmetric order request .
Please find the curl command and response for creating the order and
retrieving  the order

root@barbican:~# curl -X POST -H 'content-type:application/json' -H
'X-Project-Id: 12345' -d '{type : asymmetric, meta: {name:
secretnamepk2, algorithm: rsa, bit_length: 256, mode: cbc,
payload_content_type: application/octet-stream}}'
http://localhost:9311/v1/orders
{order_ref: 
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
}root@barbican:~#

root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345'
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{status: ERROR, updated: 2015-03-30T21:36:38.102832, created:
2015-03-30T21:36:38.083428, order_ref: 
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c;,
meta: {name: secretnamepk2, algorithm: rsa,
payload_content_type: application/octet-stream, mode: cbc,
bit_length: 256, expiration: null}, *error_status_code: 400,
error_reason: Process TypeOrder issue seen - No plugin was found that
could support your request., type: asymmetric}*root@barbican:~#

Could any one please help.
Thanks in Advance
-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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-Dev] [third-party-ci] Clarifications on the goal and skipping tests

2015-03-30 Thread Doug Wiegley

A few reasons, I’m sure there are others:

- Broken tests that hardcode something about the ref implementation. The test 
needs to be fixed, of course, but in the meantime, a constantly failing CI is 
worthless (hello, lbaas scenario test.)
- Test relies on some “optional” feature, like overlapping IP subnets that the 
backend doesn’t support.  I’d argue it’s another case of broken tests if they 
require an optional feature, but it still needs skipping in the meantime.
- Some new feature added to an interface, in the presence of shims/decomposed 
drivers/plugins (e.g. adding TLS termination support to lbaas.) Those 
implementations will lag the feature commit, by definition.

Thanks,
doug


 On Mar 30, 2015, at 2:54 PM, John Griffith john.griffi...@gmail.com wrote:
 
 This may have already been raised/discussed, but I'm kinda confused so 
 thought I'd ask on the ML here.  The whole point of third party CI as I 
 recall was to run the same tests that we run in the official Gate against 
 third party drivers.  To me that would imply that a CI system/device that 
 marks itself as GOOD doesn't do things like add skips locally that aren't 
 in the tempest code already?
 
 In other words, seems like cheating to say My CI passes and all is good, 
 except for the tests that don't work which I skip... but pay no attention to 
 those please.
 
 Did I miss something, isn't the whole point of Third Party CI to demonstrate 
 that a third parties backend is tested and functions to the same degree that 
 the reference implementations do? So the goal (using Cinder for example) was 
 to be able to say that any API call that works on the LVM reference driver 
 will work on the drivers listed in driverlog; and that we know this because 
 they run the same Tempest API tests?
 
 Don't get me wrong, certainly not saying there's malice or things should be 
 marked as no good... but if the practice is to skip what you can't do then 
 maybe that should be documented in the driverlog submission, as opposed to 
 just stating Yeah, we run CI successfully.
 
 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

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

[openstack-dev] [Fuel] Core groups split

2015-03-30 Thread Aleksandra Fedorova

Hi, everyone,

as a follow-up for discussion [1] we've added per project core groups for
all main fuel-* repositories (see [2]):

fuel-astute-core
fuel-devops-core
fuel-docs-core
fuel-library-core
fuel-main-core
fuel-ostf-core
fuel-plugins-core
fuel-qa-core
fuel-stats-core
fuel-web-core

The original fuel-core group is included in each of those new groups, so
nothing has actually changed for now.

But as we are unblocked now, we can start reorganizing our core groups and
clarify core-reviewers responsibilities.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055038.html
[2] https://review.openstack.org/#/c/168182/

-- 
Aleksandra Fedorova
Fuel Devops Engineer
bookwar
__
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][Neutron] Status of the nova-network to Neutron migration work

2015-03-30 Thread Sean M. Collins

 Quick update about OVS vs LB:
 Sean M. Collins pushed up a patch that runs CI on Tempest with LB:
 https://review.openstack.org/#/c/168423/
 
 So far it's failing pretty badly.


I haven't had a chance to debug the failures - it is my hope that
perhaps there are just more changes I need to make to DevStack to make
LinuxBridge work correctly. If anyone is successfully using LinuxBridge
with DevStack, please do review that patch and offer suggestions or
share their local.conf file. :)

-- 
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] [libvirt] [nova] The risk of hanging when shutdown instance.

2015-03-30 Thread Eric Blake

On 03/30/2015 06:08 AM, Michal Privoznik wrote:
 On 30.03.2015 11:28, zhang bo wrote:
 On 2015/3/28 18:06, Rui Chen wrote:

 snip/

   The API virDomainShutdown's description is out of date, it's not correct.
   In fact, virDomainShutdown would block or not, depending on its mode. If 
 it's in mode *agent*, then it would be blocked until qemu founds that the 
 guest actually got down.
 Otherwise, if it's in mode *acpi*, then it would return immediately.
   Thus, maybe further more work need to be done in Openstack.

   What's your opinions, Michal and Daniel (from libvirt.org), and Chris 
 (from openstack.org) :)

 
 
 Yep, the documentation could be better in that respect. I've proposed a
 patch on the libvirt upstream list:
 
 https://www.redhat.com/archives/libvir-list/2015-March/msg01533.html

I don't think a doc patch is right.  If you don't pass any flags, then
it is up to the hypervisor which method it will attempt (agent or ACPI).
 Yes, explicitly requesting an agent as the only method to attempt might
be justifiable as a reason to block, but the overall API contract is to
NOT block indefinitely.  I think that rather than a doc patch, we need
to fix the underlying bug, and guarantee that we return after a finite
time even when the agent is involved.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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] Barbican : Use of consumer resource

Including Alee and Paul in the loop

Refining the above question :

The consumer resource allows the clients to register with container
resources. Please find the command and response below

POST v1/containers/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718/consumers

Header: content-type=application/json
X-Project-Id: {project_id}
{
name: foo-service,
URL: https://www.fooservice.com/widgets/1234;
}

I would like to know the following :

*1. Who  does the client here refers to ? Openstack Services or any
other services as well?*

*2. Once the client gets registered through the consumer resource ,
How does client consume or use the consumer resource*

Any Help would be appreciated.

Thanks Asha.





On Mon, Mar 30, 2015 at 12:05 AM, Asha Seshagiri asha.seshag...@gmail.com
wrote:

 Hi All,

 Once the consumer resource registers to the containers , how does the
 consumer resource consume the container resource?
 Is there any API supporting the above operation.

 Could any one please help on this?

 --
 *Thanks and Regards,*
 *Asha Seshagiri*




-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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] [stable] Preparing for 2014.2.3 -- branches freeze April 2nd

2015-03-30 Thread Adam Gandelman

Hi All-

We'll be freezing the stable/juno branches for integrated Juno projects this
Thursday April 2nd in preparation for the 2014.2.3 stable release on
Thursday April 9th.  You can view the current queue of proposed patches
on gerrit [1].  I'd like to request all interested parties review current
bugs affecting Juno and help ensure any relevant fixes be proposed
soon and merged by Thursday, or notify the stable-maint-core team of
anything critical that may land late and require a freeze exception.

Thanks,
Adam

[1] https://review.openstack.org/#/q/status:open+branch:stable/juno,n,z
__
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] Core API vs extension: the subnet pool feature

2015-03-30 Thread Carl Baldwin

Thanks for your support, Akihiro.  We will get this up for review very soon.

Carl

On Mon, Mar 30, 2015 at 2:59 PM, Akihiro Motoki amot...@gmail.com wrote:
 Hi Carl,

 I am now reading the detail from Salvatore, but would like to response
 this first.

 I don't want to kill this useful feature too and move the thing forward.
 I am fine with the empty/shim extension approach.
 The subnet pool is regarded as a part of Core API, so I think this
 extension can be
 always enabled even if no plugin declares to use it.
 Sorry for interrupting the work at the last stage, and thank for 
 understanding.

 Akihiro

 2015-03-31 5:28 GMT+09:00 Carl Baldwin c...@ecbaldwin.net:
 Akihiro,

 If we go with the empty extension you proposed in the patch will that be
 acceptable?

 We've got to stop killing new functionality on the very last day like this .
 It just kills progress.  This proposal isn't new.

 Carl

 On Mar 30, 2015 11:37 AM, Akihiro Motoki amot...@gmail.com wrote:

 Hi Neutron folks
 (API folks may be interested on this)

 We have another discussion on Core vs extension in the subnet pool
 feature reivew
 https://review.openstack.org/#/c/157597/.
 We did the similar discussion on VLAN transparency and MTU for a
 network model last week.
 I would like to share my concerns on changing the core API directly.
 I hope this help us make the discussion productive.
 Note that I don't want to discuss the micro-versioning because it
 mainly focues on Kilo FFE BP.

 I would like to discuss this topic in today's neutron meeting,
 but I am not so confident I can get up in time, I would like to send this
 mail.


 The extension mechanism in Neutron provides two points for extensibility:
 - (a) visibility of features in API (users can know which features are
 available through the API)
 - (b) opt-in mechanism in plugins (plugin maintainers can decide to
 support some feature after checking the detail)

 My concerns mainly comes from the first point (a).
 If we have no way to detect it, users (including Horizon) need to do a
 dirty work around
 to determine whether some feature is available. I believe this is one
 important point in API.

 On the second point, my only concern (not so important) is that we are
 making the core
 API change at this moment of the release. Some plugins do not consume
 db_base_plugin and
 such plugins need to investigate the impact from now on.
 On the other hand, if we use the extension mechanism all plugins need to
 update
 their extension list in the last moment :-(


 My vote at this moment is still to use an extension, but an extension
 layer can be a shim.
 The idea is to that all implementation can be as-is and we just add an
 extension module
 so that the new feature is visible thru the extension list.
 It is not perfect but I think it is a good compromise regarding the first
 point.


 I know there was a suggestion to change this into the core API in the
 spec review
 and I didn't notice it at that time, but I would like to raise this
 before releasing it.

 For longer term (and Liberty cycle),  we need to define more clear
 guideline
 on Core vs extension vs micro-versioning in spec reviews.

 Thanks,
 Akihiro

 __
 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




 --
 Akihiro Motoki amot...@gmail.com

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

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

Re: [openstack-dev] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

2015-03-30 Thread Rochelle Grober

Top posting… I believe the main issue was a problem with snapshots that caused
false negatives for most cinder drivers. But, that got fixed. Unfortunately,
we haven’t yet established a good process to notify third parties when skipped
tests are fixed and should be “unskipped”. Maybe tagging the tests can help on
this. But, I really do think this round was a bit of first run gotchas and
rookie mistakes on all sides. A good post mortem on how to better communicate
changes and deadlines may go a long way to smooth these out in the next round.

--Rocky

John Griffith on Monday, March 30, 2015 15:36 wrote:

On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley
doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote:
A few reasons, I’m sure there are others:

- Broken tests that hardcode something about the ref implementation. The test
needs to be fixed, of course, but in the meantime, a constantly failing CI is
worthless (hello, lbaas scenario test.)
Certainly... but that's relatively easy to fix (bug/patch to Tempest).
Although that's not actually the case in this particular context as there are a
handful of third party devices that run the full set of tests that the ref
driver runs with no additional skips or modifications.

- Test relies on some “optional” feature, like overlapping IP subnets that the
backend doesn’t support. I’d argue it’s another case of broken tests if they
require an optional feature, but it still needs skipping in the meantime.

This may be something specific to Neutron perhaps? In Cinder LVM is pretty
much the lowest common denominator. I'm not aware of any volume tests in
Tempest that rely on optional features that don't pick this up automatically
out of the config (like multi-backend for example).

- Some new feature added to an interface, in the presence of shims/decomposed
drivers/plugins (e.g. adding TLS termination support to lbaas.) Those
implementations will lag the feature commit, by definition.

Yeah, certainly I think this highlights some of the differences between Cinder
and Neutron perhaps and the differences in complexity.
Thanks for the feedback... I don't disagree per say, however Cinder is set up a
bit different here in terms of expectations for base functionality requirements
and compatibility but your points are definitely well taken.

Thanks,
doug

On Mar 30, 2015, at 2:54 PM, John Griffith
john.griffi...@gmail.commailto:john.griffi...@gmail.com wrote:

This may have already been raised/discussed, but I'm kinda confused so thought
I'd ask on the ML here. The whole point of third party CI as I recall was to
run the same tests that we run in the official Gate against third party
drivers. To me that would imply that a CI system/device that marks itself as
GOOD doesn't do things like add skips locally that aren't in the tempest code
already?

In other words, seems like cheating to say My CI passes and all is good,
except for the tests that don't work which I skip... but pay no attention to
those please.

Did I miss something, isn't the whole point of Third Party CI to demonstrate
that a third parties backend is tested and functions to the same degree that
the reference implementations do? So the goal (using Cinder for example) was to
be able to say that any API call that works on the LVM reference driver will
work on the drivers listed in driverlog; and that we know this because they run
the same Tempest API tests?

Don't get me wrong, certainly not saying there's malice or things should be
marked as no good... but if the practice is to skip what you can't do then
maybe that should be documented in the driverlog submission, as opposed to just
stating Yeah, we run CI successfully.

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

Re: [openstack-dev] [nova] meaning of 'Triaged' in bug tracker

2015-03-30 Thread Tony Breeds

On Mon, Mar 30, 2015 at 10:00:44AM -0400, Sean Dague wrote:
 I've been attempting to clean up the bug tracker, one of the continued
 inconsistencies that are in the Nova tracker is the use of 'Triaged'.
 
 
 https://wiki.openstack.org/wiki/BugTriage
 
 If the bug contains the solution, or a patch, set the bug status to
 Triaged

So I'll stick my hand up and say that I was/am using:
The bug comments contain a full analysis on how to properly fix the issue
from: https://wiki.openstack.org/wiki/Bugs

to differentiate between Confirmed and Triaged.  Certainly there are a few bugs
I'm on that fall into the 'the bug has enough information to fix it' category
without having a bug attached.

So I'd like to suggest 2 things

1) We link directly to https://wiki.openstack.org/wiki/BugTriage from
   https://launchpad.net/~nova-bugs.  This is the path I used to get started
   with bug work.  Perhaps I'm strange ;P
2) [ and this is harder as it's project wide :/ ] We pick one of the two
preceding definitions and use it in both places.  We should probably check the
other state descriptions.

I'm not advocating for definition or t'other merely trying to reduce points of
confusion.

Yours Tony.


pgpzemAkZtxDR.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] [OpenStack-Dev] [third-party-ci] Clarifications on the goal and skipping tests

On Mon, Mar 30, 2015 at 7:26 PM, arkady_kanev...@dell.com wrote:

 Another scenario.

 The default LVM driver is local to cinder service.  Thus, it may work fine
 as soon as you go outside controller node it does not.

 We had a discussion on choosing different default driver and expect that
 discussion to continue.



 Not all drivers support all features. We have a table that list which
 features each driver support.



 The question I would ask is setting which test to skip in the driver is
 the right place?

 Why not specify it in the Tempest which driver run against.

 Then we can setup rules when drivers should remove themselves from that
 blackout list.

 That is easier to track, can be cleanly used by defcore and for tagging.



 Thanks,

 Arkady



 *From:* John Griffith [mailto:john.griffi...@gmail.com]
 *Sent:* Monday, March 30, 2015 8:12 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Dev] [third-party-ci]
 Clarifications on the goal and skipping tests







 On Mon, Mar 30, 2015 at 6:21 PM, Rochelle Grober 
 rochelle.gro...@huawei.com wrote:

 Top posting… I believe the main issue was a problem with snapshots that
 caused false negatives for most cinder drivers.  But, that got fixed.
 Unfortunately, we haven’t yet established a good process to notify third
 parties when skipped tests are fixed and should be “unskipped”.  Maybe
 tagging the tests can help on this.  But, I really do think this round was
 a bit of first run gotchas and rookie mistakes on all sides.  A good post
 mortem on how to better communicate changes and deadlines may go a long way
 to smooth these out in the next round.



 --Rocky



 John Griffith on Monday, March 30, 2015 15:36 wrote:

 On Mon, Mar 30, 2015 at 4:06 PM, Doug Wiegley 
 doug...@parksidesoftware.com wrote:

 A few reasons, I’m sure there are others:



 - Broken tests that hardcode something about the ref implementation. The
 test needs to be fixed, of course, but in the meantime, a constantly
 failing CI is worthless (hello, lbaas scenario test.)

 Certainly... but that's relatively easy to fix (bug/patch to Tempest).
 Although that's not actually the case in this particular context as there
 are a handful of third party devices that run the full set of tests that
 the ref driver runs with no additional skips or modifications.

 



 - Test relies on some “optional” feature, like overlapping IP subnets that
 the backend doesn’t support.  I’d argue it’s another case of broken tests
 if they require an optional feature, but it still needs skipping in the
 meantime.



 This may be something specific to Neutron perhaps?  In Cinder LVM is
 pretty much the lowest common denominator.  I'm not aware of any volume
 tests in Tempest that rely on optional features that don't pick this up
 automatically out of the config (like multi-backend for example).

 



 - Some new feature added to an interface, in the presence of
 shims/decomposed drivers/plugins (e.g. adding TLS termination support to
 lbaas.) Those implementations will lag the feature commit, by definition.



 Yeah, certainly I think this highlights some of the differences between
 Cinder and Neutron perhaps and the differences in complexity.

 Thanks for the feedback... I don't disagree per say, however Cinder is set
 up a bit different here in terms of expectations for base functionality
 requirements and compatibility but your points are definitely well taken.
 



 Thanks,

 doug





 On Mar 30, 2015, at 2:54 PM, John Griffith john.griffi...@gmail.com
 wrote:



 This may have already been raised/discussed, but I'm kinda confused so
 thought I'd ask on the ML here.  The whole point of third party CI as I
 recall was to run the same tests that we run in the official Gate against
 third party drivers.  To me that would imply that a CI system/device that
 marks itself as GOOD doesn't do things like add skips locally that aren't
 in the tempest code already?



 In other words, seems like cheating to say My CI passes and all is good,
 except for the tests that don't work which I skip... but pay no attention
 to those please.



 Did I miss something, isn't the whole point of Third Party CI to
 demonstrate that a third parties backend is tested and functions to the
 same degree that the reference implementations do? So the goal (using
 Cinder for example) was to be able to say that any API call that works on
 the LVM reference driver will work on the drivers listed in driverlog; and
 that we know this because they run the same Tempest API tests?



 Don't get me wrong, certainly not saying there's malice or things should
 be marked as no good... but if the practice is to skip what you can't do
 then maybe that should be documented in the driverlog submission, as
 opposed to just stating Yeah, we run CI successfully.



 Thanks,

 John

 __
 OpenStack Development

Re: [openstack-dev] [Mistral] Proposal for the Resume Feature

2015-03-30 Thread Dmitri Zimine

Thanks Winson for the summary. 

@Lingxian Kong
  The context for a task is used
 internally, I know the aim for this feature is to make it very easy
 and convinient for users to see the details for the workflow exection,
 but what users can do next with the context? Do you have a plan to
 change that context for a task by users? if the answer is no, I think
 it is not very necessary to expose the context endpoint.

I think the answer is “yes users will change the context” this falls out of use 
case #3. 
Let’s be specific: a create_vm task failed due to, say, network connection. 
As a user, I created the VM manually, now want to continue the workflow. 
Next step is attach storage to VM, needs VM ID published variable. So a user 
needs to 
modify outgoing context of create_vm task.

May be use case 2 be sufficient? 
We are also likely to specify multiple tasks: in case a parallel execution of 
two tasks
(create VM, create DNS record) failed again due to network conditions - than 
network 
is back I want to continue, but re-run those two exact tasks. 

Another point, may be obvious but let’s articulate it: we re-run task, not 
individual action within task.
In context of with_items, retry, repeat, it will lead to running actions 
multiple times.

Finally, workflow execution traceability. We need to get to the point of 
tracing pause and resume as workflow events. 

@Lingxian Kong
  we can introduce the notification
 system to Mistral, which is heavily used in other OpenStack projects.
care to elaborare? Thanks! 

DZ  


On Mar 26, 2015, at 10:29 PM, Lingxian Kong anlin.k...@gmail.com wrote:

 On Fri, Mar 27, 2015 at 11:20 AM, W Chan m4d.co...@gmail.com wrote:
 We assume WF is in paused/errored state when 1) user manually pause the WF,
 2) pause is specified on transition (on-condition(s) such as on-error), and
 3) task errored.
 
 The resume feature will support the following use cases.
 1) User resumes WF from manual pause.
 2) In the case of task failure, user fixed the problem manually outside of
 Mistral, and user wants to re-run the failed task.
 3) In the case of task failure, user fixed the problem manually outside of
 Mistral, and user wants to resume from the next task.
 this use case does really make sense to me.
 
 Resuming from #1 should be straightforward.
 Resuming from #2, user may want to change the inbound context.
 Resuming from #3, users is required to manually provide the published vars
 for the failed task(s).
 
 In our offline discussion, there's ambiguity with on-error clause and
 whether a task failure has already been addressed by the WF itself.  In many
 cases, the on-error tasks may just be logging, email notification, and/or
 other non-recovery procedures.  It's hard to determine that automatically,
 so we let users decide where to resume the WF instead.  Mistral will let
 user resume a WF from specific point. The resume function will determine the
 requirements needed to successfully resume.  If requirements are not met,
 then resume returns an error saying what requirements are missing.  In the
 case where there are failures in multiple parallel branches, the
 requirements may include more than one tasks.  For cases where user
 accidentally resume from an earlier task that is already successfully
 completed, the resume function should detect that and throw an exception.
 
 Also, the current change to separate task from action execution should be
 sufficient for traceability.
 
 We also want to expose an endpoint to let users view context for a task.
 This is to let user have a reference of the current task context to
 determine the delta they need to change for a successful resume.
 IMHO, I'm afraid I can't agree here. The context for a task is used
 internally, I know the aim for this feature is to make it very easy
 and convinient for users to see the details for the workflow exection,
 but what users can do next with the context? Do you have a plan to
 change that context for a task by users? if the answer is no, I think
 it is not very necessary to expose the context endpoint.
 
 However, considering the importance of context for the task
 execution(the resuming feature), we can introduce the notification
 system to Mistral, which is heavily used in other OpenStack projects.
 
 __
 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
 
 
 
 
 -- 
 Regards!
 ---
 Lingxian Kong
 
 __
 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-Dev] [third-party-ci] Clarifications on the goal and skipping tests