Re: [openstack-dev] Which program for Rally

Hi John, see below. Zitat von John Griffith : I have to agree with Duncan here. I also don't know if I fully understand the limit in options. Stress test seems like it could/should be different This is correct, Rally and Tempest Stress test have a different focus. The stress test framework

Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

On 06/08/14 14:01, Timur Sufiev wrote: Hi! Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113 The question is whether the python-pillow package really needed for proper compiling css from scss in Horizon or is it an optional requirement which can be safely dropped? The p

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

Hi Michael, Not sure if I am getting your right. I think your proposal doesn't not perform well in reality. Firstly, it is difficult to guess a good time that fix all problems, except you take "forever". Just take the volume creation in my bugfix as example (https://review.openstack.org/#/c

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and theway forward

And while we are on this, just wanted to remind all those interested to attend the weekly GBP meeting later today: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy On Wed, Aug 6, 2014 at 8:12 PM, Mike Cohen wrote: > Its good to see such a lively debate about this topic. With the dis

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

Hi Brandon, I don't think we've set a specific date to make the transition to IRC meetings. Is there a particular urgency about this that we should be aware of? Stephen On Wed, Aug 6, 2014 at 7:58 PM, Brandon Logan wrote: > When is the plan to move the meeting to IRC? > > On Wed, 2014-08-06 a

Re: [openstack-dev] [Octavia] Minutes from 8/6/2014 meeting

