[openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers

Team, I’d like to promote Anastasia Kuznetsova to the core team. What she’s been doing for 2 years is hard to overestimate. She’s done a huge amount of work reviewing code, bugfixing and participating in public discussions including our IRC channel #openstack-mistral. She is very reliable,

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

The way I'd recommend is to write your own manifests that include the openstack modules. I'd use roles and profiles which make it easy to move things around, but two simple manifests will also work. As Emilien once said we give you the ingredients but don't cook for you. If you want to just do two

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

Hi, I disagree with Bogdan. We have the same case in OpenStack components. 1. As a compony we may have own patches on top of 'master'. 2. There is no way to use tags on upstream modules so it will be very hard to support it. If we need to deliver fix in previous release there won't be simple way

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Hi, I agree with this view point. Let me provide Solum team's perspective on this. Solum currently uses Heat to deploy application docker containers that it creates. We have been looking at Magnum as an alternative deployment mechanism. The fact that Magnum is supporting containers endpoint

Re: [openstack-dev] [neutron][dvr]

Hi Sudhakar, I don’t think there was any specific reason behind this. But we can definitely check for the config flag and then add the topic ‘dvr_update’. Go ahead and file a bug and we can address it. Thanks Swami From: Sudhakar Gariganti [mailto:sudhakar.gariga...@gmail.com] Sent: Wednesday,

[openstack-dev] [watcher] Travel logistics for mid-cycle in Austin

Hi Watcher Team, For those of you attending the Watcher mid-cycle next week in Austin (Tue-Thurs), please take a quick look at the travel details [1] — particularly the bit about where to “check in” every day once you arrive to the IBM campus. As another FYI, light breakfast foods, lunch and

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

On Thu, Jan 28, 2016 at 9:31 AM, Sergii Golovatiuk wrote: > Hi, > > I disagree with Bogdan. We have the same case in OpenStack components. > > 1. As a compony we may have own patches on top of 'master'. > 2. There is no way to use tags on upstream modules so it will be

Re: [openstack-dev] [api] service type vs. project name for use in headers

On Thu, 2016-01-28 at 11:06 +, Chris Dent wrote: > I think it is high time we resolve the question of whether the > api-wg guidelines are evaluating existing behaviors in OpenStack and > blessing the best or providing aspirational guidelines of practices > which are considered best at a more

[openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Recently I tried started to use oslo.versionedobjects for a project. After playing around with it for a while, I noticed I could set "this is not a uuid" as the value of a UUIDField. After making sure I made no mistakes - I looked at the underlying code, and found:[0] class UUID(FieldType):

Re: [openstack-dev] [keystone] changes to keystone-core!

CONGRATULATIONS Dave and Samuel. Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: "Steve Martinelli" To: openstack-dev

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

> How are we handling this now for multiple plugins? OK, so right now we can only add VIPs to array, we can't remove them. So overriding would disable such possibility of adding VIPs from different plugins. But with [0] patch it will be still possible to add and to remove by providing empty

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Good idea, overally. How about multiple plugins? We don't have any sequence or priorities between them. What if one plugin assumes that VIP is present but other one wants to remove it? Aleksey Kasatkin On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk wrote: > +1

Re: [openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

My big +1 for Dmitry! On Thu, Jan 28, 2016 at 5:40 PM, Doug Hellmann wrote: > Excerpts from Davanum Srinivas (dims)'s message of 2016-01-28 09:25:56 > -0600: > > Team, > > > > Dmitry has been focused solely on the Pika Driver this cycle: > >

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Roman, please provide more details on how VIPs are overridden. And how do you deal with multiple plugins. Aleksey Kasatkin On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin wrote: > Good idea, overally. > > How about multiple plugins? We don't have any sequence or

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

On 22.01.2016 13:56, Bogdan Dobrelya wrote: > On 22.01.2016 12:19, Matthew Mosesohn wrote: >> +1 for defaulting to upstream for CI. If we have a strong case where we >> need to make a patch in order to make unit tests pass, we could switch a >> module back to

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Well, with merging instead of overriding, I believe, this problem with multiple plugins still exists, right? How are we handling this now for multiple plugins? Since VIPs is array I also vote for overriding, since merging it could be a pain (how do you remove existing element during array merge?).

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

I think that's the sane thing to do. David On Thu, Jan 28, 2016 at 2:55 AM, Richard Jones wrote: > Hi fellow angular/REST Horizon developers, > > I'd like to propose that we handle HTTP 401 responses at the core of the new > angular code interfacing to our new REST API

Re: [openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

Excerpts from Davanum Srinivas (dims)'s message of 2016-01-28 09:25:56 -0600: > Team, > > Dmitry has been focused solely on the Pika Driver this cycle: > http://stackalytics.com/?user_id=dukhlov=commits > > Now that we have Pika driver in master, i'd like to invite Dmitry to > continue his work

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

On 01/28/2016 10:14 AM, Matt Fischer wrote: > The way I'd recommend is to write your own manifests that include the > openstack modules. I'd use roles and profiles which make it easy to move > things around, but two simple manifests will also work. As Emilien once > said we give you the

[openstack-dev] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

Team, Dmitry has been focused solely on the Pika Driver this cycle: http://stackalytics.com/?user_id=dukhlov=commits Now that we have Pika driver in master, i'd like to invite Dmitry to continue his work on all of Oslo.Messaging in addition to Pika. Clearly over time he will expand to other Oslo

Re: [openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

I see ,that it has a assigned bug. So we can process it as normal backport (although it looks as a small enhancement). So Please just propose patch and we will review it. On 28 January 2016 at 23:45, Martinx - ジェームズ wrote: > Guys, > > This is important and Kilo is

Re: [openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

Kilo is in the "security supported" stage of the lifecycle. So no, that's not going to get backported. http://docs.openstack.org/releases/index.html -- Sean M. Collins __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers

A very big +1 From: Renat Akhmerov [rakhme...@mirantis.com] Sent: Friday, January 29, 2016 8:13 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

+1 Go team oslo :-) -Josh On 01/28/2016 05:40 PM, Davanum Srinivas wrote: +1 from me! -- Dims On Thu, Jan 28, 2016 at 4:05 PM, Doug Hellmann wrote: I am nominating Alexis Lee (lxsli) for oslo-core. Alexis has been working on adding configuration file reloading to

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

> On 28 Jan 2016, at 17:40, Matt Riedemann wrote: > > With regards to the trove 'plugin' stuff, it adds a new dependency on > python-troveclient which was not in sahara 1.0.0 in liberty GA, so IMO it's > not valid to release that in 1.0.1 and expect people to have

Re: [openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

Let's do it, +1 -Josh On 01/28/2016 05:41 PM, Davanum Srinivas wrote: +1 from me! -- Dims On Thu, Jan 28, 2016 at 4:00 PM, Doug Hellmann wrote: I am nominating Ronald Bradford (rbradfor) for oslo-core. Ronald has been working this cycle to learn about oslo.context,

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

AFAIC, it is better to remove by name then. Otherwise, you do not know what VIPs you are removing. Another option - remove "built-in" VIPs using some specific expression. Anyway, you do not know where other VIPs (VIPs of other plugins) live so you cannot remove them this way. And the order of

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

I am assuming that you meant redirecting on the server side. We already have a similar one in place on the client side. https://github.com/openstack/horizon/blob/master/horizon/static/framework/framework.module.js#L65   Currently, you're not able to hit the REST layer directly anyway, You get a

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Graham, Quite unfair characterization of Oslo being -2 heavy. Please compare stats before making such an assertion: http://russellbryant.net/openstack-stats/oslo-reviewers-365.txt http://russellbryant.net/openstack-stats/nova-reviewers-365.txt

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: > Recently I tried started to use oslo.versionedobjects for a project. > > After playing around with it for a while, I noticed I could set "this is > not a uuid" as the value of a UUIDField. > > After making sure I made no

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Hayes, Graham wrote: Also, olso seem to be very-2 heavy. This means that alternative views on the review are very unlikely. My question is what is the difference between a-1 and a-2 for oslo? If this is the case I am sorry about it, and I'd also like to think that we (as the oslo team)

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 18:44, Davanum Srinivas wrote: > Graham, > > Quite unfair characterization of Oslo being -2 heavy. Please compare > stats before making such an assertion: OK - that was probably my frustration boiling over at the time. I should not have made that generalization. I had been involved

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 01/28/2016 01:52 PM, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >> Recently I tried started to use oslo.versionedobjects for a project. >> >> After playing around with it for a while, I noticed I could set "this is >> not a uuid" as the value of

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 19:13, Mike Bayer wrote: > > > On 01/28/2016 01:52 PM, Doug Hellmann wrote: >> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >>> >>> The steps I had looked at doing was this: >>> >>> 1. Allow a "validate" flag on the Field __init__() defaulting to False. >>>

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 18:54, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >> Recently I tried started to use oslo.versionedobjects for a project. >> >> After playing around with it for a while, I noticed I could set "this is >> not a uuid" as the value of a

Re: [openstack-dev] [puppet] separated controller/compute installations using puppet modules

Thanks to both of you guys for detailed answer with valuable hints, My interest is maybe slightly different as I don't have own recipe for cooking "special openstack", What I am looking for is some standardized method of openstack deployment, which is for me just a kind of entry point. Our

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 19:02:57 +: > On 28/01/2016 18:44, Davanum Srinivas wrote: > > Graham, > > > > Quite unfair characterization of Oslo being -2 heavy. Please compare > > stats before making such an assertion: > > OK - that was probably my frustration boiling

Re: [openstack-dev] [Neutron][Networking-ovn] Instances on the compute node can not get IP address from DHCP

Hi, Checked with Chen for ofproto/trace for the drop flow on controller node: sudo ovs-appctl ofproto/trace

[openstack-dev] log processing project

hi folks, just querying before i do anything, i was wondering if there's a log processing project out there? or is everyone just using ELK stack? cheers, -- gord __ OpenStack Development Mailing List (not for usage

[openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

I am nominating Ronald Bradford (rbradfor) for oslo-core. Ronald has been working this cycle to learn about oslo.context, oslo.log, and oslo.config. He anticipates picking up the much-needed work on the app-agnostic-logging blueprint, and has already started making incremental changes related to

[openstack-dev] [oslo] nominating Alexis Lee for oslo-core

I am nominating Alexis Lee (lxsli) for oslo-core. Alexis has been working on adding configuration file reloading to oslo.config this cycle. The work isn't complete, but at this point he probably knows as much or more about the internals of that library as any of us. :-) He has also shown, with

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Ryan Rossiter wrote: As the-guy-in-nova-that-does-this-a-bunch, I’ve pushed a bunch of changes to nova because we didn’t have them yet in o.vo, and once they get released, I “re-sync” them back to nova to use the o.vo version, see: https://review.openstack.org/#/c/272641/

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 4:04 PM, Joshua Harlow wrote: > > Ryan Rossiter wrote: >> >> As the-guy-in-nova-that-does-this-a-bunch, I’ve pushed a bunch of changes to >> nova because we didn’t have them yet in o.vo, and once they get released, I >> “re-sync” them back to nova

Re: [openstack-dev] log processing project

Kolla wants to do a PoC [1] with Heka [2] [1]: https://review.openstack.org/#/c/270906/ [2]: https://github.com/mozilla-services/heka David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Thu, Jan 28, 2016 at 5:34 PM, gordon chung

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> I know we have some projects (heat, I think?) that don't have UUIDs at > all. Are they using oslo.versionedobjects? I suppose we could move them > to a string field instead of a UUID field, instead of flipping the > enforcement flag on. Alternately, if we add a new class we wouldn't have > to

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

Hmm. That client-side redirect isn't working consistently then. More investigation required... On 29 January 2016 at 05:04, Thai Q Tran wrote: > I am assuming that you meant redirecting on the server side. We already > have a similar one in place on the client side. >

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: > On 28/01/2016 18:54, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: > >> Recently I tried started to use oslo.versionedobjects for a project. > >> > >> After playing around with it

[openstack-dev] [release][oslo] futurist release 0.10.0 (mitaka)

We are satisfied to announce the release of: futurist 0.10.0: Useful additions to futures, from the future. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/futurist With package available at:

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

Excerpts from Hayes, Graham's message of 2016-01-28 20:42:39 +: > On 28/01/2016 20:16, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: > >> On 28/01/2016 18:54, Doug Hellmann wrote: > >>> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

On 2016-01-28 19:40:20 + (+), Dave Walker wrote: [...] > However, pip 8 was released around the same time as the tarballs were > attempted to be generated. Most of the projects are OK with this, but > ceilometer declares pbr!=0.7,<1.0,>=0.6 and then forces an update via > tox. [...] More

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

On 28/01/2016 20:16, Doug Hellmann wrote: > Excerpts from Hayes, Graham's message of 2016-01-28 19:17:54 +: >> On 28/01/2016 18:54, Doug Hellmann wrote: >>> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: Recently I tried started to use oslo.versionedobjects for a

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 1:10 PM, Mike Bayer wrote: > > > > On 01/28/2016 01:52 PM, Doug Hellmann wrote: >> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +: >>> Recently I tried started to use oslo.versionedobjects for a project. >>> >>> After playing

[openstack-dev] [Nova][Neutron] Scheduling with routed networks

Hi Nova and Neutron, It was a pleasure to attend the Nova mid-cycle in Bristol this week. I think we made a lot of progress. I spent a little time capturing the highlights of what we discussed about scheduling and routed networks in a new revision to the backlog spec [1] that I created a couple

[openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

Hi, As many of you have probably seen, most of the projects targeted for 2015.1.3 release have been tagged and have tarballs ready for release. However, pip 8 was released around the same time as the tarballs were attempted to be generated. Most of the projects are OK with this, but ceilometer

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

> On Jan 28, 2016, at 1:32 PM, Doug Hellmann wrote: > > Excerpts from Hayes, Graham's message of 2016-01-28 19:02:57 +: >> On 28/01/2016 18:44, Davanum Srinivas wrote: >>> Graham, >>> >>> Quite unfair characterization of Oslo being -2 heavy. Please compare >>> stats

Re: [openstack-dev] [Horizon] Recent integration tests failures

According to the results at https://review.openstack.org/#/c/273697/1 capping Selenium to be not greater than 2.49 fixes broken tests. Patch to global-requirements is here: https://review.openstack.org/#/c/273750/ On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev wrote: >

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 27 January 2016 at 11:06, Flavio Percoco wrote: > FWIW, the current governance model does not prevent competition. That's > not to > be understood as we encourage it but rather than there could be services > with > some level of overlap that are still worth being separate.

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/26/2016 01:48 PM, Kevin Carter wrote: > I personally think it'd be great to see this feature in OSA and I look > forward to reviewing the spec. The first draft of the spec is in Gerrit: https://review.openstack.org/#/c/273749/ I

[openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

Guys, This is important and Kilo is missing it: https://review.openstack.org/#/c/179989/ Is it possible to backport it to Kilo 2015.1.3? Currently, I am manually patching Kilo / Heat by using the following diff:

[openstack-dev] [puppet] let's start using reno

Last month, we decided [1] to give a try to reno, the release management tool in OpenStack. During the sprint, I worked with Doug to make it happen. We have now reno in place for puppet-keystone: http://docs.openstack.org/releasenotes/puppet-keystone/ What are the next steps: * our

Re: [openstack-dev] [puppet] let's start using reno

At the beginning it will be hard, but this change came to help everyone. Congratulations for everyone that made this possible. 2016-01-28 18:25 GMT-03:00 Emilien Macchi : > Last month, we decided [1] to give a try to reno, the release management > tool in OpenStack. > >

[openstack-dev] [sahara][stable] stable/kilo blocked for sahara

All changes to Sahara on stable/kilo are blocked on the version change patch here: https://review.openstack.org/#/c/273011/ But that can't land because the gate-tempest-dsvm-sahara job is failing: http://logs.openstack.org/11/273011/1/check/gate-tempest-dsvm-sahara/f5d427f/ It's failing

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

On 01/28/2016 06:03 AM, Steven Dake (stdake) wrote: The TC set precedent in this first competition-induced review which is worth a good read for other projects thinking of competing with existing projects of which there are already plenty in OpenStack.. https://review.openstack.org/206789

Re: [openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

HI, For Magnum, The community keep upstream development since Kilo. Magnum has some dependence on Keystone, Nova, Glance, Heat, Cinder. If you try to use Liberty Magnum against with Icehouse and Kilo OpenStack. It depends on related if heat templates include any non-icehouse, kilo resources.

Re: [openstack-dev] [TripleO] spec-lite process for tripleo

On Wed, Jan 27, 2016 at 08:01:31PM -0700, Jason Rist wrote: > On 01/27/2016 09:21 AM, Derek Higgins wrote: > > Hi All, > > > > We briefly discussed feature tracking in this weeks tripleo meeting. I > > would like to provide a way for downstream consumers (and ourselves) to > > track new features

Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. race conditions)?

> -Original Message- > From: Cheng, Yingxin [mailto:yingxin.ch...@intel.com] > Sent: January 28, 2016 04:21 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. > race conditions)? > > Thank you

[openstack-dev] [Magnum] Use Liberty Magnum bits with Kilo/ Icehouse Openstack ?

A newbie question ... Is it described somewhere what exactly is the set of Liberty dependencies for Magnum ? Since a significant fraction of it is orchestration templates, one would expect it should be possible to run Liberty Magnum bits along with an Icehouse or Kilo version of Openstack.

[openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 2-4, 2016 RSVP by Friday, February 19 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Wed, Jan 27, 2016 at 10:22:54AM -0500, Dan Prince wrote: > On Wed, 2016-01-27 at 09:36 -0500, Dan Prince wrote: > > On Wed, 2016-01-27 at 14:32 +0100, Jiri Tomasek wrote: > > > On 01/26/2016 09:05 PM, Ben Nemec wrote: > > > > On 01/25/2016 04:36 PM, Dan Prince wrote: > > > > > On Mon,

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

> On 27 Jan 2016, at 19:14, Matt Riedemann wrote: > > Starting with stable/liberty, each project now owns when to do point releases > for their stable branches (rather than a large coordinated stable branch > point release that the stable-maint-core team does). >

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/27/2016 08:31 PM, Dean Troyer wrote: On Wed, Jan 27, 2016 at 1:47 PM, michael mccune > wrote: i am not convinced that we would ever need to have a standard on how these names are chosen for the header values, or if we would even need to

[openstack-dev] Announcing Debian Mitaka b2 packages with backports for Jessie and Trusty

Hi everyone, I'm delighted to announce the release of Debian packages for Mitaka b2. Debian Experimental === I have uploaded it all to Debian Experimental. This is the only place where you may find official packages. It will stay this way until Debian Bikesheds (Bikesheds is what

[openstack-dev] [all][i18n] Rework of translation setup

Projects that want to setup translations for their repositories run into a few common problems and we're addressing these now to make the setup for everybody easier. The problems they run into came from limitations of the current infra scripts, so we rework the infra scripts. We want to have a

Re: [openstack-dev] [all][i18n] Rework of translation setup

Correction: b) affects also: openstack/ironic-inspector openstack/networking-l2gw openstack/networking-ovn openstack/neutron-fwaas openstack/neutron-lbaas openstack/neutron-lib openstack/vmware-nsx Andreas On 2016-01-28 13:13, Andreas Jaeger wrote: > Projects that want to setup translations for

Re: [openstack-dev] [Neutron][L3] Orphaned process cleanup

Sean M. Collins wrote: Hi, I started poking a bit at https://bugs.launchpad.net/devstack/+bug/1535661 We have radvd processes that the l3 agent launches, and if the l3 agent is terminated these radvd processes continue to run. I think we should probably terminate them

Re: [openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

Thanks! On 28/01/16 00:23, Armando M. wrote: > I'll kill it, as this should be superseded by the in-tree devref version. > > Thanks for pointing my attention to it. > > On 27 January 2016 at 23:40, Neil Jerram > wrote: > > Is

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

> On 27 January 2016 at 08:10, Tzu-Mainn Chen < tzuma...@redhat.com > wrote: > > > Okay, so I initially thought we weren't making much progress on this > > > > discussion, but after some more thought and reading of the existing PoC, > > > > we're (maybe?) less far apart than I initially

[openstack-dev] [Fuel] Overriding and removing VIPs from plugins

Folks, currently merge policy for network roles only allows to add new VIPs to already existing roles [1]. If a plugin supplies a VIP with a name that already exists but with different parameters, Nailgun will not allow to do that. We faced a need to override configuration of several VIPs by

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

+1 to overriding VIPs On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko wrote: > Folks, > > currently merge policy for network roles only allows to add new VIPs to > already existing roles [1]. If a plugin supplies a VIP with a name that > already exists but with different

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

On 27.01.2016 14:44, Simon Pasquier wrote: > Hi, > > I see that tasks.yaml is going to be deprecated in the future MOS > versions [1]. I've got one question regarding the ordering of tasks > between different plugins. > With tasks.yaml, it was possible to coordinate the execution of tasks >

Re: [openstack-dev] [api] service type vs. project name for use in headers

Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

On 1/28/2016 9:35 AM, Renat Akhmerov wrote: On 27 Jan 2016, at 19:14, Matt Riedemann wrote: Starting with stable/liberty, each project now owns when to do point releases for their stable branches (rather than a large coordinated stable branch point release

[openstack-dev] [Horizon] Handling 401 in new REST API

Hi fellow angular/REST Horizon developers, I'd like to propose that we handle HTTP 401 responses at the core of the new angular code interfacing to our new REST API so that *any* 401 just does basically what the Django code used to: redirect to the login page with a "from". What do y'all think?

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

On Thu, Jan 28 2016, Foley, Emma L wrote: > So, metrics are grouped by the type of resource they use, and each metric has > to be listed. > Grouping isn't a problem, but creating an exhaustive list might be, since > there > are 100+ plugins [1] in collectd which can provide statistics, although

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

> From: Ronald Bradford [mailto:m...@ronaldbradford.com] > Sent: Wednesday, January 20, 2016 6:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Oslo] Improving deprecated options > identification and documentation > > Markus, > >  >> Yes,

[openstack-dev] project overlap (was Re: Announcing Ekko -- Scalable block-based backup for OpenStack)

On Thu, 28 Jan 2016, Jay Pipes wrote: It was Joe Gordon and others who advised that there was nothing in the project acceptance criteria that mentioned a lack of API overlap as a condition for inclusion. Let's be honest: From my perspective Joe (and others) had it in for Ceilometer and was

Re: [openstack-dev] [api] service type vs. project name for use in headers

On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them to wade through, the API-WG is making great gains in herding those particular cats, I would hate to see giving back some

Re: [openstack-dev] OpenStack installer

Hi Kevin! We'll see when Mitaka arrives. I still have some trust in the good old apt-get (or yum or dnf) upgrade method :) Br, György > -Original Message- > From: Kevin Carter [mailto:kevin.car...@rackspace.com] > Sent: 2016 január 27, szerda 23:03 > To: OpenStack Development Mailing

[openstack-dev] [Horizon] Recent integration tests failures

Hello, Horizoneers You may have noticed recent integration tests failures seemingly unrelated to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've already filed a bug for that, https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium issue, currently

Re: [openstack-dev] [Neutron][Networking-ovn] Instances on the compute node can not get IP address from DHCP

Yes, I installed controller node at first, and then add the compute node. The last commit for ovs on controller nodes ovs is on "Jan 11", while the compute node has newer code with the last commit at Jan 20. I re-installed devstack on controller node, and everything looks fine now. Thanks very

Re: [openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

+1 from me! -- Dims On Thu, Jan 28, 2016 at 4:00 PM, Doug Hellmann wrote: > I am nominating Ronald Bradford (rbradfor) for oslo-core. > > Ronald has been working this cycle to learn about oslo.context, > oslo.log, and oslo.config. He anticipates picking up the much-needed

[openstack-dev] What's Up, Doc? 29 January 2016

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, An incredibly hot week here in the antipodes, coupled with Australia Day has meant that I haven't been particularly productive this week. Luckily, the rest of you have picked up the slack, and things have been ticking along nicely.

Re: [openstack-dev] [neutron][dvr]

Ok. Thanks for the response Swami. Filed a defect [1] for tracking this.. [1] https://bugs.launchpad.net/neutron/+bug/1539387 Thanks, Sudhakar. On Thu, Jan 28, 2016 at 10:34 PM, Vasudevan, Swaminathan (PNB Roseville) < swaminathan.vasude...@hpe.com> wrote: > Hi Sudhakar, > > I don’t think

Re: [openstack-dev] [api] service type vs. project name for use in headers

I'd like an answer on this specific issue. I agree with Chris and I wonder if our goal is consistency across services or an ideal standard. Nova has 'X-OpenStack-Nova-API-Version' and Manila has 'X-Openstack-Manila-Api-Version'. If we deviate from this, we should suggest that those projects add

Re: [openstack-dev] [TripleO] changes in irc alerts

On 01/27/2016 05:02 PM, James Slagle wrote: > On Tue, Jan 26, 2016 at 7:15 PM, Derek Higgins wrote: > >> Hi All, >> >> For the last few months we've been alerting the #tripleo irc channel when >> a card is open on the tripleo trello org, in the urgent list. >> >> When used I

Re: [openstack-dev] [keystone] changes to keystone-core!

Hey, Thanks for trusting me. I will do my best to make OpenStack even better. Regards, Samuel On Wed, Jan 27, 2016 at 8:34 PM, Chen, Wei D wrote: > Hi, > > > > Many thanks to everyone for your patient guidance and mentoring me in the > past years! It’s your help to

[openstack-dev] [puppet] separated controller/compute installations using puppet modules

Hi All, I have one very general question, we would like to deploy role-separated (compute & controller) openstack via puppet modules. Unfortunately puppet-openstack-integration supports only “all-in-one” scenarios. https://github.com/openstack/puppet-openstack-integration this project looks

Re: [openstack-dev] [keystone] changes to keystone-core!

On 01/28/2016 02:34 AM, Chen, Wei D wrote: > Hi, > > > > Many thanks to everyone for your patient guidance and mentoring me in the > past years! It's your help to make me grow up from a > newbie! > > > > As a core project in OpenStack, keystone has grown to be several > sub-projects,

Re: [openstack-dev] [murano] Nominate Victor Ryzhenkin to Murano Core

Victor, welcome! On Thu, Jan 28, 2016 at 5:57 AM, Kirill Zaitsev wrote: > > +1 from me. Victor’s continued work on keeping our gates green and stable is > invaluable. His contribution during M cycle is also very impressive. Looking > forward to seeing him one of the

Re: [openstack-dev] [api] service type vs. project name for use in headers

On 01/28/2016 06:32 AM, Jay Pipes wrote: Couldn't agree more, Chris. -jay On 01/28/2016 11:06 AM, Chris Dent wrote: On Wed, 27 Jan 2016, Dean Troyer wrote: I think we would be better served in selecting these things thinking about the API consumers first. We already have enough for them

  1   2   >