Re: [openstack-dev] [openstack-ansible] network question and documentation

Le 19/02/2016 00:31, Ian Cordasco a écrit : > > > -Original Message- > From: Fabrice Grelaud > Reply: OpenStack Development Mailing List (not for usage questions) > > Date: February 17, 2016 at 09:02:49 > To:

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On 17 February 2016 at 17:52, Clint Byrum wrote: > Excerpts from Cheng, Yingxin's message of 2016-02-14 21:21:28 -0800: >> Hi, >> >> I've uploaded a prototype https://review.openstack.org/#/c/280047/ to >> testify its design goals in accuracy, performance, reliability and >>

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, So who is voting for the path to be abandoned? By the way, there is already a task running by the wildcard: https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4 However, it this case it might work with plugins. Best regards,

Re: [openstack-dev] [release][stable][oslo][all] oslo.service 0.9.1 release (liberty)

Hi, Oh, I noticed myself the bug https://bugs.launchpad.net/nova/+bug/1538204 (nova failed to stop) on Grenade tests of one of my Cinder changes. Grenade started on Liberty with oslo.service 1.1.0, a version which didn't have my fixes for signal handling. Good news: since

Re: [openstack-dev] [Fuel] Wildcards instead of

+1 to use wildcards for common tasks like netconfig and setup repositories. This tasks should run on all nodes and it does not matter, the node has role from plugin or core-role. In my opinion we should one approach for basic configuration of node. Regards, Bulat Gaifullin Mirantis Inc. > On

Re: [openstack-dev] [Nova][Glance]Glance v2 api support in Nova

On 02/15/2016 06:00 PM, Flavio Percoco wrote: > On 12/02/16 18:24 +0300, Mikhail Fedosin wrote: >> Hello! >> >> In late December I wrote several messages about glance v2 support in >> Nova and >> Nova's xen plugin. Many things have been done after that and now I'm >> happy to >> announce that

[openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

Hi all! Initially we didn't plan on having stable branches for IPA at all. Our gate is using the prebuilt image generated from the master branch even on Ironic/Inspector stable branches. The branch in question was added by request of RDO folks, and today I got a request from trown to remove

Re: [openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

Hi, By removing stable branches you mean stable branches for mitaka and newer releases or that includes stable/liberty which already exist as well? I think the latter is more complicated, I don't think we should drop stable/liberty like that because other people (apart from TripleO) may also

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

On 02/18/2016 10:29 PM, joehuang wrote: There is difference between " An end user is able to import image from another Glance in another OpenStack cloud while sharing same identity management( KeyStone )" This is an invalid use case, IMO. What's wrong with exporting the image from one

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

On 02/18/2016 09:50 PM, Armando M. wrote: > > > On 18 February 2016 at 08:41, Sean M. Collins > wrote: > > This week's update: > > Armando was kind enough to take a look[1], since he's got a fresh > perspective. I think I've been

Re: [openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

On 02/19/2016 07:29 AM, Lucas Alvares Gomes wrote: > Hi, > > By removing stable branches you mean stable branches for mitaka and > newer releases or that includes stable/liberty which already exist as > well? > > I think the latter is more complicated, I don't think we should drop >

Re: [openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

On 02/19/2016 01:29 PM, Lucas Alvares Gomes wrote: Hi, By removing stable branches you mean stable branches for mitaka and newer releases or that includes stable/liberty which already exist as well? I think the latter is more complicated, I don't think we should drop stable/liberty like that

Re: [openstack-dev] [openstack-ansible] network question and documentation

On 02/17/2016 09:00 AM, Fabrice Grelaud wrote: > So, i would like to know if i'm going in the right direction. > We want to use both, existing vlan from our existing physical architecture > inside openstack (vlan provider) and "private tenant network" with IP > floating offer (from a flat

Re: [openstack-dev] [Fuel] Wildcards instead of

Kyrylo G. wrote: > So who is voting for the path to be abandoned? I vote to abandon it. Let's do not break existing plugins, and do not add *undo* tasks for plugin developers. If they want to configure network, they'll ask it explicitly. Kyrylo G. wrote: > By the way, there is already a task

[openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hi all, I was playing some time with puppet-keystone deployments, and also reported one issue related to this: https://bugs.launchpad.net/puppet-keystone/+bug/1547394 but in general my observations are that keystone_service is using v3 credentials with openstack cli commands that are not

Re: [openstack-dev] [Fuel] Wildcards instead of

> On 19 Feb 2016, at 17:09, Igor Kalnitsky wrote: > > Kyrylo G. wrote: >> So who is voting for the path to be abandoned? > > I vote to abandon it. Let's do not break existing plugins, and do not > add *undo* tasks for plugin developers. If they want to configure >

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

What version of openstack client do you have? What version of the module are you using? On Feb 19, 2016 7:20 AM, "Ptacek, MichalX" wrote: > Hi all, > > > > I was playing some time with puppet-keystone deployments, > > and also reported one issue related to this: > >

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: > On Feb 12, 2016, at 14:49, Jay Pipes wrote: > > > This would be my preference as well, even though it's technically a > > backwards-incompatible API change. > > > > The idea behind get-me-a-network was specifically

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hi Michal, Just add --os-identity-api-version=3 to your command it will work. The provider uses v3 openstackclient via env var OS_IDENTITY_API_VERSION=3. The default is still 2. Best Regards, Matthew Mosesohn On Fri, Feb 19, 2016 at 5:25 PM, Matt Fischer wrote: > What

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hello Matt & Matthew, I am using following versions: python-openstackclient-1.0.1-1.fc22.noarch openstack-keystone(v7.0.0) for me observations are still the same: when v2 version is used (in OS_IDENTITY_API_VERSION & OS_AUTH_URL), command "'/bin/openstack service list --quiet --format csv

Re: [openstack-dev] [Fuel] Wildcards instead of

> I vote to abandon it. Let's do not break existing plugins, and do not > add *undo* tasks for plugin developers. If they want to configure > network, they'll ask it explicitly. +1 to this gentleman. It's safe to add wildcards only to tasks that were moved from pre/post deployment stages, which

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

You shouldn't have to do any of that, it should just work. I have OSC 2.0.0 in my environment though (Ubuntu). I'm just guessing but perhaps that client is too old? Maybe a Fedora user could recommend a version. On Fri, Feb 19, 2016 at 7:38 AM, Matthew Mosesohn wrote: >

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: > Cinder team is proposing to add support for API microversions [1]. It came up > at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on > IRC have raised questions about this [3] > > Please weigh in on the design decision to

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 10:57 AM, Sean Dague wrote: On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: Cinder team is proposing to add support for API microversions [1]. It came up at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on IRC have raised questions about this [3] Please

Re: [openstack-dev] [trove] Start to port Trove to Python 3 in Mitaka cycle?

On 02/18/2016 08:20 PM, Victor Stinner wrote: > I discussed with some Trove developers who are interested to start the > Python 3 port right now. What do you think? Mitaka b3 is just around the corner (in less than 10 days now), so at the end, it doesn't change things much, unless all of your

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 02/19/2016 09:30 AM, Andrew Laski wrote: > > > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: >> On Feb 12, 2016, at 14:49, Jay Pipes wrote: >> >>> This would be my preference as well, even though it's technically a >>> backwards-incompatible API change. >>> >>>

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote: > The concern as I understand it is that by extending the v2 API with > microversions the following failure scenario exists > > If: > > 1) a client already is using the /v2 API > 2) a client opt's into using microversions on /v2 > 3)

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 11:15 AM, Ben Swartzlander wrote: > On 02/19/2016 10:57 AM, Sean Dague wrote: >> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: >>> Cinder team is proposing to add support for API microversions [1]. It >>> came up at our mid-cycle that we should add a new /v3 endpoint [2]. >>>

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 11:20 AM, Sean McGinnis wrote: > On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote: >> The concern as I understand it is that by extending the v2 API with >> microversions the following failure scenario exists >> >> If: >> >> 1) a client already is using the /v2 API >> 2) a

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote: > On 02/19/2016 09:30 AM, Andrew Laski wrote: > > > > > > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: > >> On Feb 12, 2016, at 14:49, Jay Pipes wrote: > >> > >>> This would be my preference as well, even

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 8:24 AM, Sean Dague wrote: > On 02/19/2016 11:15 AM, Ben Swartzlander wrote: > > On 02/19/2016 10:57 AM, Sean Dague wrote: > >> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: > >>> Cinder team is proposing to add support for API microversions [1]. It > >>>

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 11:28:09AM -0500, Sean Dague wrote: > On 02/19/2016 11:20 AM, Sean McGinnis wrote: > > On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote: > >> The concern as I understand it is that by extending the v2 API with > >> microversions the following failure scenario

Re: [openstack-dev] [Nova][Glance]Glance v2 api support in Nova

On 19 February 2016 at 11:45, Sean Dague wrote: > On 02/15/2016 06:00 PM, Flavio Percoco wrote: >> On 12/02/16 18:24 +0300, Mikhail Fedosin wrote: >>> Hello! >>> >>> In late December I wrote several messages about glance v2 support in >>> Nova and >>> Nova's xen plugin. Many

Re: [openstack-dev] [ceilometer, gnocchi]How to use gnocchi in OpenStack Liberty

On 19/02/2016 3:09 AM, phot...@126.com wrote: > I install OpenStack Liberty follow the instruction of "Installation > Guide for Red Hat Enterprise Linux 7 and CentOS 7”. Then, I want to use > Gnocchi instead of MongoDB in ceilometer. I read the doc of gnocchi in > http://gnocchi.xyz . But in

[openstack-dev] [tc][i18n] Please review the patch to add I18n team ATCs

Hi,   There is a patch to governance, adding a list of I18n ATCs as extra-atcs. Please review and vote. https://review.openstack.org/#/c/281145/   One major contribution of I18n active contributors is to provide translations through http://translate.openstack.org. Since Liberty, active translators

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

On 19 February 2016 at 04:43, Sean Dague wrote: > On 02/18/2016 09:50 PM, Armando M. wrote: > > > > > > On 18 February 2016 at 08:41, Sean M. Collins > > wrote: > > > > This week's update: > > > > Armando was kind enough to

Re: [openstack-dev] [heat] intrinsic function bugfixes and hot versioning

On Thu, Feb 18, 2016 at 11:40:16AM +0100, Thomas Herve wrote: > On Wed, Feb 17, 2016 at 7:54 PM, Steven Hardy wrote: > > Hi all, > > > > So, Zane and I have discussed $subject and it was suggested I take this to > > the list to reach consensus. > > > > Recently, I've run into a

Re: [openstack-dev] [all] Please do *not* use git (and specifically "git log") when generating the docs

- Original Message - > Hi, > > I've seen Reno doing it, then some more. It's time that I raise the > issue globally in this list before the epidemic spreads to the whole of > OpenStack ! :) > > The last occurence I have found is in oslo.config (but please keep in > mind this message is

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 19 February 2016 at 16:28, Andrew Laski wrote: > On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote: >> On 02/19/2016 09:30 AM, Andrew Laski wrote: >> > >> > >> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: >> >> On Feb 12, 2016, at 14:49, Jay Pipes

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

Hi Gal Sagie, Let me try to pull in the data and will provide you the information. Thanks Swami From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Thursday, February 18, 2016 9:36 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Yuli Stremovsky; Shlomo Narkolayev; Eran

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Hi Folks, Great Job! Thanks Swami From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, February 19, 2016 9:07 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/19/2016 11:24 AM, Sean Dague wrote: On 02/19/2016 11:15 AM, Ben Swartzlander wrote: On 02/19/2016 10:57 AM, Sean Dague wrote: On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: Cinder team is proposing to add support for API microversions [1]. It came up at our mid-cycle that we should add

Re: [openstack-dev] [openstack-ansible] network question and documentation

> Le 19 févr. 2016 à 14:20, Major Hayden a écrit : > > On 02/17/2016 09:00 AM, Fabrice Grelaud wrote: >> So, i would like to know if i'm going in the right direction. >> We want to use both, existing vlan from our existing physical architecture >> inside openstack (vlan

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Armando M. wrote: > Now that the blocking issue has been identified, I filed project-config > change [1] to enable us to test the Neutron Grenade multinode more > thoroughly. > > [1] https://review.openstack.org/#/c/282428/ Indeed - I want to profusely thank everyone that I reached out to

[openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

Angus is already in kolla-mesos-core but doesn't have broad ability to approve changes for all of kolla-core. We agreed by majority vote in Tokyo that folks in kolla-mesos-core that integrated well with the project would be moved from kolla-mesos-core to kolla-core. Once kolla-mesos-core is

Re: [openstack-dev] [puppet] how to run rspec tests? r10k issue

On Thu, Feb 18, 2016 at 2:26 PM, Matt Fischer wrote: > Is anyone able to share the secret of running spec tests since the r10k > transition? bundle install && bundle exec rake spec have issues because > r10k is not being installed. Since I'm not the only one hopefully this

[openstack-dev] [kolla] Adding folks to the core team

I was asked if anyone can propose someone for the core reviewer team, and the answer is absolutely yes. Any core reviewer can trigger a vote by using the [vote] tag in an email for anything related to project policy (core reviewers fall into this category). The vote must be majority (except

[openstack-dev] [swift] Account ACL with keystone auth

Account ACL for allowing other accounts administration access to create containers looks to be accepting the request but doesn't seem to be persisting the information with keystone auth. For example if admin:admin user allows demo:demo "admin" access on its account, the following request

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/19/2016 11:49 AM, John Garbutt wrote: > Now, if we step back and created this again, I would agree that > --nic=auto is a good idea, so its explicit. However, all our users > are used to automatic being the default, all be it a very patchy >

Re: [openstack-dev] [ironic] Midcycle summary part 6/6

On Thu, Feb 18, 2016 at 06:13:08PM -0800, Jim Rollenhagen wrote: > Hi all, > > As our midcycle is virtual and split into 6 "sessions" for the sake of > timezones, we'll be sending a brief summary of each session so that > folks can catch up before the next one. All of this info should be on > the

[openstack-dev] [trove] Trove Mitaka mid-cycle sprint summary

tl;dr - The Trove team held its mid-cycle sprint in Raleigh, NC last week. My thanks to Red Hat and Pete MacKinnon (IRC: pmackinn) who hosted us for this mid-cycle meeting. Several attendees from companies active in the project (HP, Tesora, IBM and Red Hat) attended the meeting in person and

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

  -Original Message- From: Jay Pipes Reply: OpenStack Development Mailing List (not for usage questions) Date: February 19, 2016 at 06:45:38 To: openstack-dev@lists.openstack.org Subject:  Re:

[openstack-dev] [Fuel][puppet] Fuel CI for puppet-openstack modules

Hey folks, I'm glad to announce that Fuel CI for puppet-openstack modules is live and running in it's initial stage, you can look at the builds here[0]. It's running in silent mode now to allow us to gather some results and ensure that everything is running stable, so you won't see any

Re: [openstack-dev] [Fuel][puppet] Fuel CI for puppet-openstack modules

Thanks Igor! With this CI up and running we're one more step closer to completing the integration between Fuel and Puppet OpenStack projects that has started with the introduction of the puppet-librarian-simple in fuel-library. Consider the whole picture: - Fuel CI is now using mitaka-2

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

But, there are no such clients today. And there is no library that does this yet. It will be 4 - 6 months (or even more likely 12+) until that's in the ecosystem. Which is why adding the header validation to existing v2 API, and backporting to liberty / kilo, will provide really substantial

Re: [openstack-dev] [Octavia] [Tempest] Tempest tests using tempest-plugin

I really do not want to see tempest code copied into the Octavia repository. We cannot keep them in sync and maintain the tests that way. It has been a recurring problem with neutron-lbaas that we are trying to get back out of[1], so I really do not want to repeat that with Octavia. [1]

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote: Angus is already in kolla-mesos-core but doesn't have broad ability to approve changes for all of kolla-core. We agreed by majority vote in Tokyo that folks in kolla-mesos-core that integrated well with the project would be moved from

[openstack-dev] Do we need lock fencing?

Hi all, After reading over the following interesting article about redis and redlock (IMHO it's good overview of distributed locking in general): http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html#protecting-a-resource-with-a-lock (I personally recommend people read

[openstack-dev] [Neutron] next Team meeting cancelled (Feb-22)

Hi Neutrinos, This week is Mid-cycle week [1], and some of us will be potentially enroute to the destination. For this reason, the meeting is cancelled. If you're interested in participating remotely, please keep an eye on the etherpad for updates. Cheers, Armando [1]

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 06:30 AM, Doug Hellmann wrote: Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: On 02/16/2016 11:30 AM, Doug Hellmann wrote: So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/18/2016 09:05 PM, Cody A.W. Somerville wrote: There is no implicit (or explicit) requirement for the tests to be a full integration/end-to-end test. Mocks and/or unit tests would be sufficient to satisfy "test-driven gate". While I do agree there is no requirement, I would not be

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 19 February 2016 at 09:49, John Garbutt wrote: > On 19 February 2016 at 16:28, Andrew Laski wrote: > > On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote: > >> On 02/19/2016 09:30 AM, Andrew Laski wrote: > >> > > >> > > >> > On Thu, Feb 18, 2016, at

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

+1 of course. I mean, its Angus. Who can say no to Angus? Sam Yaple On Fri, Feb 19, 2016 at 10:57 PM, Michal Rostecki wrote: > On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote: > >> Angus is already in kolla-mesos-core but doesn't have broad ability to >> approve

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

+1 on condition that he will appear in kolla itself, after all...you'll be a kolla core as well right?;) On 19 February 2016 at 21:44, Sam Yaple wrote: > +1 of course. I mean, its Angus. Who can say no to Angus? > > Sam Yaple > > On Fri, Feb 19, 2016 at 10:57 PM, Michal

Re: [openstack-dev] [Octavia] [Tempest] Tempest tests using tempest-plugin

All the code that is in tempest-lib is stable interface that can be consumed safely. The code in tempest instead does not provide a guaranteed stable interface, as it was not originally meant for external consumption. So while you can import it, it may change without warning (i.e. with no new

Re: [openstack-dev] [all] Please do *not* use git (and specifically "git log") when generating the docs

On 02/19/2016 05:39 AM, Dolph Mathews wrote: > > On Thu, Feb 18, 2016 at 11:17 AM, Thomas Goirand > wrote: > > Hi, > > I've seen Reno doing it, then some more. It's time that I raise the > issue globally in this list before the epidemic