Wow, Trevor! Thanks for capturing all that! On Wed, Aug 6, 2014 at 9:47 PM, Trevor Vardeman < trevor.varde...@rackspace.com> wrote: > Agenda items are numbered, and topics, as discussed, are described beneath > in list format. > > 1) Octavia Constitution and Project Direction Documents (Road map

Re: [openstack-dev] [Octavia] Minutes from 8/6/2014 meeting

On where to capture notes like this long-term: I would say the wiki is more searchable for now. When we make the transition to IRC meetings, then the meeting bots will capture minutes and transcripts in the usual way and we can link to these from the wiki. On Thu, Aug 7, 2014 at 1:29 AM, Stephen

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

I had to put the patch back on WIP because yesterday a bug causing a 100% failure rate slipped in. It should be an easy fix, and I'm already working on it. Situations like this, exemplified by [1] are a bit frustrating for all the people working on improving neutron quality. Now, if you allow me a

Re: [openstack-dev] [all] The future of the integrated release

Stefano Maffulli wrote: > On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote: >> - we rate limit the total number of blueprints under code review at >> any one time to a fixed number of "slots". I secretly prefer the term >> "runway", so I am going to use that for the rest of this email. A >>

[openstack-dev] [nova] nova-network stuck at get semaphores lock when startup

When I startup nova-network, it stuck at trying get lock for ebtables. @utils.synchronized('ebtables', external=True) def ensure_ebtables_rules(rules, table='filter'): . Checking the code found that invoke utils.synchronized without parameter lock_path, the code will try to use posix s

Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

Thanks, now it is clear that this requirement can be safely dropped. On Thu, Aug 7, 2014 at 11:33 AM, Matthias Runge wrote: > On 06/08/14 14:01, Timur Sufiev wrote: >> >> Hi! >> >> Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113 >> >> The question is whether the python

Re: [openstack-dev] [all] The future of the integrated release

On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote: > On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote: > > > We seem to be unable to address some key issues in the software we > > produce, and part of it is due to strategic contributors (and core > > reviewers) being overwhelmed j

Re: [openstack-dev] [nova] nova-network stuck at get semaphores lock when startup

Just to clarify , I think your case would be run nova-network ,then ^C or abnormally shutdown it and it might be during the period of holding a semaphore without releasing it, right? guess all component other than nova have this problem ? so maybe remove this [nova] can get more input ... Best

Re: [openstack-dev] [nova] nova-network stuck at get semaphores lock when startup

On 2014?08?07? 17:13, Chen CH Ji wrote: Just to clarify , I think your case would be run nova-network ,then ^C or abnormally shutdown it and it might be during the period of holding a semaphore without releasing it, right? yes, you are right. thanks for the clarify. guess all component ot

[openstack-dev] introducing cyclops

Dear All, Let me use my first post to this list to introduce Cyclops and initiate a discussion towards possibility of this platform as a future incubated project in OpenStack. We at Zurich university of Applied Sciences have a python project in open source (Apache 2 Licensing) that aims to provid

Re: [openstack-dev] [Ironic] call for operator-focused docs

Hi Devananda, I have been working on the documentation of some of the areas you listed. I have updated the bug https://bugs.launchpad.net/ironic/+bug/1323589 by including the other requirements which I haven't documented yet. Regards, Vinay -Original Message- From: Devananda van der Ve

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Armando M. wrote: > This thread is moving so fast I can't keep up! > > The fact that troubles me is that I am unable to grasp how we move > forward, which was the point of this thread to start with. It seems we > have 2 options: > > - We make GBP to merge as is, in the Neutron tree, with some min

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Hi folks I think this thread is still mixing topics. I feel we can archive 1000 mails :P so let me name it and let me write my thought on this. [Topic1] Nova parity priority I do understand concern and this is highest priority. However, group based policy effort won't slower this effort. Bec

[openstack-dev] nova-network stuck at get semaphores lock when startup

On 2014?08?07? 17:13, Chen CH Ji wrote: Just to clarify , I think your case would be run nova-network ,then ^C or abnormally shutdown it and it might be during the period of holding a semaphore without releasing it, right? yes, you are right. thanks for the clarify. guess all component

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote: On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote: On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote: We seem to be unable to address some key issues in the software we produce, and part of it is due to strategic contributors (an

Re: [openstack-dev] [Neutron][Nova] API design and usability

On 08/06/2014 11:08 PM, Robert Collins wrote: On 7 August 2014 15:31, Christopher Yeoh wrote: On Thu, 7 Aug 2014 11:58:43 +1200 Robert Collins wrote: ... At the moment when cleaning up we don't know if a port was autocreated by Nova or was passed to us initially through the API. That seems

[openstack-dev] [nova][oslo] oslo.config and import chains

I'm sure this is well known, but I recently encountered this problem for the second time. --- foo: import oslo.config as cfg import bar CONF = cfg.CONF CONF.register_opts('foo_opt') --- bar: import oslo.config as cfg CONF = cfg.CONF def bar_func(arg=CONF.foo_opt): pass --- importing foo re

[openstack-dev] [TripleO] dns for overcloud nodes

Hi, by default we don't set nameserver when setting up neutron subnet used by overcloud nodes, then nameserver points to the machine where undercloud's dnsmasq is running. I wonder if we should not change *default* devtest setup to allow dns resolving not only for local network but for intern

[openstack-dev] Which program for Rally

> > Date: Wed, 06 Aug 2014 09:44:12 -0400 > From: Sean Dague > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Which program for Rally > Message-ID: <53e2312c.8000...@dague.net> > Content-Type: text/plain; charset=utf-8 > > Like the fact that right now the rally team is propos

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

Patch [1] will solve the observed issue. It has already passed Jenkins tests. As it is a nova patch, the neutron full job did not run for it. To check the neutron full job outcome with [1], please check [2]. Salvatore [1] https://review.openstack.org/#/c/112541/ [2] https://review.openstack.org/#

Re: [openstack-dev] [Ironic] Exceptional approval request for Cisco Driver Blueprint

Hi! Didn't read the spec thoroughly, but I'm concerned by it's huge scope. It's actually several specs squashed into one (not too detailed). My vote is splitting it into a chain of specs (at least 3: power driver, discovery, other configurations) and seek exception separately. Actually, I'm +1 on

Re: [openstack-dev] [Neutron][Nova] API design and usability

On 2014-08-06 7:58 PM, Robert Collins wrote: I'm astounded by this proposal - it doesn't remove the garbage collection complexity at all - it transfers it from our code - Nova - onto end users. So rather than one tested and consolidated implementation, we'll have one implementation in saltstack,

Re: [openstack-dev] Which program for Rally

On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote: > I have to agree with Duncan here. I also don't know if I fully > understand the limit in options. Stress test seems like it > could/should be different (again overlap isn't a horrible thing) and I > don't see it as siphoning off resources

[openstack-dev] [NFV] Meeting summary 2014-08-06

Meeting Summary (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.html Meeting Log (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.log.html Meeting Summary (TXT): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.txt M

Re: [openstack-dev] Which program for Rally

On 08/06/2014 05:48 PM, John Griffith wrote: > I have to agree with Duncan here. I also don't know if I fully > understand the limit in options. Stress test seems like it could/should > be different (again overlap isn't a horrible thing) and I don't see it > as siphoning off resources so not sure

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

Hi! On Tue, 2014-08-05 at 12:33 -0700, Devananda van der Veen wrote: > Hi all! > > > The following idea came out of last week's midcycle for how to improve > our spec process and tracking on launchpad. I think most of us liked > it, but of course, not everyone was there, so I'll attempt to write

Re: [openstack-dev] Which program for Rally

On 08/07/2014 07:58 AM, Angus Salkeld wrote: > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote: >> I have to agree with Duncan here. I also don't know if I fully >> understand the limit in options. Stress test seems like it >> could/should be different (again overlap isn't a horrible thing

Re: [openstack-dev] Which program for Rally

On 08/07/2014 07:31 AM, Rohan Kanade wrote: > Date: Wed, 06 Aug 2014 09:44:12 -0400 > From: Sean Dague mailto:s...@dague.net>> > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] Which program for Rally > Messag

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

On 6 August 2014 18:54, Jay Pipes wrote: > So, Liyi Meng has an interesting patch up for Nova: > > https://review.openstack.org/#/c/104876 > > 1) We should just deprecate both the options, with a note in the option help > text that these options are not used when volume size is not 0, and that the

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 04:49 AM, Thierry Carrez wrote: > Stefano Maffulli wrote: >> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote: >>> - we rate limit the total number of blueprints under code review at >>> any one time to a fixed number of "slots". I secretly prefer the term >>> "runway", so I a

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 08:54 AM, Russell Bryant wrote: > On 08/07/2014 04:49 AM, Thierry Carrez wrote: >> Stefano Maffulli wrote: >>> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote: - we rate limit the total number of blueprints under code review at any one time to a fixed number of "slo

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is slot selection would just be Nova drivers. I > think there is an assumption in the old system that everyone in Nova > core wants to prioritize the blueprints. I think there are a bunch of > folks in Nova core that are happy having

Re: [openstack-dev] [all] The future of the integrated release

On 08/06/2014 11:51 AM, Eoghan Glynn wrote: > > >> Hi everyone, >> >> With the incredible growth of OpenStack, our development community is >> facing complex challenges. How we handle those might determine the >> ultimate success or failure of OpenStack. >> >> With this cycle we hit new limits in

Re: [openstack-dev] [all] The future of the integrated release

On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant wrote: > On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is > slot selection would just be Nova drivers. I > > think there is an assumption in the old system that everyone in Nova > > core wants to prioritize the blueprints. I think

Re: [openstack-dev] [all] The future of the integrated release

On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle wrote: > > > > On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant wrote: > >> On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is >> slot selection would just be Nova drivers. I >> > think there is an assumption in the old system that ever

Re: [openstack-dev] [nova] nova-network stuck at get semaphores lock when startup

Unfortunately this is a known issue. We're working on a fix: https://bugs.launchpad.net/oslo/+bug/1327946 On 08/07/2014 03:57 AM, Alex Xu wrote: > When I startup nova-network, it stuck at trying get lock for ebtables. > > @utils.synchronized('ebtables', external=True) > def ensure_ebtables_rules

Re: [openstack-dev] [nova] nova-network stuck at get semaphores lock when startup

Oops, thanks On 2014年08月07日 22:08, Ben Nemec wrote: Unfortunately this is a known issue. We're working on a fix: https://bugs.launchpad.net/oslo/+bug/1327946 On 08/07/2014 03:57 AM, Alex Xu wrote: When I startup nova-network, it stuck at trying get lock for ebtables. @utils.synchronized('ebt

[openstack-dev] [Neutron] Bug squashing day

Hi neutron folks, Today should have been 'Bug squashing day' where we go over existing bugs filed for the project and triage/prioritize/comment on them. I've created an etherpad with (hopefully) full list of neutron bugs: https://etherpad.openstack.org/p/neutron-bug-squashing-day-2014-08-07 I wa

Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS

On 07/08/14 11:11, Timur Sufiev wrote: Thanks, now it is clear that this requirement can be safely dropped. As I said, it's required during build time, if you execute the tests during build. It's not a runtime dependency; the page you were referring to is from the build system. Matthias __

Re: [openstack-dev] [nova] fair standards for all hypervisor drivers

On 7/18/2014 2:55 AM, Daniel P. Berrange wrote: On Thu, Jul 17, 2014 at 12:13:13PM -0700, Johannes Erdfelt wrote: On Thu, Jul 17, 2014, Russell Bryant wrote: On 07/17/2014 02:31 PM, Johannes Erdfelt wrote: It kind of helps. It's still implicit in that you need to look at what features are e

Re: [openstack-dev] [Neutron] Bug squashing day

On Thu, Aug 7, 2014 at 9:31 AM, Eugene Nikanorov wrote: > Hi neutron folks, > > Today should have been 'Bug squashing day' where we go over existing bugs > filed for the project and triage/prioritize/comment on them. > > I've created an etherpad with (hopefully) full list of neutron bugs: > https:

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

Hi Salvatore, I did notice the issue and I flagged this bug report: https://bugs.launchpad.net/nova/+bug/1352141 I'll follow up. Cheers, Armando On 7 August 2014 01:34, Salvatore Orlando wrote: > I had to put the patch back on WIP because yesterday a bug causing a 100% > failure rate slippe

Re: [openstack-dev] Which program for Rally

On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague wrote: > On 08/07/2014 07:58 AM, Angus Salkeld wrote: > > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote: > >> I have to agree with Duncan here. I also don't know if I fully > >> understand the limit in options. Stress test seems like it > >> c

Re: [openstack-dev] introducing cyclops

Hi, are you on IRC? :) Endre 2014-08-07 12:01 GMT+02:00 Piyush Harsh : > Dear All, > > Let me use my first post to this list to introduce Cyclops and initiate a > discussion towards possibility of this platform as a future incubated > project in OpenStack. > > We at Zurich university of Applied

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

Hi Kevin, I feel as your latest response is completely side stepping the points we have been trying to get to in the last series of emails. At the end of the day I don't believe we are changing the laws of networking (or perhaps we are?). Thus I think it's important to actually get down to the ne

Re: [openstack-dev] [TripleO] dns for overcloud nodes

On 08/07/2014 01:32 PM, Jan Provaznik wrote: Hi, by default we don't set nameserver when setting up neutron subnet used by overcloud nodes, then nameserver points to the machine where undercloud's dnsmasq is running. I wonder if we should not change *default* devtest setup to allow dns resolving

Re: [openstack-dev] [nova][oslo] oslo.config and import chains (a proposal to update the style guidelines for imports)

On 07/08/14 12:15, Matthew Booth wrote: > I'm sure this is well known, but I recently encountered this problem for > the second time. > > --- > foo: > import oslo.config as cfg > > import bar > > CONF = cfg.CONF > CONF.register_opts('foo_opt') > > --- > bar: > import oslo.config as cfg > > CON

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: > A (the?) solution is to register_opts() in foo before importing any > modules which might also use oslo.config. Actually, I disagree. The real problem here is the definition of bar_func(). The default value of the parameter "arg" will lik

Re: [openstack-dev] [cinder] The future of the integrated release

On 08/07/2014 09:55 AM, John Griffith wrote: > ​Seems everybody that's been around a while has noticed "issues" this > release and have talked about it, thanks Thierry for putting it together so > well and kicking off the ML thread here. > > I'd agree with everything that you stated, I've also flo

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

On 07/08/14 14:17 +0200, Dmitry Tantsur wrote: 2. We'll need to speed up spec reviews, because we're adding one more blocker on the way to the code being merged :) Maybe it's no longer a problem actually, we're doing it faster now. I'm not sure if this will actually delay stuff getting merged.

Re: [openstack-dev] [git-review] Supporting development in local branches

On 08/06/2014 05:35 PM, Yuriy Taraday wrote: > Oh, looks like we got a bit of a race condition in messages. I hope you > don't mind. > > > On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec wrote: > >> On 08/06/2014 01:42 PM, Yuriy Taraday wrote: >>> On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec >> wrote:

Re: [openstack-dev] [cinder] The future of the integrated release

On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney wrote: > On 08/07/2014 09:55 AM, John Griffith wrote: > > ​Seems everybody that's been around a while has noticed "issues" this > > release and have talked about it, thanks Thierry for putting it together > so > > well and kicking off the ML thread here

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

Thanks Armando, The fix for the bug you pointed out was the reason of the failure we've been seeing. The follow-up patch merged and I've removed the wip status from the patch for the full job [1] Salvatore [1] https://review.openstack.org/#/c/88289/ On 7 August 2014 16:50, Armando M. wrote:

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote: On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modules which might also use oslo.config. Actually, I disagree. The real problem here is the definition of bar_func().

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 03:20 PM, Russell Bryant wrote: > On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is > slot selection would just be Nova drivers. I >> think there is an assumption in the old system that everyone in Nova >> core wants to prioritize the blueprints. I think there are a

Re: [openstack-dev] [cinder] The future of the integrated release

On 7 August 2014 16:39, John Griffith wrote: > On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney wrote: >> On 08/07/2014 09:55 AM, John Griffith wrote: >> > There are three things that have just crushed productivity and >> > motivation >> > in Cinder this release (IMO): >> > 1. Overwhelming number of d

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote: > > On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote: > > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: > >> A (the?) solution is to register_opts() in foo before importing any > >> modules which might also use oslo.config. > > > > Ac

Re: [openstack-dev] [Neutron] Bug squashing day

Thanks Eugene for initiating Neutron bug squashing day! I would like to focus on bug triaging and checking bug status rather than fixing bugs. There seem be many bugs which are not valid anymore. Thanks, Akihiro On Thu, Aug 7, 2014 at 11:31 PM, Eugene Nikanorov wrote: > Hi neutron folks, > > Tod

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On 07/08/14 16:27, Kevin L. Mitchell wrote: > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: >> A (the?) solution is to register_opts() in foo before importing any >> modules which might also use oslo.config. > > Actually, I disagree. The real problem here is the definition of > bar_func

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

> That's different behaviour, because you can no longer pass arg=None. The > fix isn't to change the behaviour of the code. So use a sentinel... --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@l

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote: > On 07/08/14 16:27, Kevin L. Mitchell wrote: > > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: > >> A (the?) solution is to register_opts() in foo before importing any > >> modules which might also use oslo.config. > > > > Actually

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On 07/08/14 17:11, Kevin L. Mitchell wrote: > On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote: >> >> On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote: >>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modul

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On 07/08/14 17:34, Dan Smith wrote: >> That's different behaviour, because you can no longer pass arg=None. The >> fix isn't to change the behaviour of the code. > > So use a sentinel... That would also be a change to the behaviour of the code, because you can no longer pass in the sentinel. The

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On 07/08/14 17:39, Kevin L. Mitchell wrote: > On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote: >> On 07/08/14 16:27, Kevin L. Mitchell wrote: >>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any modules whic

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

You said you had no idea what group based policy was buying us so I tried to illustrate what the difference between declarative and imperative network configuration looks like. That's the major selling point of GBP so I'm not sure how that's 'side stepping' any points. It removes the need for the u

Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process

On August 7, 2014 at 8:36:16 AM, Matt Wagner (matt.wag...@redhat.com) wrote: On 07/08/14 14:17 +0200, Dmitry Tantsur wrote:    >2. We'll need to speed up spec reviews, because we're adding one more  >blocker on the way to the code being merged :) Maybe it's no longer a  >problem actually, we're doi

Re: [openstack-dev] Which program for Rally

On Thu, Aug 7, 2014 at 9:02 AM, John Griffith wrote: > > > > On Thu, Aug 7, 2014 at 6:20 AM, Sean Dague wrote: > >> On 08/07/2014 07:58 AM, Angus Salkeld wrote: >> > On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote: >> >> I have to agree with Duncan here. I also don't know if I fully >> >

Re: [openstack-dev] [Neutron] Bug squashing day

I will be around today. I can help on bug triaging.. Catch me on IRC (emagana) Thank for coordinating this Eugene! Edgar On 8/7/14, 9:19 AM, "Akihiro Motoki" wrote: >Thanks Eugene for initiating Neutron bug squashing day! >I would like to focus on bug triaging and checking bug status rather >t

[openstack-dev] [Heat] Passing a list of ResourceGroup's attributes back to its members

Hi all, I have a ResourceGroup which wraps a custom resource defined in another template: servers: type: OS::Heat::ResourceGroup properties: count: 10 resource_def: type: my_custom_server properties: prop_1: "..." prop_2:

Re: [openstack-dev] [Neutron] Bug squashing day

Indeed, thanks much Eugene for taking on this critical activity. Please let me know if I can help in any way as well. On Thu, Aug 7, 2014 at 7:39 AM, Kyle Mestery wrote: > On Thu, Aug 7, 2014 at 9:31 AM, Eugene Nikanorov > wrote: >> Hi neutron folks, >> >> Today should have been 'Bug squashing d

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 01:49 AM, Thierry Carrez wrote: > As an ex factory IT manager, I feel compelled to comment on that :) Multidisciplinary training rules! As an architect with field experience building roads, sidewalks, roofs, city planning (and training in lean manufacturing and services) I think I ca

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 17:44 +0100, Matthew Booth wrote: > These are tricky, case-by-case workarounds to a general problem which > can be solved by simply calling register_opts() in a place where it's > guaranteed to be safe. No, THE CODE IS WRONG. It is evaluating a configuration value at _modul

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: > > In any case, the operative point is that CONF. must > always be > > evaluated inside run-time code, never at module load time. > > ...unless you call register_opts() safely, which is what I'm > proposing. No, calling register_opts() at a

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Thu, 2014-08-07 at 17:41 +0100, Matthew Booth wrote: > ... or arg is an object which defines __nonzero__(), or defines > __getattr__() and then explodes because of the unexpected lookup of a > __nonzero__ attribute. Or it's False (no quotes when printed by the > debugger), but has a unicode type

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton wrote: > You said you had no idea what group based policy was buying us so I tried > to illustrate what the difference between declarative and imperative > network configuration looks like. That's the major selling point of GBP so > I'm not sure how th

Re: [openstack-dev] [Ironic] Exceptional approval request for Cisco Driver Blueprint

Hey, I agree with Dmitry that this spec has a huge scope. If you resubmitted one with only the power interface, that could be considered for an exception. A few specific reasons: 1) Auto-enrollment -- should probably be held off at the moment - This is something that was talked about extensive

[openstack-dev] [devstack] Core team proposals

I want to nominate Ian Wienand (IRC: ianw) to the DevStack core team. Ian has been a consistent contributor and reviewer for some time now. He also manages the Red Hat CI that runs tests on Fedora, RHEL and CentOS so those platforms have been a particular point of interest for him. Ian has also

Re: [openstack-dev] [all] The future of the integrated release

On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez wrote: > Hi everyone, > > With the incredible growth of OpenStack, our development community is > facing complex challenges. How we handle those might determine the > ultimate success or failure of OpenStack. > > With this cycle we hit new limits in

Re: [openstack-dev] [all] The future of the integrated release

> Multidisciplinary training rules! As an architect with field experience > building roads, sidewalks, roofs, city planning (and training in lean > manufacturing and services) I think I can have a say ;) > > > You're not really introducing a successful Kanban here, you're just > > clarifying tha

[openstack-dev] [sahara] Backports for 2014.1.2

Hey sahara folks, I'm going to push 2014.1.2 tag to stable/icehouse branch next week, so, please, propose backports before the weekend and ping us to backport some sensitive fixes. Thanks you! -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Softwar

[openstack-dev] [sahara] team meeting minutes Aug 7

Thanks everyone who have joined Sahara meeting. Here are the logs from the meeting: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-08-07-18.02.html http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-08-07-18.02.log.html -- Sincerely yours, Sergey Lukjanov Sahara Te

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 12:32 PM, Eoghan Glynn wrote: If we try to limit the number of WIP slots, then surely aspiring contributors will simply work around that restriction by preparing the code they're interested in on their own private branches, or in their github forks? OK, some pragmatic contributors

[openstack-dev] [oslo] oslo.concurrency repo review

Hello, oslo cores. I've finished polishing up oslo.concurrency repo at [0] - please take a look at it. I used my new version of graduate.sh [1] to generate it, so history looks a bit different from what you might be used to. I've made as little changes as possible, so there're still some steps le

Re: [openstack-dev] [nova][oslo] oslo.config and import chains

On Aug 7, 2014, at 12:39 PM, Kevin L. Mitchell wrote: > On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote: >> On 07/08/14 16:27, Kevin L. Mitchell wrote: >>> On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote: A (the?) solution is to register_opts() in foo before importing any >>>

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

>I mean't 'side stepping' why GBP allows for the comment you made previous, "With the latter, a mapping driver could determine that communication between these two hosts can be prevented by using an ACL on a router or a switch, which doesn't violate the user's intent and buys a performance improvem

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

It's just my own preference. Others like webex/hangouts because it can be easier to talk about topics than in IRC, but with this many people and the latency delays, it can become quite cumbersome. Plus, it makes it easier for meeting notes. I'll deal with it while the majority really prefer it.

Re: [openstack-dev] [all] The future of the integrated release

On Aug 6, 2014, at 5:10 PM, Michael Still wrote: > On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez wrote: > >> We seem to be unable to address some key issues in the software we >> produce, and part of it is due to strategic contributors (and core >> reviewers) being overwhelmed just trying to

Re: [openstack-dev] [devstack] Core team proposals

On 08/07/2014 02:09 PM, Dean Troyer wrote: > I want to nominate Ian Wienand (IRC: ianw) to the DevStack core team. > Ian has been a consistent contributor and reviewer for some time now. > He also manages the Red Hat CI that runs tests on Fedora, RHEL and > CentOS so those platforms have been a p

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wrote: > It's just my own preference. Others like webex/hangouts because it can > be easier to talk about topics than in IRC, but with this many people > and the latency delays, it can become quite cumbersome. Plus, it makes > it easier for meetin

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

Those are definitely other big reasons, and probably the reason it is planned to move to IRC in the future, no matter what. I was just wondering how soon, if soon at all. On Thu, 2014-08-07 at 12:35 -0700, Stefano Maffulli wrote: > On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wrote: > > It's

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Thu, Aug 7, 2014 at 10:58 PM, Yuriy Taraday wrote: > Hello, oslo cores. > > I've finished polishing up oslo.concurrency repo at [0] - please take a > look at it. I used my new version of graduate.sh [1] to generate it, so > history looks a bit different from what you might be used to. > > I've

Re: [openstack-dev] [Octavia] Weekly meetings resuming + agenda

Personally, I prefer IRC for general meeting stuff, with separate breakouts to voice for topics that warrant it. Doug On 8/7/14, 2:28 AM, "Stephen Balukoff" wrote: >Hi Brandon, > > >I don't think we've set a specific date to make the transition to IRC >meetings. Is there a particular urgency a

[openstack-dev] [Neutron][policy] Group Based Policy - Renaming

Hi, Following a very interesting and vocal thread on GBP for last couple of days and the GBP meeting today, GBP sub-team proposes following name changes to the resource. policy-point for endpoint policy-group for endpointgroup (epg) Please reply if you feel that it is not ok with reason and sugg

Re: [openstack-dev] [all] The future of the integrated release

> > If we try to limit the number of WIP slots, then surely aspiring > > contributors will simply work around that restriction by preparing > > the code they're interested in on their own private branches, or > > in their github forks? > > > > OK, some pragmatic contributors will adjust their prio

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

Can you include the definition/description of what each is here as well? I think there was a description in the 100+ thread of doom, but I don't want to go back there :) On Thu, Aug 7, 2014 at 3:17 PM, Ronak Shah wrote: > Hi, > Following a very interesting and vocal thread on GBP for last coup

  1   2   >