Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[Doug Wiegley]

Belated but enthusiastic +1

doug

> On Dec 15, 2016, at 4:58 PM, Armando M.  wrote:
> 
> Hi neutrinos,
> 
> I would like to propose Ryan and Nate as the go-to fellows for 
> service-related patches.
> 
> Both are core in their repos of focus, namely neutron-dynamic-routing and 
> neutron-fwaas, and have a good understanding of the service framework, the 
> agent framework and other bits and pieces. At this point, entrusting them 
> with the responsibility is almost a formality.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/411536/ 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Wiegley]

> On Nov 10, 2016, at 7:24 AM, Russell Bryant  wrote:
> 
> 
> 
> On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  > wrote:
> On Tue, 8 Nov 2016, Ash wrote:
> 
> I couldn't agree more. I don't like change for the sake of change (in any
> aspect of my life). So in my mind this would have to be a way to better
> bind us.
> 
> Here, have some tortured metaphors:
> 
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
> 
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
> 
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
> 
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
> 
> ​Agreed, Chris.  I think this topic has reflected quite poorly on OpenStack, 
> so far.

Also agreed. Like it or not, this topic is a proxy debate for whether it’s 
worth the risk to invest in OpenStack for new things. And doubling down on more 
process is not sending a great message.

Thanks,
doug

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

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

Re: [openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Doug Wiegley]

> On Oct 24, 2016, at 8:23 PM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> As part of a requirements mailing list thread [1], the idea of a servicevm 
> working group, or a common framework for reference openstack service VMs, 
> came up. It's too late to get onto the official schedule, but unofficially, 
> let's meet here:
> 
> When: Tuesday, 1:30pm-2:10pm
> Where: CCIB P1 Room 128
> 
> If this is too short notice, then we can retry on Friday.
> 
> Thanks,
> doug
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html
> 

And an etherpad:

https://etherpad.openstack.org/p/ocata-summit-servicevm 
<https://etherpad.openstack.org/p/ocata-summit-servicevm>


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

[openstack-dev] [trove][octavia][tacker][designate][manila][sahara][magnum][infra] servicevm working group meetup

[Doug Wiegley]

As part of a requirements mailing list thread [1], the idea of a servicevm 
working group, or a common framework for reference openstack service VMs, came 
up. It's too late to get onto the official schedule, but unofficially, let's 
meet here:

When: Tuesday, 1:30pm-2:10pm
Where: CCIB P1 Room 128

If this is too short notice, then we can retry on Friday.

Thanks,
doug

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105861.html



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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 12:42 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 12:21:20 -0600:
>> 
>>> On Oct 18, 2016, at 12:10 PM, Doug Hellmann <d...@doughellmann.com> wrote:
>>> 
>>> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>>>> 
>>>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <d...@doughellmann.com 
>>>>> <mailto:d...@doughellmann.com>> wrote:
>>>>> 
>>>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>>>>>> 
>>>>>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com 
>>>>>>> <mailto:sigmaviru...@gmail.com> <mailto:sigmaviru...@gmail.com 
>>>>>>> <mailto:sigmaviru...@gmail.com>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -Original Message-
>>>>>>> From: Thierry Carrez <thie...@openstack.org 
>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org 
>>>>>>> <mailto:thie...@openstack.org>> <mailto:thie...@openstack.org 
>>>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org 
>>>>>>> <mailto:thie...@openstack.org>>>>
>>>>>>> Reply: OpenStack Development Mailing List (not for usage questions) 
>>>>>>> <openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org>> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org>>>>
>>>>>>> Date: October 18, 2016 at 03:55:41
>>>>>>> To: openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org>> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org>>> 
>>>>>>> <openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org
>>>>>>>  <mailto:openstack-dev@lists.openstack.org>> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>>>> <mailto:openstack-dev@lists.openstack.org>>>>
>>>>>>> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>>>>>>> 
>>>>>>>> Doug Wiegley wrote:
>>>>>>>>> [...] Paths forward:
>>>>>>>>> 
>>>>>>>>> 1. Add gunicorn to global requirements.
>>>>>>>>> 
>>>>>>>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>>>>>>>> service VM packages (this is actually my preference.) It has been
>>>>>>>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>>>>>>>> modify the bot to include it in some way, or do it manually, or with a
>>>>>>>>> project specific job.
>>>>>>>>> 
>>>>>>>>> 3. Split our service VM builds into another repo, to keep a clean
>>>>>>>>> separation between API services and the backend. But, even this new
>>>>>>>>> repo’s standlone requirements.txt file will have the g-r issue from 
>>>>>>>>> #1.
>>>>>>>>> 
>>>>>>>>> 4. Boot the backend out of OpenStack entirely.
>>>>>>>> 

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 12:10 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 12:00:35 -0600:
>> 
>>> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <d...@doughellmann.com 
>>> <mailto:d...@doughellmann.com>> wrote:
>>> 
>>> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>>>> 
>>>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com 
>>>>> <mailto:sigmaviru...@gmail.com> <mailto:sigmaviru...@gmail.com 
>>>>> <mailto:sigmaviru...@gmail.com>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> -Original Message-
>>>>> From: Thierry Carrez <thie...@openstack.org 
>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org 
>>>>> <mailto:thie...@openstack.org>> <mailto:thie...@openstack.org 
>>>>> <mailto:thie...@openstack.org> <mailto:thie...@openstack.org 
>>>>> <mailto:thie...@openstack.org>>>>
>>>>> Reply: OpenStack Development Mailing List (not for usage questions) 
>>>>> <openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org>> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org>>>>
>>>>> Date: October 18, 2016 at 03:55:41
>>>>> To: openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org>> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org>>> 
>>>>> <openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org
>>>>>  <mailto:openstack-dev@lists.openstack.org>> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org> 
>>>>> <mailto:openstack-dev@lists.openstack.org 
>>>>> <mailto:openstack-dev@lists.openstack.org>>>>
>>>>> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>>>>> 
>>>>>> Doug Wiegley wrote:
>>>>>>> [...] Paths forward:
>>>>>>> 
>>>>>>> 1. Add gunicorn to global requirements.
>>>>>>> 
>>>>>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>>>>>> service VM packages (this is actually my preference.) It has been
>>>>>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>>>>>> modify the bot to include it in some way, or do it manually, or with a
>>>>>>> project specific job.
>>>>>>> 
>>>>>>> 3. Split our service VM builds into another repo, to keep a clean
>>>>>>> separation between API services and the backend. But, even this new
>>>>>>> repo’s standlone requirements.txt file will have the g-r issue from #1.
>>>>>>> 
>>>>>>> 4. Boot the backend out of OpenStack entirely.
>>>>>> 
>>>>>> All those options sound valid to me, so the requirements team should
>>>>>> pick what they are the most comfortable with.
>>>>>> 
>>>>>> My 2c: yes g-r is mostly about runtime dependencies and ensuring
>>>>>> co-installability. However it also includes test/build-time deps, and
>>>>>> generally converging dependencies overall sounds like a valid goal. Is
>>>>>> there any drawback in adding gunicorn to g-r (option 1) ?
>>>>> 
>>>>> The drawback (in my mind) is that new projects might start using it 
>>>>> giving operators yet another thing to learn abo

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 11:30 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> Excerpts from Doug Wiegley's message of 2016-10-18 09:59:54 -0600:
>> 
>>> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com 
>>> <mailto:sigmaviru...@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org> 
>>> <mailto:thie...@openstack.org <mailto:thie...@openstack.org>>>
>>> Reply: OpenStack Development Mailing List (not for usage questions) 
>>> <openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org> 
>>> <mailto:openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org>>>
>>> Date: October 18, 2016 at 03:55:41
>>> To: openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org> 
>>> <mailto:openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org>> 
>>> <openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org> 
>>> <mailto:openstack-dev@lists.openstack.org 
>>> <mailto:openstack-dev@lists.openstack.org>>>
>>> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
>>> 
>>>> Doug Wiegley wrote:
>>>>> [...] Paths forward:
>>>>> 
>>>>> 1. Add gunicorn to global requirements.
>>>>> 
>>>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>>>> service VM packages (this is actually my preference.) It has been
>>>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>>>> modify the bot to include it in some way, or do it manually, or with a
>>>>> project specific job.
>>>>> 
>>>>> 3. Split our service VM builds into another repo, to keep a clean
>>>>> separation between API services and the backend. But, even this new
>>>>> repo’s standlone requirements.txt file will have the g-r issue from #1.
>>>>> 
>>>>> 4. Boot the backend out of OpenStack entirely.
>>>> 
>>>> All those options sound valid to me, so the requirements team should
>>>> pick what they are the most comfortable with.
>>>> 
>>>> My 2c: yes g-r is mostly about runtime dependencies and ensuring
>>>> co-installability. However it also includes test/build-time deps, and
>>>> generally converging dependencies overall sounds like a valid goal. Is
>>>> there any drawback in adding gunicorn to g-r (option 1) ?
>>> 
>>> The drawback (in my mind) is that new projects might start using it giving 
>>> operators yet another thing to learn about when deploying a new component 
>>> (eventlet, gevent, gunicorn, ...).
>>> 
>>> On the flip, what's the benefit of adding it to g-r?
>> 
>> The positive benefit is the same as Octavia’s use case: it provides an 
>> alternative for any non-frontline-api service to run a lightweight http/wsgi 
>> service as needed (service VMs, health monitor agents, etc). And something 
>> better than the built-in debug servers in most of the frameworks.
>> 
>> On the proliferation point, it is certainly a risk, though I’ve personally 
>> heard pretty strong guidance that all main API services in our community 
>> should be trending towards pecan.
> 
> Pecan is a way to build WSGI applications. Gunicorn is a way to deploy
> them. So they're not mutually exclusive.

Right, agreed.

What we’re trying to convey here is:

- The normal way of making a REST endpoint in OpenStack is to use pecan (or 
flask or falcon), and let the deployer or packager worry about the runtime wsgi 
and/or reverse proxy.

- This isn't a “normal” OpenStack endpoint, because it’s a microservice inside 
a service VM, and thus has different needs, and is much less likely to be 
customized by a non-dev, to boot. And it needs to be “deploy ready” as a simple 
matter of it being a service VM black box. It’s part of the data plane, not the 
control plane.

Thanks,
doug

> 
> Doug
> 
>> 
>> Thanks,
>> doug
>> 
>>> 
>>> --  
>>> Ian Cordasco
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 10:41 AM, Thomas Goirand  wrote:
> 
> On 10/18/2016 02:44 AM, Morgan Fainberg wrote:
>> For the record uwsgi was not (at least at one point) allowed in g-r as
>> it was not a "runtime dependency" it was to be installed more like
>> apache mod_wsgi at the time. Gunicorn could fall into the same category,
>> it is meant to be used in conjunction with the runtime but not be a hard
>> requirement for the runtime itself.
> 
> Except that it can be used as a python module.
> 
> If it's only a "binary runner", then I don't think we even need to care,
> as we could replace it by apache or uwsgi, and it's an implementation
> detail that could even be left to package maintainers (I don't know the
> exact details of Octavia here though…).

This is for Octavia’s service VM image, not it’s mainline API service (which 
uses pecan and all the normal stuff.)

It’s true that packagers can create their own service VM images, and run 
whatever they like, but we must do something for the ref implementation that 
runs in the gate. And at present, we’ve chosen gunicorn, because the built-in 
server in flask is flaky in our CI tests.

doug


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


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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 10:39 AM, Matthew Thode  wrote:
> 
> On 10/18/2016 11:25 AM, Adam Harwell wrote:
>> We really don't want bindep IMO -- it's much safer to use the
>> non-packaged version from pypi for our purposes, since we may not be
>> running on a system that packages things like this. Again, our use case
>> may be strange though, as we're really using the python module and not
>> the binaries.
>> 
>> --Adam
> 
> Is there a reason you are not using pecan?

Seems a bit heavy for a microservice inside a service VM.

doug


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


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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

> On Oct 18, 2016, at 5:14 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
> 
>  
> 
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org <mailto:thie...@openstack.org>>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>>
> Date: October 18, 2016 at 03:55:41
> To: openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org> <openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org>>
> Subject:  Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r
> 
>> Doug Wiegley wrote:
>>> [...] Paths forward:
>>> 
>>> 1. Add gunicorn to global requirements.
>>> 
>>> 2. Create a project specific “amphora-requirements.txt” file for the
>>> service VM packages (this is actually my preference.) It has been
>>> pointed out that this wouldn’t be kept up-to-date by the bot. We could
>>> modify the bot to include it in some way, or do it manually, or with a
>>> project specific job.
>>> 
>>> 3. Split our service VM builds into another repo, to keep a clean
>>> separation between API services and the backend. But, even this new
>>> repo’s standlone requirements.txt file will have the g-r issue from #1.
>>> 
>>> 4. Boot the backend out of OpenStack entirely.
>> 
>> All those options sound valid to me, so the requirements team should
>> pick what they are the most comfortable with.
>> 
>> My 2c: yes g-r is mostly about runtime dependencies and ensuring
>> co-installability. However it also includes test/build-time deps, and
>> generally converging dependencies overall sounds like a valid goal. Is
>> there any drawback in adding gunicorn to g-r (option 1) ?
> 
> The drawback (in my mind) is that new projects might start using it giving 
> operators yet another thing to learn about when deploying a new component 
> (eventlet, gevent, gunicorn, ...).
> 
> On the flip, what's the benefit of adding it to g-r?

The positive benefit is the same as Octavia’s use case: it provides an 
alternative for any non-frontline-api service to run a lightweight http/wsgi 
service as needed (service VMs, health monitor agents, etc). And something 
better than the built-in debug servers in most of the frameworks.

On the proliferation point, it is certainly a risk, though I’ve personally 
heard pretty strong guidance that all main API services in our community should 
be trending towards pecan.

Thanks,
doug

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

On Oct 17, 2016, at 6:44 PM, Morgan Fainberg  wrote:
> 
> 
> On Oct 17, 2016 17:32, "Thomas Goirand"  > wrote:
> >
> > On 10/17/2016 08:43 PM, Adam Harwell wrote:
> > > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> > > aware is to maintain interoperability between project dependencies for
> > > openstack deploys, and since our amphora image is totally separate, it
> > > should not be restricted to g-r requirements.
> >
> > The fact that we have a unified version number of a given lib in all of
> > OpenStack is also because that's a requirement of downstream distros.
> >
> > Imagine that someone would like to build the Octavia image using
> > exclusively packages from ...
> >
Right, so, we’re dancing around the common problem in openstack lately: what 
the heck is openstack?

This came up because service VMs/data plane implementations, which this is, 
have different requirements than API services. Paths forward:

1. Add gunicorn to global requirements.

2. Create a project specific “amphora-requirements.txt” file for the service VM 
packages (this is actually my preference.) It has been pointed out that this 
wouldn’t be kept up-to-date by the bot. We could modify the bot to include it 
in some way, or do it manually, or with a project specific job.

3. Split our service VM builds into another repo, to keep a clean separation 
between API services and the backend.  But, even this new repo’s standlone 
requirements.txt file will have the g-r issue from #1.

4. Boot the backend out of OpenStack entirely.

Thanks,
doug


> > > I brought this up, but
> > > others thought it would be prudent to go the g-r route anyway.
> >
> > It is, and IMO you should go this route.
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> For the record uwsgi was not (at least at one point) allowed in g-r as it was 
> not a "runtime dependency" it was to be installed more like apache mod_wsgi 
> at the time. Gunicorn could fall into the same category, it is meant to be 
> used in conjunction with the runtime but not be a hard requirement for the 
> runtime itself. 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

On Oct 17, 2016, at 12:02 PM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
> 
> On Mon, Oct 17, 2016 at 1:33 PM, Doug Wiegley
> <doug...@parksidesoftware.com> wrote:
>> Hi,
>> 
>> On a review to add gunicorn to global requirements[1], we were asked to send 
>> a notice to the ML. In this particular application, it’s for use inside a 
>> service VM for Octavia. Objections/comments/other?
> 
> global-requirements is meant to ensure co-installability between
> OpenStack services.
> Is it safe to assume that software running in service VMs does not need to be
> co-installable with other OpenStack services, since it's separated
> from the control
> plane?
> 

In this particular case, yes, that’s not a concern, but if added to g-r, it 
might proliferate elsewhere over time.

Thanks,
doug

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


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

[openstack-dev] [requirements][lbaas] gunicorn to g-r

[Doug Wiegley]

Hi,

On a review to add gunicorn to global requirements[1], we were asked to send a 
notice to the ML. In this particular application, it’s for use inside a service 
VM for Octavia. Objections/comments/other?

Thanks,
doug


[1] https://review.openstack.org/#/c/386790/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra] Third Party CI Question

[Doug Wiegley]

You can also selectively not use zuul. For those jobs pointed at other source 
control, use standard Jenkins triggers, and all the rest of the tooling remains 
the same (including jjb for those new triggers.)

Doug

> On Oct 16, 2016, at 9:09 AM, Monty Taylor  wrote:
> 
>> On 10/14/2016 01:50 PM, Pradeep Patra wrote:
>> Hi all,
>> 
>> I was referring the CI system in OpenStack [1]. I was reading this
>> approach and its pretty good. One limitation I could find is the CI
>> mechanism is tightly coupled with git/geritt.
>> 
>> [snippet from [1]]
>> Zuul  is a tool
>> that determines what jobs are run when. Zuul listens to the Gerrit event
>> stream, and first tries to match each event to one or more pipelines.
>> 
>> Is there a way to make Zuul listen to Code Collaborator or other Code
>> review tools events and the source control system is SVN not git?
> 
> Hi Pradeep!
> 
> Yes and no.
> 
> Zuul is _heavily_ based around git. We have made a conscious decision to
> have that not be extensible so that we can make the best use of git
> under the hood. It's central to the way zuul prepares speculative future
> states to present to the testing system.
> 
> On the other hand, zuul has a system of extensible Triggers and
> Reporters. Jobs can currently be triggered by both Gerrit and by
> cron-like timers. There is a set of patches proposed to add support for
> listening to github pull requests, although we're deferring landing them
> until we're a little further along with zuul v3. We have a desire for a
> "trigger from url" feature too - where zuul can watch for changes in a
> URL and trigger a job based on it.
> 
> So it should be totally possible to write a Trigger and Reporter module
> to interface with Code Collaborator. I do not believe having such
> modules natively understand SVN will be possible.
> 
> Monty
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Doug Wiegley]

+1

Doug

> On Oct 14, 2016, at 6:24 PM, Kevin Benton  wrote:
> 
> +1
> 
> 
>> On Oct 14, 2016 1:33 PM, "Miguel Lavalle"  wrote:
>> Dear Neutrinos,
>> 
>> I am organizing a social event for the team on Thursday 27th at 19:30. After 
>> doing some Google research, I am proposing Raco de la Vila, which is located 
>> in Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
>> http://www.racodelavila.com/en/carta-racodelavila.htm
>> 
>> It is easy to get there by subway from the Summit venue: 
>> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
>> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get 
>> a final count.
>> 
>> Here's some reviews: 
>> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
>> 
>> Cheers
>> 
>> Miguel
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

[Doug Wiegley]

+1

> On Oct 10, 2016, at 3:40 PM, Brandon Logan  
> wrote:
> 
> +1
> 
> On Mon, 2016-10-10 at 13:06 -0700, Michael Johnson wrote:
>> Greetings Octavia and developer mailing list folks,
>> 
>> I propose that we add Lubosz Kosnik (diltram) as an OpenStack Octavia
>> core reviewer.
>> 
>> His contributions [1] are in line with other cores and he has been an
>> active member of our community.  He regularly attends our weekly
>> meetings, contributes good code, and provides solid reviews.
>> 
>> Overall I think Lubosz would make a great addition to the core review
>> team.
>> 
>> Current Octavia cores, please respond with +1/-1.
>> 
>> Michael
>> 
>> [1] http://stackalytics.com/report/contribution/octavia/90
>> 
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [kosmos] meetings canceled until post summit

[Doug Wiegley]

We will pick back up on 11/1. 

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

Re: [openstack-dev] TC candidacy

[Doug Wiegley]

> On Sep 28, 2016, at 1:59 PM, Chris Dent  wrote:
> 
> On Wed, 28 Sep 2016, Jim Rollenhagen wrote:
> 
 +1 to release notes or something of that like. i was asked to give an
 update on the TC internally and it seems the only information out there
 is to read through backlog of meeting logs or track the items that do
 get raised to ML. even then, it's hard to define what deliverables were
 achieved in the cycle.
 
>>> 
>>> FWIW, the resolutions that passed are listed here:
>>> https://governance.openstack.org/
>> 
>> And the git tree, with a changelog, is here:
>> http://git.openstack.org/cgit/openstack/governance/
> 
> I assume, but I'd prefer if he confirm, that the point gordc was
> trying to make was that there's more to what the TC gets up to than
> merging changes to governance. That's certainly a major aspect and
> one can track those changes by tracking both of those resources.
> 
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of

The minutes and logs exist.

http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html 


http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.log.html 


http://eavesdrop.openstack.org/meetings/tc/2016/ 




> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.
> 
> [1] Note that I don't actually think that release notes is the proper
> form for some extra communication from the TC. Rather the justifications
> that lead some projects to add release notes, in addition to the git
> log, are something to consider for TC activity.
> 
> -- 
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: 
> @anticdent__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Doug Wiegley]

> On Sep 8, 2016, at 12:49 PM, Matt Riedemann  
> wrote:
> 
> On 9/8/2016 6:42 AM, Sean Dague wrote:
>> On 09/08/2016 05:00 AM, Thierry Carrez wrote:
>>> Sean Dague wrote:
>> 
>>> So... the difference between your proposal and mine is: you force the
>>> PTL to be the release steward (rather than having a choice there), and
>>> introduce a delay between election and start of authority for the PTL.
>>> 
>>> I don't see that delay as a good thing. You would elect in April a PTL
>>> whose authority over the project would start in August. That sounds a
>>> bit weird to me. I'd rather say that the authority of the PTL starts
>>> when he is elected, and not introduce a delay.
>>> 
>>> I don't see *forcing* the PTL to be the release steward to be a good
>>> thing either. The just-elected PTL can totally be the release steward
>>> for the upcoming cycle -- actually, that is how my proposal would work
>>> by default: the PTL elected around Boston would be the default release
>>> steward for Q, and the PTL elected around Sydney would be the default
>>> release steward for R. But I'd rather allow for some flexibility here,
>>> in case the PTL prefers to delegate more of his work. I also think
>>> allowing for more leadership roles (rather than piling it all on the
>>> PTL) helps growing a stronger leadership pipeline.
>>> 
>>> In summary, I see drawbacks to your variant, and I fail to see any
>>> benefits... Am I missing something ?
>> 
>> I can only bring my own experience from projects, which is to expose
>> projects to succession planning a bit earlier, but otherwise keep things
>> the same. Both with working in the QA team, and in Nova, usually the
>> standing PTL starts telling folks about half way through their final
>> term that they aren't going to run again. And there ends up being a
>> bunch of private team conversations to figure out who else is
>> interested. Often those folks need to clear some things off their plate.
>> So there is some completely private indication of who might be the next
>> PTL. However, nothing is made official, and no one wants to presume
>> until an actual election happens months later.
>> 
>> When succession planning doesn't go well, you get to nomination week,
>> and you find out the current PTL isn't running, and there are two days
>> of mad scramble trying to figure out who is going to run.
>> 
>> Forcing the PTL-next conversation back some amount of time means it
>> matches the way I've seen succession planning work in projects for the
>> best handoff.
>> 
>> I feel like projects and PTLs do already delegate the things they can
>> and want to. It's not clear to me that creating another title of release
>> steward is going to dramatically change that. Maybe it's an active
>> suggestion to delegate that role out? Or that another title helps
>> convince employers that someone needs to end up at the PTG?
>> 
>> I'm also not very concerned about delayed authority of the PTL. Peaceful
>> handoff should be a pretty basic tenant in projects. Knowing about it
>> for a longer time shouldn't be a big deal. If it causes giant strife to
>> pass the torch from one PTL to the next there is something else going
>> wrong in that project. In the few cases I'm familiar with in which a
>> standing PTL lost an election, the relationship between that PTL and the
>> PTL-next was fine.
>> 
>> Again, these are personal experiences from the projects I'm actively
>> involved with, or collaborate with the most.
>> 
>>  -Sean
>> 
> 
> +1 to everything sdague said here.

Another +1 to sdague’s sentiments.

If a PTL wants to setup this kind of heirarchy, they are already free to do so. 
 (And in your proposal, if they want to not do it, they are free not to, so why 
codify it?)

Thanks,
doug

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


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

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

[Doug Wiegley]

> On Mar 23, 2016, at 4:17 PM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> Migration script has been submitted, v1 is not going anywhere from 
> stable/liberty or stable/mitaka, so it’s about to disappear from master.
> 
> I’m thinking in this order:
> 
> - remove jenkins jobs
> - wait for heat to remove their jenkins jobs ([heat] added to this thread, so 
> they see this coming before the job breaks)
> - remove q-lbaas from devstack, and any references to lbaas v1 in 
> devstack-gate or infra defaults.
> - remove v1 code from neutron-lbaas

FYI, all of the above have completed, and the final removal is in the merge 
queue: https://review.openstack.org/#/c/286381/

Mitaka will be the last stable branch with lbaas v1.

Thanks,
doug

> 
> Since newton is now open for commits, this process is going to get started.
> 
> Thanks,
> doug
> 
> 
> 
>> On Mar 8, 2016, at 11:36 AM, Eichberger, German <german.eichber...@hpe.com> 
>> wrote:
>> 
>> Yes, it’s Database only — though we changed the agent driver in the DB from 
>> V1 to V2 — so if you bring up a V2 with that database it should reschedule 
>> all your load balancers on the V2 agent driver.
>> 
>> German
>> 
>> 
>> 
>> 
>> On 3/8/16, 3:13 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>> 
>>> So this looks like only a database migration, right?
>>> 
>>> -Original Message-
>>> From: Eichberger, German [mailto:german.eichber...@hpe.com] 
>>> Sent: Tuesday, March 08, 2016 12:28 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
>>> weready?
>>> 
>>> Ok, for what it’s worth we have contributed our migration script: 
>>> https://review.openstack.org/#/c/289595/ — please look at this as a 
>>> starting point and feel free to fix potential problems…
>>> 
>>> Thanks,
>>> German
>>> 
>>> 
>>> 
>>> 
>>> On 3/7/16, 11:00 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>>> 
>>>> As far as I recall, you can specify the VIP in creating the LB so you will 
>>>> end up with same IPs.
>>>> 
>>>> -Original Message-
>>>> From: Eichberger, German [mailto:german.eichber...@hpe.com]
>>>> Sent: Monday, March 07, 2016 8:30 PM
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
>>>> weready?
>>>> 
>>>> Hi Sam,
>>>> 
>>>> So if you have some 3rd party hardware you only need to change the 
>>>> database (your steps 1-5) since the 3rd party hardware will just keep 
>>>> load balancing…
>>>> 
>>>> Now for Kevin’s case with the namespace driver:
>>>> You would need a 6th step to reschedule the loadbalancers with the V2 
>>>> namespace driver — which can be done.
>>>> 
>>>> If we want to migrate to Octavia or (from one LB provider to another) it 
>>>> might be better to use the following steps:
>>>> 
>>>> 1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
>>>> Monitors , Members) into some JSON format file(s) 2. Delete LBaaS v1 3. 
>>>> Uninstall LBaaS v1 4. Install LBaaS v2 5. Transform the JSON format 
>>>> file into some scripts which recreate the load balancers with your 
>>>> provider of choice —
>>>> 
>>>> 6. Run those scripts
>>>> 
>>>> The problem I see is that we will probably end up with different VIPs 
>>>> so the end user would need to change their IPs…
>>>> 
>>>> Thanks,
>>>> German
>>>> 
>>>> 
>>>> 
>>>> On 3/6/16, 5:35 AM, "Samuel Bercovici" <samu...@radware.com> wrote:
>>>> 
>>>>> As for a migration tool.
>>>>> Due to model changes and deployment changes between LBaaS v1 and LBaaS 
>>>>> v2, I am in favor for the following process:
>>>>> 
>>>>> 1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, 
>>>>> Health Monitors , Members) into some JSON format file(s) 2. Delete LBaaS 
>>>>> v1 3.
>>>>> Uninstall LBaaS v1 4. Install LBaaS v2 5. Import the data from 1 back 
>>>>> over LBaaS v2 (need to allow moving

Re: [openstack-dev] [neutron][lbaas] gate iffy, hold your rechecks

[Doug Wiegley]

The ip collisions with the devstack fixed range are no longer an issue, so 
rechecks and approvals can resume.

Thanks,
doug

> On Aug 19, 2016, at 12:08 PM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> And cores, please hold your +A’s until the patch below has merged.
> 
> Thanks,
> doug
> 
>> On Aug 19, 2016, at 12:03 PM, Doug Wiegley <doug...@parksidesoftware.com> 
>> wrote:
>> 
>> Hi all,
>> 
>> The CI system is having some issues with osic nodes running dsvm jobs right 
>> now, and the odds of getting one are pretty high with neutron or lbaas, 
>> because of how many dsvm jobs we run on each change. Please hold your 
>> rechecks until the following patch merges:
>> 
>> https://review.openstack.org/#/c/357764/
>> 
>> Thanks,
>> doug
>> 
>> 
> 


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

Re: [openstack-dev] [neutron][lbaas] gate iffy, hold your rechecks

[Doug Wiegley]

And cores, please hold your +A’s until the patch below has merged.

Thanks,
doug

> On Aug 19, 2016, at 12:03 PM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> Hi all,
> 
> The CI system is having some issues with osic nodes running dsvm jobs right 
> now, and the odds of getting one are pretty high with neutron or lbaas, 
> because of how many dsvm jobs we run on each change. Please hold your 
> rechecks until the following patch merges:
> 
> https://review.openstack.org/#/c/357764/
> 
> Thanks,
> doug
> 
> 


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

[openstack-dev] [neutron][lbaas] gate iffy, hold your rechecks

[Doug Wiegley]

Hi all,

The CI system is having some issues with osic nodes running dsvm jobs right 
now, and the odds of getting one are pretty high with neutron or lbaas, because 
of how many dsvm jobs we run on each change. Please hold your rechecks until 
the following patch merges:

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

Thanks,
doug



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

Re: [openstack-dev] [infra][neutron] - best way to load 8021q kernel module into cirros

[Doug Wiegley]

I would be tempted to make a custom image, and ask to put it on our mirrors, or 
have nodepool manage the image building and storing.

You can also likely just have the module on the local mirrors, which would 
alleviate the random internet issue. 

Bigger OS'es with nested Virt is kinda pain. 

Doug


> On Aug 5, 2016, at 3:37 PM, Kevin Benton  wrote:
> 
> Hi,
> 
> In neutron there is a new feature under active development to allow a VM to 
> attach to many networks via its single interface using VLAN tags.
> 
> We would like this to be tested in a scenario test in the gate, but in order 
> to do that the guest instance must have support for VLAN tags (the 8021q 
> kernel module for Linux VMs). Cirros does not ship with this module so I have 
> a few questions.
> 
> Do any other projects need to load a kernel module for a specific test? If 
> not, where would the best place be to store the module so we can load it for 
> that test; or, should we download it directly from the Internet (worried 
> about the stability of this)?
> 
> Thanks, 
> Kevin Benton
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

[Doug Wiegley]

+1

> On Jul 21, 2016, at 5:13 PM, Kevin Benton  wrote:
> 
> +1
> 
> On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin  > wrote:
> +1 from me
> 
> On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller  > wrote:
> As Neutron's so called testing lieutenant I would like to propose
> Jakub Libosvar to be a core in the testing area.
> 
> Jakub has demonstrated his inherent interest in the testing area over
> the last few years, his reviews are consistently insightful and his
> numbers [1] are in line with others and I know will improve if given
> the responsibilities of a core reviewer. Jakub is deeply involved with
> the project's testing infrastructures and CI systems.
> 
> As a reminder the expectation from cores is found here [2], and
> specifically for cores interesting in helping out shaping Neutron's
> testing story:
> 
> * Guide community members to craft a testing strategy for features [3]
> * Ensure Neutron's testing infrastructures are sufficiently
> sophisticated to achieve the above.
> * Provide leadership when determining testing Do's & Don'ts [4]. What
> makes for an effective test?
> * Ensure the gate stays consistently green
> 
> And more tactically we're looking at finishing the Tempest/Neutron
> tests dedup [5] and to provide visual graphing for historical control
> and data plane performance results similar to [6].
> 
> [1] http://stackalytics.com/report/contribution/neutron/90 
> 
> [2] http://docs.openstack.org/developer/neutron/policies/neutron-teams.html 
> 
> [3] 
> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
>  
> 
> [4] https://assafmuller.com/2015/05/17/testing-lightning-talk/ 
> 
> [5] https://etherpad.openstack.org/p/neutron-tempest-defork 
> 
> [6] https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tc][all] Plugins for all

[Doug Wiegley]

> On Jul 19, 2016, at 9:36 AM, Doug Hellmann  wrote:
> 
> Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +:
>> On 18/07/2016 17:57, Thierry Carrez wrote:
>>> Hayes, Graham wrote:
 [...]
 The point is that we were supposed to be a level field as a community
 but if we have examples like this, there is not a level playing field.
>>> 
>>> While I generally agree on your goals here (avoid special-casing some
>>> projects in generic support projects like Tempest), I want to clarify
>>> what we meant by "level playing field" in a recent resolution.
>> 
>> 
>> Yes - it has been pointed out the title is probably overloading a term
>> just used for a different purpose - I am more than willing to change it.
>> 
>> I wasn't sure where I got the name, and I realised that was probably in
>> my head from that resolution.
>> 
>>> This was meant as a level playing field for contributors within a
>>> project, not a level playing field between projects. The idea is that
>>> any contributor joining any OpenStack project should not be technically
>>> limited compared to other contributors on the same project. So, no
>>> "secret sauce" that only a subset of developers on a project have access to.
>> 
>> There is a correlation here - "special sauce" (not secret obviously)
>> that only a subset of projects have access to.
>> 
>>> I think I understand where you're gong when you say that all projects
>>> should have equal chances, but keep in mind that (1) projects should not
>>> really "compete" against each other (but rather all projects should
>>> contribute to the success of OpenStack as a whole) and (2) some
>>> OpenStack projects will always be more equal than others (for example we
>>> require that every project integrates with Keystone, and I don't see
>>> that changing).
>> 
>> Yes, I agree we should not be competing. But was should not be asking
>> the smaller projects to re-implement functionality, just because they
>> did not get integrated in time.
>> 
>> We require all projects to integrate with keystone for auth, as we
>> require all projects to integrate with neutron for network operations
>> and designate for DNS, I just see it as a requirement for using the
>> other components of OpenStack for their defined purpose.
>> 
> 
> It would be useful to have some specific information from the QA/Tempest
> team (and any others with a similar situation) about whether the current
> situation about how differences between in-tree tests and plugin tests
> are allowed to use various APIs. For example, are there APIs only
> available to in-tree tests that are going to stay that way? Or is this
> just a matter of not having had time to "harden" or "certify" or
> otherwise prepare those APIs for plugins to use them?

Doug, one example that I’m aware of — I’ve suggested moving neutron entirely 
out of devstack and into the neutron repo, via the devstack plugin interface. 
This was rejected, and the counter-argument given was that the folks that 
maintain the integrated gate, which happen to be many of the same folks 
maintaining devstack and the like, want to retain control of the items that can 
break the integrated gate, and that it gets too hard to track down individual 
project folks when the world is burning.

I don’t personally agree with the decision, but I can see some merit in that 
argument.

Thanks,
doug


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


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

[openstack-dev] [kosmos] new meeting time?

[Doug Wiegley]

Hi all,

The Kosmos team has shuffled a lot, and we have some prospective new members. 
The current meeting time of 1600 UTC may not be optimal anymore. If you’re 
interested in attending, can you post what times work for you?

I’m in the U.S. mountain time zone, so 1500 - 2300 UTC are optimal (plus or 
minus an hour.)

Others?

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

Re: [openstack-dev] [octavia][upgrades] upgrade loadbalancer to new amphora image

[Doug Wiegley]

> On Jun 30, 2016, at 7:15 AM, Ihar Hrachyshka  wrote:
> 
>> 
>> On 30 Jun 2016, at 01:16, Brandon Logan  wrote:
>> 
>> Hi Ihar, thanks for starting this discussion.  Comments in-line.
>> 
>> After writing my comments in line, I might now realize that you're just
>> talking about documenting  a way for a user to do this, and not have
>> Octavia handle it at all.  If that's the case I apologize for my reading
>> comprehension, but I'll keep my comments in case I'm wrong.  My brain is
>> not working well today, sorry :(
> 
> Right. All the mechanisms needed to apply the approach are already in place 
> in both Octavia and Neutron as of Mitaka. The question is mostly about 
> whether the team behind the project may endorse the alternative approach in 
> addition to whatever is in the implementation in regards to failovers by 
> giving space to describe it in the official docs. I don’t suggest that the 
> approach is the sole documented, or that octavia team need to implement 
> anything. [That said, it may be wise to look at providing some smart scripts 
> on top of neutron/octavia API that would realize the approach without putting 
> the burden of multiple API calls onto users.]

I don’t have a problem documenting it, but I also wouldn’t personally want to 
recommend it.

We’re adding a layer of NAT, which has performance and HA implications of its 
own.

We’re adding FIPs, when the neutron advice for “simple nova-net like 
deployment” is provider nets and linuxbridge, which don’t support them.

Thanks,
doug


> 
>> 
>> Thanks,
>> Brandon
>> 
>> On Wed, 2016-06-29 at 18:14 +0200, Ihar Hrachyshka wrote:
>>> Hi all,
>>> 
>>> I was looking lately at upgrades for octavia images. This includes using 
>>> new images for new loadbalancers, as well as for existing balancers.
>>> 
>>> For the first problem, the amp_image_tag option that I added in Mitaka 
>>> seems to do the job: all new balancers are created with the latest image 
>>> that is tagged properly.
>>> 
>>> As for balancers that already exist, the only way to get them use a new 
>>> image is to trigger an instance failure, that should rebuild failed nova 
>>> instance, using the new image. AFAIU the failover process is not currently 
>>> automated, requiring from the user to set the corresponding port to DOWN 
>>> and waiting for failover to be detected. I’ve heard there are plans to 
>>> introduce a specific command to trigger a quick-failover, that would 
>>> streamline the process and reduce the time needed for the process because 
>>> the failover would be immediately detected and processed instead of waiting 
>>> for keepalived failure mode to occur. Is it on the horizon? Patches to 
>>> review?
>> 
>> Not that I know of and with all the work slated for Newton, I'm 99% sure
>> it won't be done in Newton.  Perhaps Ocata.
> 
> I see. Do we maybe want to provide a smart script that would help to trigger 
> a failover with neutron API? [detect the port id, set it to DOWN, …]
> 
>>> 
>>> While the approach seems rather promising and may be applicable for some 
>>> environments, I have several concerns about the failover approach that we 
>>> may want to address.
>>> 
>>> 1. HA assumption. The approach assumes there is another node running 
>>> available to serve requests while instance is rebuilding. For non-HA 
>>> amphoras, it’s not the case, meaning the image upgrade process has a 
>>> significant downtime.
>>> 
>>> 2. Even if we have HA, for the time of instance rebuilding, the balancer 
>>> cluster is degraded to a single node.
>>> 
>>> 3. (minor) during the upgrade phase, instances that belong to the same HA 
>>> amphora may run different versions of the image.
>>> 
>>> What’s the alternative?
>>> 
>>> One idea I was running with for some time is moving the upgrade complexity 
>>> one level up. Instead of making Octavia aware of upgrade intricacies, allow 
>>> it to do its job (load balance), while use neutron floating IP resource to 
>>> flip a switch from an old image to a new one. Let me elaborate.
>> I'm not sure I like the idea of tying this to floating IP as there are
>> deployers who do not use floating IPs.  Then again, we are currently
>> depending on allowed address pairs which is also an extension, but I
>> suspect its probably deployed in more places.  I have no proof of this
>> though.
> 
> I guess you already deduced that, but just for the sake of completeness: no, 
> I don’t suggest that octavia ties its backend to FIPs. I merely suggest to 
> document the proposed approach as ‘yet another way of doing it’, at least 
> until we tackle the first two concerns raised.
> 
>>> 
>>> Let’s say we have a load balancer LB1 that is running Image1. In this 
>>> scenario, we assume that access to LB1 VIP is proxied through a floating ip 
>>> FIP that points to LB1 VIP. Now, the operator uploaded a new Image2 to 
>>> glance registry and tagged it for octavia usage. The user now wants to 
>>> 

Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Doug Wiegley]

> On Jun 30, 2016, at 7:01 AM, Ihar Hrachyshka  wrote:
> 
> 
>> On 30 Jun 2016, at 06:03, Kosnik, Lubosz  wrote:
>> 
>> Like Doug said Amphora suppose to be a black box. It suppose to get some 
>> data - like info in /etc/defaults and do everything inside on its own.
>> Everyone will be able to prepare his own implementation of this image 
>> without mixing things between each other.
> 
> That would be correct if the image would not be maintained by the project 
> itself. Then indeed every vendor would prepare their own image, maybe 
> collaborate on common code for that. Since this code is currently in octavia, 
> we kinda need to plug into it for other vendors. Otherwise you pick one and 
> give it a preference.

No, I disagree with that premise, because it pre-supposes that we have any 
interest in supporting *this exact reference implementation* for any period of 
time.

Octavia has a few goals:

- Present an openstack loadbalancing API to operators and users.
- Put VIPs on openstack clouds, that do loadbalancy things, and are always 
there and working.
- Upgrade seamlessly.

That’s it. A few more constraints:

- It’s an openstack project, so it must be python, with our supported version, 
running on our supported OSs, using our shared libraries, being open, level 
playing field, etc…

Nowhere in there is the amp concept, or that we must always require nova, or 
that said amps must run a REST agent, or anything about the load-balancing 
backend.The amp itself, and all the code written for it, is just a means to an 
end. If the day comes tomorrow that the amp agent and amp concept is silly, as 
long as we have a seamless upgrade and those VIPs keep operating, we are under 
no obligation as a project to keep using that amp code or maintaining it. Our 
obligation is to the operators and users.

The amp “agent” code has already gone through two iterations (direct ssh, now a 
silly rest agent on the amp). We’ve already discussed that the current ubuntu 
based amp is too heavy-weight and needs to change. Tomorrow it could be based 
on a microlinux. And the day after that, cirros plus a static nginx. And the 
day after that, a docker swarm with an proxy running on a simulated minecraft 
redstone machine (well, we’d have to find an open-source clone of minecraft, 
first.)

The point being, as a project contributor, I have zero interest in signing up 
for long-term maintenance of something that 1) is not user visible, and 2) is 
likely to change; all for the sake of any particular vendors sensibilities. The 
current octavia will run just fine on ubuntu or redhat, and the current amp 
image will launch just fine on a nova run by either, too.

That said, every part of octavia is pluggable with drivers, and while I will 
personally resist adding multiple reference drivers in-tree, it doesn’t mean 
everyone will, nor does it preclude using shims and external repos.

That’s just my opinion, but I’d hate to see us tying our own hands by adding 
support and maintenance burden at this early stage, beyond delivering VIPs to 
users. I’d be more inclined to see the amp image itself cease to exist inside 
an openstack project, before I want to spend the time supporting lots of them, 
for non-technical reasons.

Thanks,
doug



> 
> But if we can make the agent itself vendor agnostic, so that the only 
> differentiation would happen around components stuffed into the image 
> (kernel, haproxy version, security tweaks, …), then it will be obviously a 
> better path than trying to template the agent for multiple vendors.

> 
> A silly question: why does the agent even need to configure the network using 
> distribution mechanisms and not just calling to ip link and friends?
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Doug Wiegley]

> On Jun 29, 2016, at 10:25 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> 
> 
>> On 29 Jun 2016, at 18:10, Doug Wiegley <doug...@parksidesoftware.com> wrote:
>> 
>> Interesting discussion, but the first question I’d ask is ‘why’ ?
>> 
>> Unlike openstack server software, the amphora are meant to be black box 
>> appliance images, so why do we want to run different distros on them? Is 
>> there a deployment scenario you’re concerned with, or other use case?
> 
> Because vendors want to keep control for the contents of the image. For one, 
> Company X may not be particularly happy about shipping and supporting Ubuntu 
> based images through its channels. And without it, there is no end-to-end 
> support story for load balancers that the company could sell to its 
> customers. The company may also want to specialize the image contents in some 
> way, f.e. inject additional vendor specific security mechanisms, or ship a 
> new better version of haproxy. 
> 
> I believe it’s self evident, but for completeness: Company X engineers would 
> not support Ubuntu bits because 1. they don’t have expertise in Ubuntu. 2. it 
> would give a really twisted message to customers.

Fair enough, and that’s the reply that I was expecting. So either we make the 
amphora driver distro aware, or multiple amphora drivers/images. I presume that 
“company x” is willing to devote resources to this?

Thanks,
doug

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


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

Re: [openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Doug Wiegley]

Interesting discussion, but the first question I’d ask is ‘why’ ?

Unlike openstack server software, the amphora are meant to be black box 
appliance images, so why do we want to run different distros on them? Is there 
a deployment scenario you’re concerned with, or other use case?

Thanks,
doug


> On Jun 29, 2016, at 9:26 AM, Nir Magnezi  wrote:
> 
> Hello,
> 
> Lately, I've been working on a fix[1] for the amhpora-agent, which currently 
> only support Debian based flavors such as Ubuntu.
> 
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX 
> files which are accepted in Linux flavors such a RHEL, CentOS and Fedora, 
> read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
> 
> I would like to have a discussion about the second bullet mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an instance 
> (Amphora), There are few actions that need to take place in the Amphora 
> instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
> 
> The Amphora-agent leverages[2] the capabilities of 'upstart' to make that 
> happen, which is a bit problematic if we wish it to work on other flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few more 
> options[3] such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors 
> use 'systemd'.
> This creates incompatibility with the jinja2[4][5] templates used by the 
> agent.
> 
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix[1] that will essentially duplicate 
> the functionality mentioned above and work in the other flavors.
> 2. Have a the amphora agent be the only binary that needs to be configured to 
> start upon boot, and that agent will take care of plugging namespaces and 
> NICs and also spawning needs processes. This is how it is done in lbaas and 
> l3 agents.
> 
> While the latter solution looks like a more "clean" design, the trade-off 
> here is a bigger change to the amphora agent. 
> 
> [1] https://review.openstack.org/#/c/331841/ 
> 
> [2] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
>  
> 
> [3] 
> https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
>  
> 
> [4] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
>  
> 
> [5] 
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>  
> 
> 
> 
> Thanks,
> Nir
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [lbaas]HA for lbaas v2 agent

[Doug Wiegley]

As Assaf mentioned, namespace and octavia are two different lbaas drivers.  But 
within those:

- The lbaas plugin will schedule lbaas VIPs from all available lbaas-agents (I 
think it’s random.)  No, you can’t move them later, or override the scheduler.

- The lbaas agent is used by the octavia driver. Octavia is its own REST 
endpoint, and the lbaas driver for it just makes synchronous REST calls.

Thanks,
doug


> On Jun 23, 2016, at 3:33 PM, Assaf Muller  wrote:
> 
> On Thu, Jun 23, 2016 at 3:43 PM, Akshay Kumar Sanghai
>  wrote:
>> Thanks Assaf.
>> I have few questions for lbaas:
>> -  if i run agents on multiple nodes, will the request be ditrsibuted by
>> neutron-server?
>> - Does neutron lbaas agent forward the request to octavia-api or the
>> neutron-server?
> 
> The LBaaS v2 API has multiple implementations. One of which is based
> off haproxy and namespaces, known as the agent based implementation.
> Do you have neutron-lbaas-agent running on your network nodes? The
> second implementation is called Octavia and is based off service VMs
> instead of agents and namespaces. Octavia calls out to Nova to create
> VMs and inside those VMs is an agent that talks back to Octavia, and
> that creates an haproxy instance to perform the actual loadbalancing.
> The answer to both of your questions depends on which of these two
> implementations you're going with. There's a bunch of summit sessions
> about Octavia you can look in to.
> 
>> 
>> Thanks
>> Akshay
>> 
>> On Thu, Jun 23, 2016 at 1:00 AM, Assaf Muller  wrote:
>>> 
>>> On Wed, Jun 22, 2016 at 3:17 PM, Akshay Kumar Sanghai
>>>  wrote:
 Hi,
 I have a multinode openstack installation (3 controller, 3 network
 nodes,
 and some compute nodes).
 Like l3 agent, is high availability feature available for the lbaas v2
 agent?
>>> 
>>> It is not. Nir Magnezi is working on a couple of patches to implement
>>> a simplistic HA solution for LBaaS v2 with haproxy:
>>> https://review.openstack.org/#/c/28/
>>> https://review.openstack.org/#/c/327966/
>>> 
 
 Thanks
 Akshay
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Openstack Neutron lbaas question

[Doug Wiegley]

Hi,

LBaaS is installed automatically if neutron is present. Then you just need to 
install a driver and get everything configured.  I’d start here:

http://docs.openstack.org/liberty/networking-guide/adv-config-lbaas.html 


Thanks,
doug


> On Jun 23, 2016, at 9:33 AM, zhihao wang  wrote:
> 
> 
> Dear Openstack Team:
> 
> I have some questions regarding to openstack Mitaka Neutron lbaas 
> 
> For Neutron-lbaas installation, should I just follow this LINK
> 
> https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun 
> 
> 
> but my openstack has controller and compute nodes. is not installed by 
> Devstack, it is manually installed on production environment (one controller 
> and a few computed nodes)
>  
> Can I install Neutron-lbaas on production environment , if I can, then what 
> is the document guide?
> Thanks
> wally
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Doug Wiegley]

> On Jun 21, 2016, at 11:29 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> 
> On 06/21/2016 12:53 PM, Doug Wiegley wrote:
>>> On Jun 21, 2016, at 2:56 AM, Thierry Carrez <thie...@openstack.org>
>>> wrote:
>>> Chris Dent wrote:
>>>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>>>> So, it sounds like you’ve just described the job of the TC. And
>>>>> they have so far refused to define OpenStack, leading to a
>>>>> series of derivative decisions that seem … inconsistent over
>>>>> time.
>>>> 
>>>> Thanks for writing down what I was thinking. I agree that
>>>> OpenStack needs some architectural vision, direction, leadership,
>>>> call it what you will. Every time I've voted for the _Technical_
>>>> Committee that leadership is what I've wanted my vote to be
>>>> creating.
>>> 
>>> The TC is a representative body which is elected to make top-down
>>> decisions on OpenStack. However, as much as our community loves the
>>> idea of "technical leadership" and "vision", they hate the top-down
>>> decisions that come with it (especially when that top-down decision
>>> doesn't go their way). They prefer bottom-up consensus.
>>> 
>>> So I'd argue that you need both. You need the TC whenever a hard
>>> call has to be made, but in order to minimize the number of those
>>> hard calls (and favor consensus building) you also need working
>>> groups to build a bottom-up reasonable way forward.
>> 
>> This reads very strange to me, as I’d expect a group of technical
>> leaders to both make hard calls *and* to be able to build consensus
>> on overall direction and vision. They’re two sides of the same coin.
>> What is it about our process that means the TC can’t build consensus
>> on direction, but can only impose its will? I expect you didn’t mean
>> it to sound that way, though. Is the workload too high on the
>> bookkeeping to prevent the vision building? Are we too afraid of the
>> implications of defining ‘what is openstack?’, and what it might mean
>> to existing projects and the community? I’d think that in the
>> long-run, it’d prevent seemingly unrelated topics from seeming to go
>> sideways so often, and prevent a lot of these “hard calls”.
> 
> Perhaps you weren't around for the endless (and pointless) discussions around 
> what is "the core of OpenStack"? Or you weren't around for the endless (and 
> conflicting, contradictory, and religious) battles that were waged during the 
> old "incubation" and "graduation" procedures?
> 
> Ask Clint, Flavio and Devananda how fruitful the Marconi/Zaqar "architectural 
> review" by the TC was.

That would be interesting to hear, and how this group would avoid and/or help 
such issues.

> 
>> But, I’m also on the fringe that is very ready to call the “big tent”
>> a failed experiment in attempting to avoid hard calls, too.
> 
> That's because you think the big tent initiative is something that it is not.
> 
> And we've had this conversation before, but you insist on equating the big 
> tent initiative with the TC broadening what its definition of OpenStack was. 
> And that's not what the big tent initiative was, as I've said repeatedly.
> 
> The big tent initiative was specifically to change from a subjective set of 
> requirements that a project must meet in order to be "part of OpenStack" into 
> an objective set of requirements.

Wait, wait, wait. The TC has a definition of OpenStack?  Oooh, what is it?

And if we can’t answer that, how can there be objective criteria to meet an 
undefined quantity?  Oh wait, that’s what the tent is today. Except Go, of 
course.

This is tangent from the main thread topic, so I’ll let it go.

Thanks,
doug

> 
> We removed the subjective, bike-shedding, and cringe-inducing "graduation 
> review" from the application process and instead focused on documenting a 
> clear set of objective requirements that projects could obligate themselves 
> to meeting if they wanted to "be part of OpenStack".
> 
>>>> It may be that an architecture working group can provide some
>>>> guidance that people will find useful. Against the odds I think
>>>> those of us in the API-WG have actually managed to have a
>>>> positive influence. We've not shaken things down to the
>>>> foundations from which a great a glorious future may be born -- a
>>>> lot of compromises have been made and not everybody wants to play
>>>> along -- but things are going in

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Doug Wiegley]

> On Jun 21, 2016, at 2:56 AM, Thierry Carrez <thie...@openstack.org> wrote:
> 
> Chris Dent wrote:
>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>> So, it sounds like you’ve just described the job of the TC. And they
>>> have so far refused to define OpenStack, leading to a series of
>>> derivative decisions that seem … inconsistent over time.
>> 
>> Thanks for writing down what I was thinking. I agree that OpenStack
>> needs some architectural vision, direction, leadership, call it what
>> you will. Every time I've voted for the _Technical_ Committee that
>> leadership is what I've wanted my vote to be creating.
> 
> The TC is a representative body which is elected to make top-down decisions 
> on OpenStack. However, as much as our community loves the idea of "technical 
> leadership" and "vision", they hate the top-down decisions that come with it 
> (especially when that top-down decision doesn't go their way). They prefer 
> bottom-up consensus.
> 
> So I'd argue that you need both. You need the TC whenever a hard call has to 
> be made, but in order to minimize the number of those hard calls (and favor 
> consensus building) you also need working groups to build a bottom-up 
> reasonable way forward.

This reads very strange to me, as I’d expect a group of technical leaders to 
both make hard calls *and* to be able to build consensus on overall direction 
and vision. They’re two sides of the same coin. What is it about our process 
that means the TC can’t build consensus on direction, but can only impose its 
will? I expect you didn’t mean it to sound that way, though. Is the workload 
too high on the bookkeeping to prevent the vision building? Are we too afraid 
of the implications of defining ‘what is openstack?’, and what it might mean to 
existing projects and the community? I’d think that in the long-run, it’d 
prevent seemingly unrelated topics from seeming to go sideways so often, and 
prevent a lot of these “hard calls”.

But, I’m also on the fringe that is very ready to call the “big tent” a failed 
experiment in attempting to avoid hard calls, too.

> 
>> It may be that an architecture working group can provide some
>> guidance that people will find useful. Against the odds I think
>> those of us in the API-WG have actually managed to have a positive
>> influence. We've not shaken things down to the foundations from
>> which a great a glorious future may be born -- a lot of compromises
>> have been made and not everybody wants to play along -- but things
>> are going in the right direction, for some people, in some projects.
>> Maybe a similar thing can happen with architecture.
> 
> That is my hope. I see the API WG and the Architecture WG as groups of 
> experts in specific domains preparing recommendations and long-term plans. 
> They don't have authority to force them onto projects. Ideally projects adopt 
> them because they see them as the right way to do things.
> 
> And for the very few things that the TC deems necessary for OpenStack and 
> where bottom-up didn't get it in a specific project (if all else fails), the 
> TC can make a top-down request to a project to do things a certain way. The 
> project can them either comply or reject the TC oversight and become an 
> unofficial project.

Don’t get me wrong, I welcome this initiative. I find it mildly disconcerting 
that the folks that I thought we were electing to fill this role will instead 
be filled by others, but the vacuum does need to be filled, and I thank Clint 
for stepping up.

Thanks,
doug


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


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

Re: [openstack-dev] [all] Proposal: Architecture Working Group

[Doug Wiegley]

So, it sounds like you’ve just described the job of the TC. And they have so 
far refused to define OpenStack, leading to a series of derivative decisions 
that seem … inconsistent over time.

How is this body going to be different?

How will it have any teeth, and not just end up with the standard entrenched 
projects ignoring it?

Thanks,
doug


> On Jun 17, 2016, at 3:52 PM, Clint Byrum  wrote:
> 
> ar·chi·tec·ture
> ˈärkəˌtek(t)SHər/
> noun
> noun: architecture
> 
>1. 
> 
>the art or practice of designing and constructing buildings.
> 
>synonyms:building design, building style, planning, building, 
> construction; 
> 
>formalarchitectonics 
> 
>"modern architecture"
> 
>the style in which a building is designed or constructed, especially with 
> regard to a specific period, place, or culture.
> 
>plural noun: architectures
> 
>"Victorian architecture"
> 
>2. 
> 
>the complex or carefully designed structure of something.
> 
>"the chemical architecture of the human brain"
> 
>the conceptual structure and logical organization of a computer or 
> computer-based system.
> 
>"a client/server architecture"
> 
>synonyms:structure, construction, organization, layout, design, build, 
> anatomy, makeup; 
> 
>informalsetup 
> 
>"the architecture of a computer system"
> 
> 
> Introduction
> =
> 
> OpenStack is a big system. We have debated what it actually is [1],
> and there are even t-shirts to poke fun at the fact that we don't have
> good answers.
> 
> But this isn't what any of us wants. We'd like to be able to point
> at something and proudly tell people "This is what we designed and
> implemented."
> 
> And for each individual project, that is a possibility. Neutron can
> tell you they designed how their agents and drivers work. Nova can
> tell you that they designed the way conductors handle communication
> with API nodes and compute nodes. But when we start talking about how
> they interact with each other, it's clearly just a coincidental mash of
> de-facto standards and specs that don't help anyone make decisions when
> refactoring or adding on to the system.
> 
> Oslo and cross-project initiatives have brought some peace and order
> to the implementation and engineering processes, but not to the design
> process. New ideas still start largely in the project where they are
> needed most, and often conflict with similar decisions and ideas in other
> projects [dlm, taskflow, tooz, service discovery, state machines, glance
> tasks, messaging patterns, database patterns, etc. etc.]. Often times this
> creates a log jam where none of the projects adopt a solution that would
> align with others. Most of the time when things finally come to a head
> these things get done in a piecemeal fashion, where it's half done here,
> 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
> looks like  chaos, because that's precisely what it is.
> 
> And this isn't always a technical design problem. OpenStack, for instance,
> isn't really a micro service architecture. Of course, it might look like
> that in diagrams [2], but we all know it really isn't. The compute node is
> home to agents for every single concern, and the API interactions between
> the services is too tightly woven to consider many of them functional
> without the same lockstep version of other services together. A game to
> play is ask yourself what would happen if a service was isolated on its
> own island, how functional would its API be, if at all. Is this something
> that we want? No. But there doesn't seem to be a place where we can go
> to actually design, discuss, debate, and ratify changes that would help
> us get to the point of gathering the necessary will and capability to
> enact these efforts.
> 
> Maybe nova-compute should be isolated from nova, with an API that
> nova, cinder and neutron talk to. Maybe we should make the scheduler
> cross-project aware and capable of scheduling more than just nova
> instances. Maybe we should have experimental groups that can look at how
> some of this functionality could perhaps be delegated to non-openstack
> projects. We hear that Mesos, for example to help with the scheduling
> aspects, but how do we discuss these outside hijacking threads on the
> mailing list? These are things that we all discuss in the hallways
> and bars and parties at the summit, but because they cross projects at
> the design level, and are inherently a lot of social and technical and
> exploratory work, Many of us fear we never get to a place of turning
> our dreams into reality.
> 
> So, with that, I'd like to propose the creation of an Architecture Working
> Group. This group's charge would not be design by committee, but a place
> for architects to share their designs and gain support across projects
> to move forward with and ratify architectural decisions. That includes
> coordinating exploratory work that may turn 

Re: [openstack-dev] [octavia][neutron] Fwd: [Openstack-stable-maint] Stable check of openstack/octavia failed

[Doug Wiegley]

Hi Matt,

Thanks for the heads up, we are looking into it. And adding some sort of 
monitor.

doug

> On Jun 6, 2016, at 11:27 AM, Matt Riedemann  
> wrote:
> 
> Can someone from the Octavia team check on the stable/liberty failures for 
> the unit test runs?  Those have been failing for several weeks, if not 
> months, now, which makes having a job run Octavia unit tests on the 
> periodic-stable queue pointless since they never pass.
> 
> Keep in mind the octavia repo has the stable:follows-policy tag in the 
> governance repo [1] and part of that tag being applied to the project is 
> actually maintaining the stable branches, which includes keeping the CI jobs 
> running.
> 
> [1] 
> https://governance.openstack.org/reference/projects/neutron.html#project-neutron
> 
> 
>  Forwarded Message 
> Subject: [Openstack-stable-maint] Stable check of openstack/octavia failed
> Date: Mon, 06 Jun 2016 06:23:15 +
> From: A mailing list for the OpenStack Stable Branch test reports. 
> 
> Reply-To: openstack-dev@lists.openstack.org
> To: openstack-stable-ma...@lists.openstack.org
> 
> Build failed.
> 
> - periodic-octavia-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-octavia-docs-liberty/9796536/
>  : SUCCESS in 3m 01s
> - periodic-octavia-python27-liberty 
> http://logs.openstack.org/periodic-stable/periodic-octavia-python27-liberty/6d96415/
>  : FAILURE in 4m 36s
> - periodic-octavia-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-octavia-docs-mitaka/b2074b4/
>  : SUCCESS in 3m 36s
> - periodic-octavia-python27-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-octavia-python27-mitaka/f220954/
>  : SUCCESS in 3m 59s
> 
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron][Release] Changing release model for *-aas services

[Doug Wiegley]

Agreed.

doug

> On May 31, 2016, at 12:12 PM, Armando M.  wrote:
> 
> Hi folks,
> 
> Having looked at the recent commit volume that has been going into the *-aas 
> repos, I am considering changing the release model for neutron-vpnaas, 
> neutron-fwaas, neutron-lbaas from release:cycle-with-milestones [1] to 
> release:cycle-with-intermediary [2]. This change will allow us to avoid 
> publishing a release at fixed times when there's nothing worth releasing.
> 
> I'll follow up with a governance change, as I know of the imminent deadline 
> [3].
> 
> Thoughts?
> Armando
> 
> [1] 
> https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
>  
> 
> [2] 
> https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
>  
> 
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095490.html 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Mid-cycle development sprint

[Doug Wiegley]

This is kind of tough timing-wise from the states. Since we lose about 24 hours 
to travel/time zone, that means realistically leaving on Saturday from over the 
pond. Not that I’m opposed to weekend travel, but summer logistics are hard 
(and not possible for me on this one.) Remote for me, I suppose? Or I’ll find a 
local approximation of a pub,and work there, in spirit.

doug


> On May 26, 2016, at 2:47 PM, Henry Gessau  wrote:
> 
> I am happy to announce that the location logistics for the Neutron mid-cycle
> have been finalized. The mid-cycle will take place in Cork, Ireland on August
> 15-17. I have updated the wiki [1] where you will find a link to an etherpad
> with all the details. There you can add yourself if you plan to attend, and
> make updates to topics that you would like to work on.
> 
> 
> [1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC

[Doug Wiegley]

In a nutshell, you’ve got it, you can’t add an API without a reference 
implementation, including data-plane, which has to be open-source (though does 
not have to itself be openstack.)

> o   Especially as Stadium, can we let Neutron to lead the industry, given 
> broad enough community interest?


You can do anything you want outside the stadium, which is where 
experimental/incubation is meant to happen.  Inside the stadium means, 
“official openstack project”, which means it has an open-source implementation.

If all backends are closed-source, it’s not open as openstack defines it: 
https://governance.openstack.org/reference/opens.html 


There isn’t any wiggle room there. This isn’t a neutron argument; feel free to 
take it up with the TC.

Thanks,
doug



> On May 20, 2016, at 6:37 PM, Elzur, Uri  wrote:
> 
> Hi Armando, Cathy, All <>
>  
> First I apologize for the delay, returning from a week long international 
> trip. (yes, I know,  a lousy excuse on many accounts…)
>  
> If I’m attempting to summarize all the responses, it seems like
> · A given abstraction in Neutron is allowed (e.g. in support of SFC), 
> preferably not specific to a given technology e.g. NSH for SFC
> · A stadium project is not held to the same tests (but we do not have 
> a “formal” model here, today) and therefore can support even a specific 
> technology e.g. NSH (definitely better with abstractions to meet Neutron 
> standards for future integration)
>  
> However,
> · There still is a chicken and egg phenomenon… how can a technology 
> become main stream with OPEN SOURCE support  if we can’t get an OpenStack to 
> support the required abstractions before the technology was adopted 
> elsewhere??
> o   Especially as Stadium, can we let Neutron to lead the industry, given 
> broad enough community interest?
> · BTW,  in this particular case, there originally has been a direct 
> ODL access as a NSH solution (i.e. NO OpenStack option), then we got Tacker 
> (now an Neutron Stadium project, if I get it right) to support SFC and NSH, 
> but we are still told that networking-sfc (another Neutron Stadium project ) 
> can’t do the same….
> · Also regarding the  following comment made on another message in 
> this thread, “As to OvS features, I guess the OvS ml is a better place, but 
> wonder if the Neutron community wants to hold itself hostage to the pace of 
> other projects who are reluctant to adopt a feature”, what I mean is again, 
> that chicken and egg situation as above. Personally, I think OpenStack 
> Neutron should allow mechanisms that are of interest / value to the 
> networking community at large, to “ experiment with the abstraction” as you 
> stated, independent of other organizations/projects…
>  
> SOOO, is the bottom line that we agree that supporting NSH explicitly in 
> networking-sfc can be added now?
>  
>  
> Thx
>  
> Uri (“Oo-Ree”)
> C: 949-378-7568
>  
>  <>From: Armando M. [mailto:arma...@gmail.com] 
> Sent: Friday, May 13, 2016 5:14 PM
> To: Cathy Zhang 
> Cc: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC
>  
>  
>  
> On 13 May 2016 at 16:01, Cathy Zhang  > wrote:
> Hi Uri,
>  
> Current networking-sfc API allows the user to specify the data path SFC 
> encapsulation mechanism and NSH could be one of the encapsulation options. 
> But since OVS release has not supported the NSH yet, we have to wait until  
> NSH is added into OVS and then start to support the NSH encapsulation 
> mechanism in the data path.
>  
> One can support NSH whichever way they see fit. NSH in OVS is not something 
> Neutron can do anything about. Neutron is about defining abstractions that 
> can apply to a variety of technologies and experiment with what open source 
> component is available on the shelves. Anyone can take the abstraction and 
> deliver whatever technology stack they want with it and we'd happily gather 
> any feedback to iterate on the abstraction to address more and more use case.
>  
>  
> AFAIK, it is the position of Neutron to have any OVS related new features 
> developed inside the OVS community. 
>  
> Thanks,
> Cathy
>  
> From: Elzur, Uri [mailto:uri.el...@intel.com ] 
> Sent: Friday, May 13, 2016 3:02 PM
> To: OpenStack Development Mailing List (not for usage questions); Armando M
> Subject: [openstack-dev] [Neutron] support of NSH in networking-SFC
>  
> Hi Armando <>
>  
> As an industry we are working on SFC for 3 years or so (more?). Still to 
> date, we are told we can’t get Neutron or even a Stadium project e.g. 
> networking-SFC to support NSH (in IETF LC phase) because OvS has not 
> supported NSH. Is this an official position of 

Re: [openstack-dev] [nova][neutron] Is it still valid/supported to create a network with a br- id?

[Doug Wiegley]

> On May 15, 2016, at 10:17 AM, Matt Riedemann  
> wrote:
> 
>> On 5/15/2016 10:56 AM, Sean M. Collins wrote:
>> Matt Riedemann wrote:
>>> The nova create-server API allows passing a network id that's prefixed with
>>> br- [1]. That was added due to this bug from Folsom [2].
>>> 
>>> I'm wondering if that's still valid? Looking at the network.id data model in
>>> Neutron it doesn't look like it would be [3].
>> 
>> Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs.
>> 
>> Just because some vendor plugin decides that their going to break the
>> Networking API contract and define their own ID scheme,
>> doesn't mean that we should fix it to help them.
>> 
>> That commit shouldn't have been accepted into Nova, and I don't think
>> that we should support anything but a UUID for a network id. Period.
> 
> Yeah, I agree. Remember, this was Folsom, when Neutron was a young and brash 
> Quantum.
> 
> I was just trying to sort out if there is still anything out there in the 
> stadium that relies on this working. If not, I'll microversion it out of 
> support for the Nova API when we add support for auto-allocated-topology.

I agree with Sean.  Even if there is anything that relies on non uuid, it's 
totally fair to break it. 

Doug

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

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

Re: [openstack-dev] [neutron][FWaaS] __init__ arguments issue status

[Doug Wiegley]

This break is almost certainly because of the following neutron change, to 
unwind the incestuous inheritance that was in neutron (dependency arrow was 
circular):

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


I don’t expect there will be a lot of appetite to revert that, so it will need 
to be addressed in neutron-fwaas. Likely it should’ve had an ML warning first, 
sorry about that, this has been a longstanding issue.

doug



> On May 5, 2016, at 7:00 PM, Frances, Margaret 
>  wrote:
> 
> Hi Doug.  
> 
> The old and new MROs are both pretty complicated, and it’s not entirely clear 
> to me yet why the original one worked. (The MROs are included below for 
> reading pleasure; they're embellished to show the incoming args to self’s 
> init and outgoing args to super’s init in each case.)
> 
> I’m fairly sure the APIs for the mixins can be made the same, and I’ll try 
> that.  But I still wonder if in fact the problem is a base class ordering 
> issue.  
> 
> The error that 223343 produced occurs in method call #6 in the "AFTER" MRO, 
> where we get the following trace:
> 
>   super(PeriodicTasks, self).__init__()
> TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> 
> For grins, we changed PeriodicTasks’s call to super init as suggested by the 
> trace:
> 
>   super(PeriodicTasks, self).__init__(conf)
> 
> 
> At this point FWaaSAgentRpcCallbackMixin (AFTER, #8) complained:
> 
>   super(FWaaSAgentRpcCallbackMixin, self).__init__(host)
> TypeError: object.__init__() takes no parameters
> 
> 
> Changing *that* class as suggested elicited the following (to me baffling) 
> result:
> 
>   super(FWaaSAgentRpcCallbackMixin, self).__init__()
> TypeError: __init__() takes exactly 2 arguments (1 given)
> 
> 
> I find it baffling because FWaaSAgentRpcCallbackMixin is the end of the line, 
> it’s a subclass of object, and object doesn’t allow arguments to init (so 
> whose init is that? that’s the next thing I’m going to look at).  (It’s for 
> these same reasons that I don’t understand why things worked before the 
> 223343 change.)
> 
> I’m still looking at things.  (And learning about MRO, which I’ve never 
> really dealt with before.)  Will run pdb and see what surfaces.  
> 
> Thanks for your help.  Thoughts, comments, suggestions all welcome.
> Margaret
> 
> 
> BEFORE 223343
>  1. varmour_router_vArmourL3NATAgent  (host, conf)-->(host, conf)
>  2. agent_L3NATAgent  (host, conf)-->(conf)
>  3. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
>  4. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
>  5. ha_AgentMixin (host)-->(host)
>  6. dvr_AgentMixin(host)-->(host)
>  7. manager_Manager   (host)-->(conf)
>  8. periodic_task_PeriodicTasks   (conf)-->()
>  9. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
> 10. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
> 11. object
> 
> AFTER 223343
>  1. varmour_router_vArmourL3NATAgent  (host, conf)-->(host, conf)
>  2. agent_L3NATAgent  (host, conf)-->(host)
>  3. ha_AgentMixin (host)-->(host)
>  4. dvr_AgentMixin(host)-->(host)
>  5. manager_Manager   (host)-->(conf)
>  6. periodic_task_PeriodicTasks   (conf)-->()
>  7. firewall_l3_agent_FWaaSL3AgentRpcCallback (conf)-->(host)
>  8. api_FWaaSAgentRpcCallbackMixin(host)-->(host)
>  9. object
> 
> --
> Margaret Frances
> Eng 4, Prodt Dev Engineering
> 
> 
> 
>> On May 5, 2016, at 7:06 PM, Doug Hellmann > > wrote:
>> 
>> Excerpts from Nate Johnston's message of 2016-05-05 17:40:13 -0400:
>>> FWaaS team,
>>> 
>>> After a day of looking at the tests currently failing in the FWaaS repo, I
>>> believe I have the issue narrowed down considerably. First, to restate what
>>> is going on.  If you check out the neutron-fwaas repository and run `tox -e
>>> py27` in it, you will get six errors all in the
>>> neutron_fwaas.tests.unit.services.firewall.agents.varmour.test_varmour_router.TestVarmourRouter
>>> section.
>>> Running the py34 tests results in similar problems.  The failures follow
>>> the following form:
>>> 
>>> Captured traceback:
>>> 
>>> ~~~
>>> 
>>>Traceback (most recent call last):
>>> 
>>>  File
>>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>>> line 190, in test_agent_external_gateway
>>> 
>>>router = self._create_router()
>>> 
>>>  File
>>> "neutron_fwaas/tests/unit/services/firewall/agents/varmour/test_varmour_router.py",
>>> line 87, in _create_router
>>> 
>>>router = varmour_router.vArmourL3NATAgent(HOSTNAME, self.conf)
>>> 
>>>  File
>>> 

[openstack-dev] [neutron][fwaas][vpnaas][lbaas][octavia] summit summary - future of the advanced services

[Doug Wiegley]

Egads, that’s a long subject prefix.  Anyways, we had a design session on the 
future of the advanced services:

https://etherpad.openstack.org/p/newton-neutron-future-adv-services

In a nutshell, vpn and fw are critically lacking active contributors at 
present. Again. A proposal was made to remove them from the neutron stadium, 
effectively making them the equivalent of stackforge projects (openstack 
experimental in the new terminology.)  This was rejected in favor of giving 
them until Ocata-1 to retain stadium status, similar to the criteria laid out 
in the later neutron stadium discussion:

https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution

Given how often we’ve extended the lives of those two repos by yet another six 
months, this time we’ll be looking for regular progress up to ocata-1, with 
final criteria being done (ish) by then. But, as agreed at the summit, if 
things go utterly dark post-summit, then you can expect to see governance 
patches to remove them from the stadium much faster than Ocata-1.

After that session, but worth mentioning here, further discussions led to a 
proposal to make lbaas a standalone project, with a standalone endpoint, but 
adopting the current API:

https://review.openstack.org/#/c/310805/
https://review.openstack.org/#/c/310667/

and here’s a WIP governance patch for flavor:

https://review.openstack.org/313056

This achieved broad consensus among those present for the follow-up 
conversations (-1 nits on that patch aside), but please comment on any of those 
if you have comments/concerns.

Next steps:

- Monitor progress of vpn and fw.
- Cleanup lbaas spinout specs, generate a timeline for minimum work required.

Thanks,
doug



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

Re: [openstack-dev] [neutron][devstack] State of the refactor

[Doug Wiegley]

> On May 5, 2016, at 8:57 AM, Sean M. Collins  wrote:
> 
> During the Austin summit, there was a discussion in the QA meetings
> about the future of Neutron's support in DevStack. It's been an ongoing
> effort, and I'd like to step back and give everyone a view of the Big
> Picture.
> 
> https://etherpad.openstack.org/p/newton-qa-devstack-roadmap
> 
> A year ago at the NYC QA midcycle, consensus was reached that in order
> to get Neutron to become the default deployment model for Devstack and
> finally deprecate Nova-Network, some grunt work would need to be done to
> clean up the DevStack code.
> 
> Dean wrote about the experience in his blog:
> 
> http://hackstack.org/x/blog/2015/03/30/qa-code-sprint
> 
>> DevStack's Neutron code is in bad shape. It has been continually
>> updated by many people who do not understand the Big Picture. I blame
>> myself for not staying on top of this code and allowing it to diverge
>> from the rest of DevStack's style and implementation. Other Sean found
>> a number of inconsistencies in variable names and uses as he tried to
>> get the single interface work done and we came to the inevitable
>> conclusion that it was time to start over.
> 
> So we did.
> 
> https://review.openstack.org/168438
> 
> The new lib/neutron is an attempt to only have the *bare minimum*
> configured for either an OVS or Linux Bridge deployment of Neutron. My

I’d actually suggest just linuxbridge (the install guide default), and make the 
OVS jobs use whatever mechanism the other plugins will have to use.

Thanks,
doug


> strategy was - start from scratch and build up enough Neutron
> configuration to get everything to launch, and have the network plumbed
> correctly. Everything else was left on the cutting room floor.
> 
> There are still some things that I did for the sake of expediency, that
> I am sure will need to be improved in the future. However, the code is
> very close to completion - there's still some work that needs to be
> done, but I see the light at the end of the tunnel.
> 
> For anything that isn't ML2 based, or the LB or OVS agent, Dean and I
> share this view:
> 
>> But what about the plugins? What about the advanced services? What
>> about the vendors? I can't do it all at once. The first priority is to
>> get a 'minimum viable Neutron' configuration to use as the default.
>> The old code was renamed not removed, and exactly zero of the
>> configuration variables and service names have changed. Nothing should
>> be directly importing lib/neutron* so that change is handled in
>> DevStack and Grenade already. After we have working linuxbridge and
>> ovs configurations we can look at what else needs to be included.
> 
> Sean Dague and I have also been kicking around some ideas about adding
> another hook to the DevStack plugin contract so that DevStack plugins
> that do network things have a chance to create networks and wire
> everything during installation and configuration, as part of a DevStack
> plugin call.
> 
> The basic reasoning for this is, the current lib/neutron-legacy has tons
> of knobs for plugging veths into things, creating provider networks,
> etc.. - those things are very specific to a deployment or networking
> type, so they should be moved into a plugin so they don't gunk up the
> main code path and also avoid trampling one another (like they do
> today).
> 
> The current lib/neutron weighs in around 500 lines of code, and the l3
> setup code (which was the nastiest) is 300 lines, split out into a
> separate file. Partially to allow other plugins to call this code, and
> partially because of a divide-and-conquer strategy I am employing for
> the refactor.
> 
> If you haven't read my post about eliminating the DevStack layer, this
> is also part of my thought process for the refactor, and how to support
> other configurations in DevStack.
> 
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091764.html
> 
> So, take a look at what I've done so far, take it for a spin, and if you
> have any thoughts or ideas please share them! 
> 
> -- 
> Sean M. Collins
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

[Doug Wiegley]

Were we looking at the same etherpad?  I think the ‘inclusion criteria’ and 
‘benefits of the proposal’ sections cover those two points. Are you referring 
to something else?

Thanks,
doug


> On May 2, 2016, at 12:18 PM, Gal Sagie  wrote:
> 
> Maybe it can help if instead of trying to define criteria to which projects 
> dont fit into
> the stadium, try to define in your spec what IT IS, and for what purpose its 
> there.
> 
> 
> On Mon, May 2, 2016 at 8:53 PM, Kyle Mestery  > wrote:
> On Mon, May 2, 2016 at 12:22 PM, Armando M.  > wrote:
> >
> >
> > On 30 April 2016 at 14:24, Fawad Khaliq  > > wrote:
> >>
> >> Hi folks,
> >>
> >> Hope everyone had a great summit in Austin and got back safe! :)
> >>
> >> At the design summit, we had a Neutron stadium evolution session, which
> >> needs your immediate attention as it will impact many stakeholders of
> >> Neutron.
> >
> >
> > It's my intention to follow up with a formal spec submission to
> > neutron-specs as soon as I recover from the trip. Then you'll have a more
> > transparent place to voice your concern.
> >
> >>
> >>
> >> To summarize for everyone, our Neutron leadership made the following
> >> proposal for the “greater-good” of Neutron to improve and reduce burden on
> >> the Neutron PTL and core team to avoid managing more Neutron drivers:
> >
> >
> > It's not just about burden. It's about consistency first and foremost.
> >
> >>
> >>
> >> Quoting the etherpad [1]
> >>
> >> "No request for inclusion are accepted for projects focussed solely on
> >> implementations and/or API extensions to non-open solutions."
> >
> >
> > By the way, this was brought forward and discussed way before the Summit. In
> > fact this is already implemented at the Neutron governance level [1].
> >
> >>
> >> To summarize for everyone what this means is that all Neutron drivers,
> >> which implement non open source networking backends are instantly out of 
> >> the
> >> Neutron stadium and are marked as "unofficial/unsupported/remotely
> >> affiliated" and rest are capable of being tagged as "supported/official”.
> >
> >
> > Totally false.
> >
> > All this means is that these projects do not show up in list [1] (minus [2],
> > which I forgot): ie. these projects are the projects the Neutron team
> > vouches for. Supportability is not a property tracked by this list. You,
> > amongst many, should know that it takes a lot more than being part of a list
> > to be considered a supported solution, and I am actually even surprised that
> > you are misled/misleading by bringing 'support' into this conversation.
> >
> > [1] http://governance.openstack.org/reference/projects/neutron.html 
> > 
> > [2] https://review.openstack.org/#/c/309618/ 
> > 
> >
> >>
> >>
> >> This eliminates all commercial Neutron drivers developed for many service
> >> providers and enterprises who have deployed OpenStack successfully with
> >> these drivers. It’s unclear how the OpenStack Foundation will communicate
> >> its stance with all the users but clearly this is a huge set back for
> >> OpenStack and Neutron. Neutron will essentially become closed to all
> >> existing, non-open drivers, even if these drivers have been compliant with
> >> Neutron API for years and users have them deployed in production, forcing
> >> users to re-evaluate their options.
> >
> >
> > Again, totally false.
> >
> > The Neutron team will continue to stand behind the APIs and integration
> > mechanisms in a way that made the journey of breaking down the codebase as
> > we know it today possible. Any discussion of evolving these has been done
> > and will be done in the open and with the support of all parties involved,
> > non-open solutions included.
> >
> >>
> >>
> >> Furthermore, this proposal will erode confidence in Neutron and OpenStack,
> >> and destroy much of the value that the community has worked so hard to 
> >> build
> >> over the years.
> >>
> >>
> >> As a representative and member of the OpenStack community and maintainer
> >> of a Neutron driver (since Grizzly), I am deeply disappointed and disagree
> >> with this statement [2]. Tossing out all the non-open solutions is not in
> >> the best interest of the end user companies that have built working
> >> OpenStack clusters. This proposal will lead OpenStack end users who 
> >> deployed
> >> different drivers to think twice about OpenStack communities’ commitment to
> >> deliver solutions they need. Furthermore, this proposal punishes OpenStack
> >> companies who developed commercial backend drivers to help end users bring
> >> up OpenStack clouds.
> >
> >
> > What? Now you're just spreading FUD.
> >
> > What is being discussed in that etherpad is totally in line with [1], which
> > you 

Re: [openstack-dev] [neutron][tc] Neutron stadium evolution from Austin

[Doug Wiegley]

> On Apr 30, 2016, at 1:24 PM, Fawad Khaliq  wrote:
> 
> Hi folks,
> 
> Hope everyone had a great summit in Austin and got back safe! :)
> 
> At the design summit, we had a Neutron stadium evolution session, which needs 
> your immediate attention as it will impact many stakeholders of Neutron.
> 
> To summarize for everyone, our Neutron leadership made the following proposal 
> for the “greater-good” of Neutron to improve and reduce burden on the Neutron 
> PTL and core team to avoid managing more Neutron drivers:
> 
> Quoting the etherpad [1]
> 
> "No request for inclusion are accepted for projects focussed solely on 
> implementations and/or API extensions to non-open solutions.”

Let’s be clear about official openstack projects versus in the ecosystem versus 
whatever, which is defined by the TC, not neutron: 
https://governance.openstack.org/reference/new-projects-requirements.html 

> 
> To summarize for everyone what this means is that all Neutron drivers, which 
> implement non open source networking backends are instantly out of the 
> Neutron stadium and are marked as "unofficial/unsupported/remotely 
> affiliated" and rest are capable of being tagged as "supported/official”.

So, before we throw around statements like “supported” vs “unsupported”, let’s 
take a look at what the stadium governance change really entails:

- The neutron core team won’t review/merge/maintain patches for your 
plugin/driver. In many cases, this was already true.
- The neutron release team won’t handle tagging your releases. In many cases, 
this was already true.
- The neutron PTL is no longer involved in your repository’s governance. In 
many cases, this was effectively already true.

It doesn’t mean it isn’t a valid project that supports neutron interfaces.

In or out of the stadium, all plugins have these challenges:

- If you’re not using a stable interface, you’ll break a lot.
- If you are using a stable interface, you’ll still break some (standard rot).
- Vendors will need to support and test their own code.

Every time this comes up, people get upset that neutron is closing its doors, 
or somehow invalidating all the existing plugins. Let’s review:

- The neutron api and plugin interfaces are not going away.
- There is ongoing work to libify more interfaces, for the sake of 
plugins/drivers.
- There is a strong push for more documentation to make integrating better.
- Non-stadium projects still have access to their infra repos and CI resources.

Armando’s proposal was about recognizing reality, not some huge change in how 
things actually work. What is the point of having a project governed by Neutron 
that isn’t doing anything but consuming neutron interfaces, and is otherwise 
uninvolved? How can you expect neutron to vouch for those? What is your 
proposal?

Thanks,
doug


> 
> This eliminates all commercial Neutron drivers developed for many service 
> providers and enterprises who have deployed OpenStack successfully with these 
> drivers. It’s unclear how the OpenStack Foundation will communicate its 
> stance with all the users but clearly this is a huge set back for OpenStack 
> and Neutron. Neutron will essentially become closed to all existing, non-open 
> drivers, even if these drivers have been compliant with Neutron API for years 
> and users have them deployed in production, forcing users to re-evaluate 
> their options.
> 
> Furthermore, this proposal will erode confidence in Neutron and OpenStack, 
> and destroy much of the value that the community has worked so hard to build 
> over the years.
> 
> As a representative and member of the OpenStack community and maintainer of a 
> Neutron driver (since Grizzly), I am deeply disappointed and disagree with 
> this statement [2]. Tossing out all the non-open solutions is not in the best 
> interest of the end user companies that have built working OpenStack 
> clusters. This proposal will lead OpenStack end users who deployed different 
> drivers to think twice about OpenStack communities’ commitment to deliver 
> solutions they need. Furthermore, this proposal punishes OpenStack companies 
> who developed commercial backend drivers to help end users bring up OpenStack 
> clouds.
> 
> Also, we have to realize that this proposal divides the community rather than 
> unifying it. If it proceeds, it seems all OpenStack projects should follow 
> for consistency. For example, this should apply to Nova which means HyperV 
> and vShphere can't be part of Nova, PLUMgrid can't be part of Kuryr, and ABC 
> company cannot have a driver/plugin for a XYZ project.
> 
> Another thing to note is, for operators, the benefit is that the flexibility 
> up until now has allowed them to embark on successful OpenStack deployments. 
> For those operators, yanking out support they’ve come to depend on makes 
> things worse. While certain team members may prefer only open-source 

Re: [openstack-dev] [neutron] Social at the summit

[Doug Wiegley]

> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka  wrote:
> 
> WAT???
> 
> It was never supposed to be core only. Everyone is welcome!

+2

irony intended.

Socials are not controlled by gerrit ACLs.  :-)

doug

> 
> Sent from my iPhone
> 
>> On 25 Apr 2016, at 11:56, Edgar Magana  wrote:
>> 
>> Would you extend it to ex-cores?
>> 
>> Edgar
>> 
>> 
>> 
>> 
>>> On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>>> 
>>> Ihar, Henry and I were talking and we thought Thursday night makes sense 
>>> for a Neutron social in Austin. If others agree, reply on this thread and 
>>> we'll find a place.
>>> 
>>> Thanks!
>>> Kyle
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] Social at the summit

[Doug Wiegley]

I’m in.

> On Apr 25, 2016, at 11:24 AM, Martin Hickey  wrote:
> 
> +1
> 
> Regards,
> Martin
> -
> Martin Hickey | Software Development | OpenStack | Tel: + 353 21 7306040 
> 
> Nate Johnston ---25/04/2016 10:58:21---Count me in. --N.
> 
> From: Nate Johnston 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 25/04/2016 10:58
> Subject: Re: [openstack-dev] [neutron] Social at the summit
> 
> 
> 
> 
> Count me in. 
> 
> --N.
> 
> On Monday, April 25, 2016, Kyle Mestery  > wrote:
> Ihar, Henry and I were talking and we thought Thursday night makes sense for 
> a Neutron social in Austin. If others agree, reply on this thread and we'll 
> find a place.
> 
> Thanks!
> Kyle
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Neutron lib hack has broken all decomposed projects

[Doug Wiegley]

Reverted the neutron change that started using this, which is the quickest path 
to unbreaking the children. We’ll have to unwind those child projects first.

doug


> On Apr 24, 2016, at 8:09 AM, Gary Kotton  wrote:
> 
> Another example is Lbaas - https://review.openstack.org/#/c/309766 
> /
> 
> I have posted https://review.openstack.org/309770 
> 
> 
> Its either that or we skip the current neutron-lib in the requirements file.
> 
> Neutron lib cores please look ASAP as the whole community is kind of stuck at 
> the moment…
> 
> From: Gary Kotton >
> Reply-To: OpenStack List  >
> Date: Sunday, April 24, 2016 at 4:48 PM
> To: OpenStack List  >
> Subject: [openstack-dev] [Neutron] Neutron lib hack has broken all decomposed 
> projects
> 
> Hi,
> Commit 4b17f1da1a5f65f0c4db395034ed732174a19315 has broken the pep8 of all of 
> the decomposed projects.
> Do we need this hacking check? Can we have it reverted
> An example of this is - 
> OVN - 
> http://logs.openstack.org/35/299835/3/check/gate-networking-ovn-pep8/3ad066e/console.html
>  
> 
> Thanks
> Gary
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Neutron lib hack has broken all decomposed projects

[Doug Wiegley]

That revert is https://review.openstack.org/#/c/309776 
<https://review.openstack.org/#/c/309776> , and is working its way through CI 
now.  About to lose connectivity for my flight to the summit…

doug


> On Apr 24, 2016, at 9:24 AM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> Reverted the neutron change that started using this, which is the quickest 
> path to unbreaking the children. We’ll have to unwind those child projects 
> first.
> 
> doug
> 
> 
>> On Apr 24, 2016, at 8:09 AM, Gary Kotton <gkot...@vmware.com 
>> <mailto:gkot...@vmware.com>> wrote:
>> 
>> Another example is Lbaas - https://review.openstack.org/#/c/309766 
>> <https://review.openstack.org/#/c/309766>/
>> 
>> I have posted https://review.openstack.org/309770 
>> <https://review.openstack.org/309770>
>> 
>> Its either that or we skip the current neutron-lib in the requirements file.
>> 
>> Neutron lib cores please look ASAP as the whole community is kind of stuck 
>> at the moment…
>> 
>> From: Gary Kotton <gkot...@vmware.com <mailto:gkot...@vmware.com>>
>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org 
>> <mailto:openstack-dev@lists.openstack.org>>
>> Date: Sunday, April 24, 2016 at 4:48 PM
>> To: OpenStack List <openstack-dev@lists.openstack.org 
>> <mailto:openstack-dev@lists.openstack.org>>
>> Subject: [openstack-dev] [Neutron] Neutron lib hack has broken all 
>> decomposed projects
>> 
>> Hi,
>> Commit 4b17f1da1a5f65f0c4db395034ed732174a19315 has broken the pep8 of all 
>> of the decomposed projects.
>> Do we need this hacking check? Can we have it reverted
>> An example of this is - 
>> OVN - 
>> http://logs.openstack.org/35/299835/3/check/gate-networking-ovn-pep8/3ad066e/console.html
>>  
>> <http://logs.openstack.org/35/299835/3/check/gate-networking-ovn-pep8/3ad066e/console.html>
>> Thanks
>> Gary
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 

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

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

[Doug Wiegley]

> On Apr 8, 2016, at 1:28 PM, Sean M. Collins  wrote:
> 
> Assaf Muller wrote:
>> I do want to say that ML2's "mechanism_drivers" option probably does
>> not have a default for the same reason we do not have a default for
>> the core_plugin value, we don't want to play favorites. From Neutron's
>> point of view, ignoring the existence of Devstack and upstream CI, I
>> think that makes sense.
>> 
> 
> True, I do see your point.
> 
> I do however think, that if you do pick the ML2 plugin as your
> core_plugin, it should have some mechanism drivers enabled by default. You
> shouldn't have to pick core_plugin, then be forced to pick
> mechanism_drivers. I'd rather see some mechanism_drivers already
> enabled, and if you have a difference in opinion, set mechanism_drivers
> in your local.conf.

I previously thought that a default there made no sense, but really, how is a 
default core plugin of ml2 with a default mech of local going to hurt anyone?

We had a big argument of whether to have a default DNS resolver… 8.8.8.8 leaks 
internal info to a third-party, hypervisor default potentially leaks 
infrastructure details.  Not having a default there at least has some 
security/privacy implications.

There are likely things that we can start defaulting in a saner way.

doug



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


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

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

[Doug Wiegley]

> On Apr 8, 2016, at 11:26 AM, Davanum Srinivas  wrote:
> 
> Team,
> 
> Steve pointed out to a problem in Stackalytics:
> https://twitter.com/stevebot/status/718185667709267969
> 
> It's pretty clear what's happening if you look here:
> https://review.openstack.org/#/q/owner:openstack-infra%2540lists.openstack.org+status:open
> 
> Here's the drastic step (i'd like to avoid):
> https://review.openstack.org/#/c/303545/
> 
> What do you think?

Is it really worth trying to stop the folks that will game the system?  That is 
a never-ending arms race.

Has anyone ever been made core or had some influence purely by pumping 
stacklytics? I haven’t seen it, since that usually requires personal 
relationships that are far more important than numbers.

Are they using the numbers for some internal company purpose maybe?  If so, how 
does it matter to any of us?

Chasing this tail just takes time away from useful things, IMO.

doug


> 
> Thanks,
> Dims
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu as Octavia Core

[Doug Wiegley]

+1

> On Apr 4, 2016, at 10:53 AM, Adam Harwell  wrote:
> 
> +1
> 
> From: Brandon Logan 
> Sent: Thursday, March 31, 2016 8:04 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Bharath Munirajulu 
> as Octavia Core
> 
> +1
> 
> On Wed, 2016-03-30 at 13:56 -0700, Michael Johnson wrote:
>> I would like to nominate Bharath Munirajulu (bharathm) as a OpenStack
>> Octavia core reviewer.
>> His contributions [1] are in line with other cores and he has been an
>> active member of our community.  I have been impressed with the
>> insight and quality of his reviews.
>> 
>> Current Octavia cores, please vote by replying to this e-mail.
>> 
>> Michael
>> 
>> 
>> [1] http://stackalytics.com/report/contribution/octavia/90
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Doug Wiegley]

+1 (ditto)

> On Apr 8, 2016, at 9:31 AM, Carl Baldwin  wrote:
> 
> +1 (whether my vote counts or note for this area)
> 
> On Thu, Apr 7, 2016 at 10:34 PM, Akihiro Motoki  wrote:
>> Hi Neutrinos,
>> 
>> As the API Lieutenant of Neutron team,
>> I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of
>> Neutron core reviewer team mainly focuing on the API/DB area.
>> 
>> Hirofumi has been contributing neutron actively in the recent two
>> releases constantly.
>> He was involved in key features in API/DB areas in Mitaka such as
>> tagging support and network availability zones.
>> I believe his knowledge and involvement will be great addition to our team.
>> He have been reviewing constantly [1] and I expect he continue to work
>> for Newton or later.
>> 
>> Existing API/DB core reviews (and other Neutron core reviewers),
>> please vote +1/-1 for the addition of Hirofumi to the team.
>> 
>> Thanks!
>> Akihiro
>> 
>> 
>> [1] http://stackalytics.com/report/contribution/neutron/90
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Doug Wiegley]

> On Apr 4, 2016, at 10:37 AM, Armando M.  wrote:
> 
> 
> 
> On 4 April 2016 at 09:22, Ihar Hrachyshka  > wrote:
> Armando M. > wrote:
> 
> 
> 
> On 4 April 2016 at 09:01, Ihar Hrachyshka  > wrote:
> Hi all,
> 
> I noticed that often times we go and -2 all the patches in the review queue 
> on every neutron specific gate breakage spotted. This is allegedly done to 
> make sure that nothing known to be broken land in merge gate until we fix the 
> breakage on our side.
> 
> This is not allegedly done. When I do it, I put a comment next to my action.
> 
> 
> 
> While I share the goal of not resetting the gate if we can avoid it, I find 
> the way we do it a bit too aggressive. Especially considering that often 
> times those -2 votes sit there not cleared even days after the causing 
> breakage is fixed, needlessly blocking patches landing.
> 
> That's a blatant lie: I am aggressive at putting -2s as well as removing 
> them. Other changes for those the -2 stick is probably because they aren't 
> worth the hassle. We've been also in feature freeze so slowing things down 
> should have hurt anyway.
> 
> 
> I suggest we either make sure that we remove those -2 votes right after gate 
> fixes land, or we use other means to communicate to core reviewers that there 
> is a time window when nothing should land in the merge queue.
> 
> Initially I tried sending emails ahead of time alerting for gate breakages, 
> but that doesn't work for obvious reasons: there is a lag that can still be 
> fatal.
> 
> On the specific circumstance, gate broke on Friday late afternoon PDT. It 
> didn't seem that was anything critical worth merging at all cost that 
> couldn't wait until Monday morning and I didn't bother check that things 
> merged safely in the middle of my weekend.
> 
> Yeah, but it’s already up to two working days in some places.
> 
> I hear ya, but I only blocked 6 patches with one +2, none of which were 
> critical, so I really didn't see much of a disruption; that said, I 
> appreciate your note, and I'll be even more cautious next time.
>  
> 
> Note that I don’t mean you should check anything on your weekend. Instead, I 
> think we should avoid -2’s in this case and teach core reviewers to check 
> some source of gate state truth. An email would actually work as long as 
> everyone actively checks it [if for some reason people are not reading 
> openstack-dev@, let’s To: everyone in the group].
> 
> Perhaps we could try using -1, rather than -2, hoping it gets the same level 
> of attention. Having tried the entire past cycle with emails I don't see how 
> they could work at all.

I don’t know, -1 really means, “there is something wrong, the submitter should 
fix it and clear the slate.”  Whereas -2 has two meanings.  The first is 
“procedural block”, and the second is “f*** you.”

I really don’t see a reason not to use the procedural block as a procedural 
block. Are you not trusting the other cores to remove them or something? It’s 
literally what it’s there for.

Thanks,
doug



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

Re: [openstack-dev] [neutron] -2'ing all patches on every gate breakage

[Doug Wiegley]

> On Apr 4, 2016, at 10:22 AM, Ihar Hrachyshka  wrote:
> 
> Armando M.  wrote:
> 
>> 
>> 
>> On 4 April 2016 at 09:01, Ihar Hrachyshka  wrote:
>> Hi all,
>> 
>> I noticed that often times we go and -2 all the patches in the review queue 
>> on every neutron specific gate breakage spotted. This is allegedly done to 
>> make sure that nothing known to be broken land in merge gate until we fix 
>> the breakage on our side.
>> 
>> This is not allegedly done. When I do it, I put a comment next to my action.
>> 
>> 
>> 
>> While I share the goal of not resetting the gate if we can avoid it, I find 
>> the way we do it a bit too aggressive. Especially considering that often 
>> times those -2 votes sit there not cleared even days after the causing 
>> breakage is fixed, needlessly blocking patches landing.
>> 
>> That's a blatant lie: I am aggressive at putting -2s as well as removing 
>> them. Other changes for those the -2 stick is probably because they aren't 
>> worth the hassle. We've been also in feature freeze so slowing things down 
>> should have hurt anyway.
>> 
>> 
>> I suggest we either make sure that we remove those -2 votes right after gate 
>> fixes land, or we use other means to communicate to core reviewers that 
>> there is a time window when nothing should land in the merge queue.
>> 
>> Initially I tried sending emails ahead of time alerting for gate breakages, 
>> but that doesn't work for obvious reasons: there is a lag that can still be 
>> fatal.
>> 
>> On the specific circumstance, gate broke on Friday late afternoon PDT. It 
>> didn't seem that was anything critical worth merging at all cost that 
>> couldn't wait until Monday morning and I didn't bother check that things 
>> merged safely in the middle of my weekend.
> 
> Yeah, but it’s already up to two working days in some places.

Not that -2’s sitting around is good, but what is so urgent that two days 
affects the overall flow of things, and didn’t get escalated?  Review chains 
can address collaboration issues.  Monster syntax churns with lots of conflicts 
get more annoying, but they’re annoying for everyone anyway. The worst part of 
two days with a -2 is the fact that no one will look at it and give feedback 
during that time period, IMO, not that it takes longer to merge.  Velocity is 
about throughput, not latency.

Thanks,
doug


> 
> Note that I don’t mean you should check anything on your weekend. Instead, I 
> think we should avoid -2’s in this case and teach core reviewers to check 
> some source of gate state truth. An email would actually work as long as 
> everyone actively checks it [if for some reason people are not reading 
> openstack-dev@, let’s To: everyone in the group].
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron]: Neutron naming legal issues

[Doug Wiegley]

I vote for “Big Giant Pencil”.  We can call it BGP for short.

doug

> On Apr 1, 2016, at 2:15 PM, Sean M. Collins  wrote:
> 
> I for one, have grown fond of "Mutnauq" while doing the DevStack neutron
> re-write ;)
> 
> 
> -- 
> Sean M. Collins
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

[Doug Wiegley]

;>> isn't a migration script to go from v1 to v2.
>>>>> 
>>>>> Thanks,
>>>>> Kevin
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Stephen Balukoff
>>>>> [sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>]
>>>>> Sent: Wednesday, March 02, 2016 4:49 PM
>>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
>>>>> weready?
>>>>> 
>>>>> I am also on-board with removing LBaaS v1 as early as possible in the 
>>>>> Newton cycle.
>>>>> 
>>>>> On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici 
>>>>> <samu...@radware.com<mailto:samu...@radware.com>> wrote:
>>>>> Thank you all for your response.
>>>>> 
>>>>> In my opinion given that UI/HEAT will make Mitaka and will have one cycle 
>>>>> to mature, it makes sense to remove LBaaS v1 in Newton.
>>>>> Do we want do discuss an upgrade process in the summit?
>>>>> 
>>>>> -Sam.
>>>>> 
>>>>> 
>>>>> From: Bryan Jones
>>>>> [mailto:jone...@us.ibm.com<mailto:jone...@us.ibm.com>]
>>>>> Sent: Wednesday, March 02, 2016 5:54 PM
>>>>> To: 
>>>>> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.opensta
>>>>> c
>>>>> k
>>>>> .org>
>>>>> 
>>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are 
>>>>> weready?
>>>>> 
>>>>> And as for the Heat support, the resources have made Mitaka, with 
>>>>> additional functional tests on the way soon.
>>>>> 
>>>>> blueprint: 
>>>>> https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport
>>>>> gerrit topic: 
>>>>> https://review.openstack.org/#/q/topic:bp/lbaasv2-suport
>>>>> BRYAN M. JONES
>>>>> Software Engineer - OpenStack Development
>>>>> Phone: 1-507-253-2620
>>>>> E-mail: jone...@us.ibm.com<mailto:jone...@us.ibm.com>
>>>>> 
>>>>> 
>>>>> - Original message -
>>>>> From: Justin Pomeroy
>>>>> <jpom...@linux.vnet.ibm.com<mailto:jpom...@linux.vnet.ibm.com>>
>>>>> To: 
>>>>> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.opensta
>>>>> c
>>>>> k
>>>>> .org>
>>>>> Cc:
>>>>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we 
>>>>> ready?
>>>>> Date: Wed, Mar 2, 2016 9:36 AM
>>>>> 
>>>>> As for the horizon support, much of it will make Mitaka.  See the 
>>>>> blueprint and gerrit topic:
>>>>> 
>>>>> https://blueprints.launchpad.net/horizon/+spec/horizon-lbaas-v2-ui
>>>>> https://review.openstack.org/#/q/topic:bp/horizon-lbaas-v2-ui,n,z
>>>>> 
>>>>> - Justin
>>>>> 
>>>>> On 3/2/16 9:22 AM, Doug Wiegley wrote:
>>>>> Hi,
>>>>> 
>>>>> A few things:
>>>>> 
>>>>> - It's not proposed for removal in Mitaka. That patch is for Newton.
>>>>> - HEAT and Horizon are planned for Mitaka (see 
>>>>> neutron-lbaas-dashboard for the latter.)
>>>>> - I don't view this as a "keep or delete" question. If sufficient 
>>>>> folks are interested in maintaining it, there is a third option, 
>>>>> which is that the code can be maintained in a separate repo, by a 
>>>>> separate team (with or without the current core team's blessing.)
>>>>> 
>>>>> No decisions have been made yet, but we are on the cusp of some major 
>>>>> maintenance changes, and two deprecation cycles have passed. Which path 
>>>>> forward is being discussed at today's Octavia meeting, or feedback is of 
>>>>> course welcomed here, in IRC, or anywhere.
>>>>> 
>>>>> Thanks,
>>>>> doug
>>>>> 
>>>>> On Mar 2, 2016, at 7:06 AM, Samuel Bercovici 
>>>>> <samu...@radware.com<mailto:samu...@radware.com>> wrote:
>>>&

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

[Doug Wiegley]

> On Mar 21, 2016, at 5:40 AM, Ihar Hrachyshka  wrote:
> 
> Sean M. Collins  wrote:
> 
>> Rossella Sblendido wrote:
>>> 2) multi-node jobs run for every patch set. Is that really what we want?
>>> They take pretty long. We could move them to a periodic job.
>> 
>> I would rather remove all the single-node jobs. Nova has been moving to
>> multinode jobs for their gate (if I recall correctly my
>> conversation with Dan Smith) and we should be moving in this direction
>> too. We should test Neutron the way it is deployed in production.
>> 
>> Also, who is really monitoring the periodic jobs? Truthfully? I know
>> there are some IPv6 jobs that are periodic and I'll be the first to
>> admit that I am not following them *at all*.
> 
> Well, stable maintainers track their periodic job failures. :) Email 
> notifications when something starts failing help.
> 
>> 
>> So, my thinking is, unless it's running at the gate and inflicting pain
>> on people, it's not going to be a treated as a priority. Look at Linux
>> Bridge - serious race conditions that existed for years only
>> got fixed once I inflicted pain on all the Neutron devs by making it
>> voting and running on every patchset (sorry, not sorry).
> 
> I think there is still common ground between you and Rossella’s stances: the 
> fact that we want to inflict gating pain does not mean that we want to 
> execute every single job on each PS uploaded to gerrit. For some advanced and 
> non-obvious checks [like partial grenade] the validation could be probably 
> postponed till the patch hits the gate.
> 
> Yes, sometimes it will mean gate being reset due to the bad patch. This can 
> be avoided in most of cases if reviewers and the author for a patch that 
> potentially touches a specific scenario execute the jobs before hitting the 
> gate with the patch [for example, if the job is in experimental set, it’s a 
> matter of ‘check experimental’ before pressing W+1].

We have been pretty consciously moving neutron jobs to cause pain to *neutron* 
and not everyone else, which is the opposite of a “gate only” plan. Aside from 
that being against infra policy, I think I’m reading between the lines that 
folks are wanting faster iterations between patchsets. I note that the standard 
-full job is up to 55-65 minutes, from it’s old time of 40-45. Have we 
characterized why that’s so much slower now? Perhaps addressing that will bring 
down to the turn-around for all.

Thanks,
doug


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


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

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

[Doug Wiegley]

> On Mar 18, 2016, at 4:01 AM, Ihar Hrachyshka  wrote:
> 
> Hi all,
> 
> Just giving my fellows an update from the event where we gathered our 
> upgrades subteam to plan for Newton and do some coding.
> 
> ==
> 
> We had folks from multiple companies participating in the event (Red Hat, 
> SuSE, Intel, IBM). We also had some folks joining us online. Thanks everyone 
> who gave us a hand at these days!
> 
> For the most part, we were working on the plan to adopt versioned objects for 
> neutron db codebase. Just in case someone is not aware about the end goal for 
> the effort: we want to eventually get to the point where you can upgrade your 
> neutron-server processes between major releases without shutting all of them 
> down to run database migration scripts. [There are other applications for 
> objects, but that’s currently out of immediate scope for the N effort.]

What is the plan for out of tree objects derived from neutron, and out of tree 
projects that are using the current neutron objects?  Specifically, the ones 
which *can’t* use the REST API, because they’re for something loaded directly 
into neutron-server (core plugins, service plugins, etc). Will they work?  Is 
our live upgrade strategy going to be labeled “reference only”?

doug


> 
> Long story short, the current plan of the team for the near future is:
> 
> - N: provide objects for all major neutron resources;
> - N: get most if not all the db code in neutron repo switched to using 
> objects;
> - N: start using objects to handle database live data migration (aka 
> ‘contract’ scripts);
> - start of O: forbid contract alembic scripts;
> - O and beyond: introduce gating for HA neutron-servers; complete objects 
> adoption; look into utilizing objects for plugin API; API version pinning; ...
> 
> If all goes well, this plan should allow ops to upgrade Newton neutron-server 
> to O without API endpoint downtime.
> 
> ==
> 
> We also discussed current gating for upgrades. The plan for that would be 
> getting the current l3 legacy job voting next weeks; adding dvr flavor into 
> check queue (non-voting); get voting for the latter (probably while removing 
> the former from check gate).
> 
> There are still some things to improve in multinode grenade that we have.
> 
> One thing is that we should look into running dvr tests for dvr flavour of 
> the job. Though there are some dvr tests in tempest, they are not tagged as 
> smoke, and hence are not executed in the job. Also, as per Assaf, those dvr 
> tests go away from tempest middle term, leaving just tests inside neutron 
> tree. So we should come up with some way to run dvr tests that are maintained 
> inside neutron tree. One way is utilizing a tempest plugin (there is a patch 
> for review for that).
> 
> Another thing we may want to consider is moving some more services into ‘old’ 
> node of the multinode setup. Specifically, dhcp and l3 agent (even for l3 
> legacy job). There are questions though whether we would then effectively 
> hide some potential places to break (due to external-to-internal routing not 
> leaving the node, or no tunneling needed between l3/dhcp and instances). So 
> it may require introducing a separate ‘networking’ node in the multinode 
> setup to host l3/dhcp agents there.
> 
> ==
> 
> We realize that subteam plans are not well known to other community members. 
> We will work on raising awareness about use cases and features we target for 
> next releases. That will include posting proper ‘ops oriented’ RFEs, working 
> on documentation (devref as well as networking-guide), etc.
> 
> One thing that we discussed on the event is updating networking-guide with 
> detailed description of the upgrade process for neutron. We already have some 
> pieces scattered there [f.e. we have some coverage for neutron-db-manage 
> tool] but it’s nothing complete or deep enough. That’s something we will look 
> into improving at the start of the N cycle.
> 
> ==
> 
> As for actual coding, we focused on objects. We track the effort using ‘ovo’ 
> topic in gerrit:
> 
> https://review.openstack.org/#/q/topic:ovo
> 
> We landed some patches already, and we will land a lot more in the next 
> months. Reviews from outside the subteam are highly appreciated. If anything, 
> you may learn something new. :)
> 
> ==
> 
> It was the second time we organized a highly focused sprint for Neutron (the 
> previous one was on QoS during Liberty cycle). I hope we as a community start 
> learning how to manage those events more effectively. I would be glad to talk 
> about how the events go, what are the obstacles and mistakes we make along 
> the line, if anything cares to hear. :) For example, the timing that we chose 
> for this event this time was really unfortunate, and that slowed down some 
> progress. Still, we are in a better shape coding wise as well as being on the 
> same page for the upcoming work for the next 6 months.
> 
> ==
> 
> All in all, it was a 

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Doug Wiegley]

> On Mar 18, 2016, at 8:31 AM, Cory Benfield <c...@lukasa.co.uk> wrote:
> 
>> 
>> On 18 Mar 2016, at 13:57, Brian Haley <brian.ha...@hpe.com> wrote:
>> 
>> On 03/17/2016 06:04 PM, Doug Wiegley wrote:
>>>>> Here is the non comprehensive list of usages based on what trees I
>>>>> happen to have checked out (which is quite a few, but not all of
>>>>> OpenStack for sure).
>>>>> 
>>>>> I think before deciding to take over ownership of an upstream lib (which
>>>>> is a large commitment over space and time), we should figure out the
>>>>> migration cost. All the uses in Tempest come from usage in Glance IIRC
>>>>> (and dealing with chunked encoding).
>>>>> 
>>>>> Neutron seems to use it for a couple of proxies, but that seems like
>>>>> requests/urllib3 might be sufficient.
>>>> 
>>>> The Neutron team should talk to Cory Benfield (CC'd) and myself more about 
>>>> this if they run into problems. requests and urllib3 are a little limited 
>>>> with respect to proxies due to limitations in httplib itself.
>>>> 
>>>> Both of us might be able to dedicate time during the day to fix this if 
>>>> Neutron/OpenStack have specific requirements that requests is not 
>>>> currently capable of supporting.
>>> 
>>> Looks like neutron is using it to do HTTP requests via unix domain sockets. 
>>> Unless I’m missing something, requests doesn’t support that directly. There 
>>> are a couple of other libs that do, or we could monkey patch the socket. Or 
>>> modify the agents to use localhost.
>> 
>> We have to use Unix domain sockets in the metadata proxy because it's 
>> running in a namespace, so can't use localhost to talk to the agent.  But we 
>> could use some other library of course.
>> 
> 
> Getting requests to talk over a Unix domain socket is not particularly 
> tricky, and there are third-party libraries that hook into requests 
> appropriately to make that happen. For example, the requests-unixsocket 
> module exists that can do the appropriate things.

That’s the module that I was eyeing, but we’re just trading one dependency for 
another. Is there something about httplib2 maintenance in particular that makes 
us want that gone?

doug


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


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

Re: [openstack-dev] [all] Maintaining httplib2 python library

[Doug Wiegley]

> On Mar 14, 2016, at 8:51 AM, Ian Cordasco  wrote:
> 
> -Original Message-
> From: Sean Dague 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: March 14, 2016 at 09:41:02
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library
> 
>> On 03/14/2016 10:24 AM, Ian Cordasco wrote:
>>> 
>>> 
>>> -Original Message-
>>> From: Davanum Srinivas  
>>> Reply: OpenStack Development Mailing List (not for usage questions)  
>>> Date: March 14, 2016 at 09:18:50
>>> To: OpenStack Development Mailing List (not for usage questions)  
>>> Subject: [openstack-dev] [all] Maintaining httplib2 python library
>>> 
 Team,
 
 fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2
 
 We have httplib2 in our global requirements and lots of projects are
 using it[1]. Is there anyone willing to step up?
>>> 
>>> Is it really worth our time to dedicate extra resources to that? Glance has 
>>> been discussing  
>> (but it's been a low priority) to switing all our dependence on httplib2 to 
>> requests (and  
>> maybe urllib3 directly) as necessary.
>>> 
>>> We have other tools and libraries we can use without taking over 
>>> maintenance of yet another  
>> library.
>>> 
>>> I think the better question than "Can people please maintain this for the 
>>> community?"  
>> is "What benefits does httplib2 have over something that is actively 
>> maintained (and  
>> has been actively maintaiend) like urllib3, requests, etc.?"
>>> 
>>> And then we can (and should) also ask "Why have we been using this? How 
>>> much work do cores  
>> think it would be to remove this from our global requirements?"
>> 
>> +1.
>> 
>> Here is the non comprehensive list of usages based on what trees I
>> happen to have checked out (which is quite a few, but not all of
>> OpenStack for sure).
>> 
>> I think before deciding to take over ownership of an upstream lib (which
>> is a large commitment over space and time), we should figure out the
>> migration cost. All the uses in Tempest come from usage in Glance IIRC
>> (and dealing with chunked encoding).
>> 
>> Neutron seems to use it for a couple of proxies, but that seems like
>> requests/urllib3 might be sufficient.
> 
> The Neutron team should talk to Cory Benfield (CC'd) and myself more about 
> this if they run into problems. requests and urllib3 are a little limited 
> with respect to proxies due to limitations in httplib itself.
> 
> Both of us might be able to dedicate time during the day to fix this if 
> Neutron/OpenStack have specific requirements that requests is not currently 
> capable of supporting.

Looks like neutron is using it to do HTTP requests via unix domain sockets. 
Unless I’m missing something, requests doesn’t support that directly. There are 
a couple of other libs that do, or we could monkey patch the socket. Or modify 
the agents to use localhost.

doug


>  
>> I suspect Glance is really the lynchpin here (as it actually does some
>> low level stuff with it). If there can be a Glance plan to get off of
>> it, the rest can follow pretty easily.
> 
> I'm in a meeting right now, but I think I will be able to lead a spike to get 
> Glance off of this if the rest of the Glance team is okay with it.
> 
> --  
> Ian Cordasco
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] [neutron-lib] adding a new flag to neutron-lib

[Doug Wiegley]

tl;dr is, if you need a new constant/method/whatnot quickly, it should go into 
*neutron*, not *neutron-lib*.

The lib is meant to be for stable interfaces that are being used in more than 
one place. As such, I don’t think it should be the first stop for anything, nor 
should you ever set yourself up to wait for a change there. The lib is meant to 
encapsulate stable interfaces, but not to slow down neutron development. The 
general procedure that was envisioned is:

1. Make your change in neutron. ALL of it. If it’s a “common” routing, put it 
in a common place in neutron.  neutron-lib is NOT meant to replace the neutron 
repo having common utilities of its own.
2. If another project/repo needs that change, then propose it to the lib.
3. At some point it’ll merge and then be released, which will lag, on purpose.
4. Make the change in neutron to use the lib code, or file a bug for a lib 
maintainer to take care of it.

You can invert steps 3 and 4, it just won’t merge until the code is released on 
pypi.

You should *NOT* put yourself in a position where you need code to land and 
merge in neutron-lib before you can continue with neutron work. That is not 
what it’s meant for, and will slow people down too much, even if reviews in the 
lib happened at a lightning pace. And they shouldn’t, because rushing and 
deadlines lead to sloppy interfaces.

Now, all that said, there is an experimental job that builds neutron against 
lib master instead of pypi, that you can use to make sure changes work there if 
you wish. Couple that with Depends-On to get the test behavior requested.  But, 
please, don't get yourself into a position where that is blocking.

doug


> On Mar 14, 2016, at 12:01 PM, Assaf Muller  wrote:
> 
> On Mon, Mar 14, 2016 at 1:27 PM, Gary Kotton  wrote:
>> Hi,
>> It would be nice if we could get a little more reviews in the neutron-lib.
>> I think that we should maybe strive to cut a new version prior to the
>> release.
>> Thanks
>> Gary
>> 
>> On 3/14/16, 6:17 PM, "Venkata Anil"  wrote:
>> 
>>> Hi All
>>> 
>>> I have added a new flag in neutron-lib
>>> https://review.openstack.org/#/c/291641/3/neutron_lib/constants.py
>>> and wanted to use that flag in neutron's change
>>> https://review.openstack.org/#/c/291651/
>>> How to add the dependency?
>>> 
>>> I added neutron-lib change in neutron's change as "Depends-On:" in
>>> commit message.
>>> Also added the change suggested in
>>> https://wiki.openstack.org/wiki/Neutron/Lib as  "Depends-On:" in commit
>>> message. But still neutron change is not resolving the flag added in
>>> neutron-lib.
> 
> On a somewhat related note, I'd love to pick the brains of the people
> involved as for why a separate repo was chosen over placing the code
> in the main Neutron repo (Under say, neutron.lib). It would mean
> easier/faster movement of code in to the lib, thus faster velocity and
> adoption. As it is, it requires 1 patch to move something in to
> neutron_lib (With a debtcollector), releasing a new version of it to
> PyPi, then another patch to use the code in Neutron. The Tempest
> community moved from tempest_lib to tempest.lib very recently, but I
> don't know all of the motivations behind that move, I can imagine the
> reason I stated above was also on their minds.
> 
>>> 
>>> Thanks
>>> Anil
>>> 
>>> 
>>> 
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron]Where did the flows go in ovs bridge?

[Doug Wiegley]

Take a look in /var/log/neutron/openvswitch-agent.log, or similar, on the 
hypervisor. 

Doug


> On Mar 12, 2016, at 6:54 PM, Zhi Chang  wrote:
> 
> hi, guys.
> 
> I deployed DVR in my local environment by following  this 
> document(https://wiki.openstack.org/wiki/Neutron/DVR).  And I have three 
> compute nodes which running DVR l3-agent and two network nodes which running 
> DVR_SNAT l3-agent.
> 
> I created a vm in one of the computes nodes. And flows was generated 
> normally. But, all flows are gone when I  restart 
> "neutron-openvswitch-agent"!. I wait a few minutes but I can't see any flows 
> were generated. 
> 
> Could someone tell me why the flows are gone and they can't generated 
> anymore?
> 
> 
> Thanks
> Zhi Chang
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

[Doug Wiegley]

The cleanup was my fault. I had removed folks that were added initially just 
for the initial *aas split. Welcome back.  :-)

Thanks,
doug

> On Mar 10, 2016, at 2:33 AM, Ihar Hrachyshka  wrote:
> 
> Sean M. Collins  wrote:
> 
>> I probably speak for all FwaaS cores when I say - "Welcome!”
> 
> …back! Thanks.
> 
>> 
>> Frankly I had just assumed he had core privileges for our repo anyway
>> via an inherited ACL.
> 
> Full disclosure: I had all -*aas core privileges before [not thru inherited 
> ACLs though]. It’s just that lately I lost some of them, probably due to some 
> cleanup.
> 
> To all: it’s not my plan to abuse the powers for anything that is not 
> required for general success of the current stadium. If I ever decide to get 
> more involved into a specific *-aas subproject strategically, I will get back 
> to the corresponding *-aas team for additional approval before I use the 
> powers for anything beyond those immediate goals set by PTL.
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

[Doug Wiegley]

Hi,

A few things:

- It’s not proposed for removal in Mitaka. That patch is for Newton.
- HEAT and Horizon are planned for Mitaka (see neutron-lbaas-dashboard for the 
latter.)
- I don’t view this as a “keep or delete” question. If sufficient folks are 
interested in maintaining it, there is a third option, which is that the code 
can be maintained in a separate repo, by a separate team (with or without the 
current core team’s blessing.)

No decisions have been made yet, but we are on the cusp of some major 
maintenance changes, and two deprecation cycles have passed. Which path forward 
is being discussed at today’s Octavia meeting, or feedback is of course 
welcomed here, in IRC, or anywhere.

Thanks,
doug

> On Mar 2, 2016, at 7:06 AM, Samuel Bercovici  wrote:
> 
> Hi,
>  
> I have just notices the following change: 
> https://review.openstack.org/#/c/286381 
>  which aims to remove LBaaS v1.
> Is this planned for Mitaka or for Newton?
>  
> While LBaaS v2 is becoming the default, I think that we should have the 
> following before we replace LBaaS v1:
> 1.  Horizon Support – was not able to find any real activity on it
> 2.  HEAT Support – will it be ready in Mitaka?
>  
> Do you have any other items that are needed before we get rid of LBaaS v1?
>  
> -Sam.
>  
>  
>  
>  
>  
>  
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Gate failure

[Doug Wiegley]

This has merged, so you can resume your previously scheduled 
mad-merge-for-Mitaka and break it all again.

Thanks,
doug

> On Feb 25, 2016, at 2:46 PM, Armando M.  wrote:
> 
> Folks,
> 
> The API job recent breakage prevents us from merging code. Please refrain 
> from pushing patches to the merge queue until [1] completes going through the 
> pipeline.
> 
> A.
> 
> [1] https://review.openstack.org/#/c/284911/ 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

[Doug Wiegley]

> On Feb 21, 2016, at 10:38 AM, Steven Dake (stdake)  wrote:
> 
> Armando,
> 
> I apologize if neutron does not have a limit of 2 core reviewers per company 
> – I had heard this through the grapevine but a google search of the mailing 
> list shows no such limitation.

It goes back to what Armando mentioned. If I don’t trust my fellow core 
reviewers, for *whatever reason*, we have much bigger problems than company 
affiliation.

I was told when I joined that the same company shouldn’t +2/+2/+A, which I 
follow, but even then, it’s a judgement call. I mean, who cares if the same 
company merges proposal bot? I certainly don’t. Nor would I think ill of it 
even for a second for a gate fix or the like.

It’s usually pretty obvious when one entity is trying to shove something in to 
the detriment of the project. And I’d rather just have a conversation with 
those folks at the time, and deal with the social problem, rather than trying 
to pass a million bureaucratic rules to cover every what-if. It’s not that I 
like having difficult conversations; I just like a world with a million little 
rules even less.

doug


> 
> Regards
> -steve
> 
> 
> From: "Armando M." >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Sunday, February 21, 2016 at 9:38 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer 
> limitations by company
> 
> 
> 
> On 20 February 2016 at 12:58, Steven Dake (stdake)  > wrote:
> Neutron, the largest project in OpenStack by active committers and reviewers 
> as measured by the governance repository teamstats tool, has a limit of 2 
> core reviewers per company.  They do that for a reason.  I expect Kolla will 
> grow over time (we are about 1/4 their size in terms of contributors and 
> reviewers).  I believe other projects follow a similar pattern besides 
> Neutron that already have good diversity (and intend to keep it in place).
> 
> Where did you find this information? I do not believe this is true. I agree 
> wholeheartedly with Joshua: I personally value the judgement of the people I 
> trust rather than looking at affiliation. 
>  
> 
> Regards
> -steve
> 
> 
> From: Gal Sagie >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Saturday, February 20, 2016 at 10:38 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer 
> limitations by company
> 
> I think setting these limits is wrong, some companies have more overall 
> representation then others.
> The core reviewer job should be on a personal basis and not on a company 
> basis, i think the PTL of each project needs
> to make sure the diversity and the community voice is heard in each project 
> and the correct path is taken even if
> many (or even if all) of the cores are from the same company.
> If you really want to set limits then i would go with something like 2 cores 
> from the same company cannot +2 the same patch, but 
> again i am against such things personally..
> 
> Disclaimer: i am not personally involved in Kolla or know how things are 
> running there.
> 
> On Sat, Feb 20, 2016 at 7:09 PM, Steven Dake (stdake)  > wrote:
> Hey folks,
> 
> Mirantis has been developing a big footprint in the core review team, and Red 
> Hat already has a big footprint in the core review team.  These are all good 
> things, but I want to avoid in the future a situation in which one company 
> has a majority of core reviewers.  Since core reviewers set policy for the 
> project, the project could be harmed if one company has such a majority.  
> This is one reason why project diversity is so important and has its own 
> special snowflake tag in the governance repository.
> 
> I'd like your thoughts on how to best handle this situation, before I trigger 
>  a vote we can all agree on.
> 
> I was thinking of something simple like:
> "1 company may not have more then 33% of core reviewers.  At the conclusion 
> of PTL elections, the current cycle's 6 months of reviews completed will be 
> used as a metric to select the core reviewers from that particular company if 
> the core review team has shrunk as a result of removal of core reviewers 
> during the cycle."
> 
> Thoughts, comments, questions, concerns, etc?
> 
> Regards,
> -steve
> 
> 
> 

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

[Doug Wiegley]

Hi all,

I automated a non-dashboard version of Rossella’s script.

The tweaked script that gets run:

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

Results, updated hourly (bookmarkable, will redirect to gerrit):

http://104.236.79.17/
http://104.236.79.17/current
http://104.236.79.17/current-min

Thanks,
doug


> On Feb 16, 2016, at 2:52 PM, Carl Baldwin  wrote:
> 
> Could this be done by creating a project dashboard [1]?  I think the
> one thing that prevents using such a dashboard is that your script
> generates a dashboard that crosses multiple projects.  So, we'd be
> stuck with multiple dashboards, one per project.
> 
> The nature of your script is to create a new URL reflecting the
> current state of things each time it is run.  But, it would be nice if
> it were bookmark-able.  These seem to conflict.
> 
> Would it be possible have a way to create a URL which would return a
> "307 Temporary Redirect" to the URL of the day?  It could be
> bookmarked and redirect to the latest URL of the day.
> 
> Another idea is a page with a frame or something so that the permanent
> URL stays in the browser bar.  I think I've seen web pages redirect
> this way before.
> 
> Or, we could not do the fancy stuff and just have a link on a wiki or 
> something.
> 
> No matter how it is done, there is the problem of where to host such a
> page which can be automatically updated daily (or more often) by this
> script.
> 
> Any thoughts from infra on this?
> 
> Carl
> 
> [1] 
> https://gerrit-review.googlesource.com/Documentation/user-dashboards.html#project-dashboards
> 
> On Fri, Feb 12, 2016 at 10:12 AM, Rossella Sblendido
>  wrote:
>> 
>> 
>> On 02/12/2016 12:25 PM, Rossella Sblendido wrote:
>>> 
>>> Hi all,
>>> 
>>> it's hard sometimes for reviewers to filter reviews that are high
>>> priority. In Neutron in this mail thread [1] we had the idea to create a
>>> script for that. The script is now available in the Neutron repository
>>> [2].
>>> The script queries Launchpad and creates a file that can be used by
>>> gerrit-dash-creator to display a dashboard listing patches that fix
>>> critical/high bugs, that implement approved blueprint or feature
>>> requests. This is how it looks like today [3].
>>> For it to be really useful the dashboard link needs to be updated once a
>>> day at least. Here I need your help. I'd like to publish the URL in a
>>> public place and update it every day in an automated way. How can I do
>>> that?
>>> 
>>> thanks,
>>> 
>>> Rossella
>>> 
>>> [1]
>>> 
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-November/079816.html
>>> 
>>> [2]
>>> 
>>> https://github.com/openstack/neutron/blob/master/tools/milestone-review-dash.py
>>> 
>>> [3] https://goo.gl/FSKTj9
>> 
>> 
>> This last link is wrong, this is the right one [1] sorry.
>> 
>> [1] https://goo.gl/Hb3vKu
>> 
>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Octavia (LBaaS) license question

[Doug Wiegley]

It’s a binary dependency with no code modification.  According to 
http://governance.openstack.org/reference/licensing.html 
, it should be fine, 
unless I’m mistaken.

Thanks,
doug


> On Feb 13, 2016, at 11:46 PM, Gal Sagie  wrote:
> 
> Hello All,
> 
> I recently started looking at Octavia and i noticed it uses HAProxy as its 
> reference
> implementation.
> I also noticed that HAProxy is GPL license so i am wondering how is this 
> working?
> 
> Just interested to know if there is a special exemption ?
> 
> Thanks
> Gal.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Doug Wiegley]

> On Feb 12, 2016, at 12:03 PM, Matt Riedemann  
> wrote:
> 
> 
> 
> On 2/12/2016 12:45 PM, John Garbutt wrote:
>> On 12 February 2016 at 18:17, Andrew Laski  wrote:
>>> 
>>> 
>>> On Fri, Feb 12, 2016, at 12:15 PM, Matt Riedemann wrote:
 Forgive me for thinking out loud, but I'm trying to sort out how nova
 would use a microversion in the nova API for the get-me-a-network
 feature recently added to neutron [1] and planned to be leveraged in
 nova (there isn't a spec yet for nova, I'm trying to sort this out for a
 draft).
 
 Originally I was thinking that a network is required for nova boot, so
 we'd simply check for a microversion and allow not specifying a network,
 easy peasy.
 
 Turns out you can boot an instance in nova (with neutron as the network
 backend) without a network. All you get is a measly debug log message in
 the compute logs [2]. That's kind of useless though and seems silly.
 
 I haven't tested this out yet to confirm, but I suspect that if you
 create a nova instance w/o a network, you can latter try to attach a
 network using the os-attach-interfaces API as long as you either provide
 a network ID *or* there is a public shared network or the tenant has a
 network at that point (nova looks those up if a specific network ID
 isn't provided).
 
 The high-level plan for get-me-a-network in nova was simply going to be
 if the user tries to boot an instance and doesn't provide a network, and
 there isn't a tenant network or public shared network to default to,
 then nova would call neutron's new auto-allocated-topology API to get a
 network. This, however, is a behavior change.
 
 So I guess the question now is how do we handle that behavior change in
 the nova API?
 
 We could add an auto-create-net boolean to the boot server request which
 would only be available in a microversion, then we could check that
 boolean in the compute API when we're doing network validation.
 
>>> 
>>> I think a flag like this is the right approach. If it's currently valid
>>> to boot an instance without a network than there needs to be something
>>> to distinguish a request that wants a network created vs. a request that
>>> doesn't want a network.
>>> 
>>> This is still hugely useful if all that's required from a user is to
>>> indicate that they would like a network, they still don't need to
>>> understand/provide details of the network.
>> 
>> I was thinking a sort of opposite. Would this work?
>> 
>> We add a new micro-version that does this:
>> * nothing specified: do the best we can to get a port created
>> (get-me-a-network, etc,), or fail if not possible
>> * --no-nics option (or similar) that says "please don't give me any nics"
>> 
>> This means folks that don't want a network, reliably have a way to do
>> that. For everyone else, we do the same thing when using either
>> neutron or nova-network VLAN manager.
>> 
>> Thanks,
>> johnthetubaguy
>> 
>> PS
>> I think we should focus on the horizon experience, CLI experience, and
>> API experience separately, for a moment, to make sure each of those
>> cases actually works out OK.
>> 
 Today if you don't specify a network and don't have a network available,
 then the validation in the API is basically just quota checking that you
 can get at least one port in your tenant [3]. With a flag on a
 microversion, we could also validate some other things about
 auto-creating a network (if we know that's going to be the case once we
 hit the compute).
 
 Anyway, this is mostly me getting thoughts out of my head before the
 weekend so I don't forget it and am looking for other ideas here or
 things I might be missing.
 
 [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
 [2]
 https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
 [3]
 https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
 
 --
 
 Thanks,
 
 Matt Riedemann
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __
>> OpenStack Development Mailing List (not for 

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

[Doug Wiegley]

> On Feb 12, 2016, at 2:15 PM, Andrew Laski <and...@lascii.com> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
>> gives it one nic with an IP, right?
>> 
>> So how is this changing that behavior? Making it harder to use, for the
>> sake of preserving a really unusual corner case (no net with neutron),
>> seems a much worse user experience here.
> 
> I was just going off of the behavior Matt described, that it was
> possible to boot with no network by leaving that out of the request. If
> the behavior already differs based on what networking backend is in use
> then we've put users in a bad spot, and IMO furthers my case for having
> explicit parameters in the request. I'm really not seeing how "--nic
> auto|none" is any harder than leaving all network related parameters off
> of the boot request, and it avoids potential confusion as to what will
> happen.

It hurts discoverability, and “expectedness”. If I’m new to openstack, having 
it default boot unusable just means the first time I use ’nova boot’, I’ll end 
up with a useless VM. People don’t read docs first, it should “just work” as 
far as that’s sane. And OpenStack has a LOT of these little annoyances for the 
sake of strict correctness while optimizing for an unusual or rare case.

The original stated goal of this simpler neutron api was to get back to the 
simpler nova boot. I’d like to see that happen.

Thanks,
doug

> 
>> 
>> Thanks,
>> doug
>> 
>> 
>>> On Feb 12, 2016, at 1:51 PM, Ed Leafe <e...@leafe.com> wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>> 
>>> On 02/12/2016 02:41 PM, Andrew Laski wrote:
>>> 
>>>>> I think if the point of the experience for this API is to be
>>>>> working out
>>>>>> of the box. So I very much like the idea of a defaults change
>>>>>> here to the thing we want to be easy. And an explicit option to
>>>>>> disable it if you want to do something more complicated.
>>> 
>>>> I think this creates a potential for confusing behavior for users. 
>>>> They're happily booting instances with no network on 2.1, as silly
>>>> as that might be, and then decide "ooh I'd like to use fancy new
>>>> flag foo which is available in 2.35". So they add the flag to their
>>>> request and set the version to 2.35 and suddenly multiple things
>>>> change about their boot process because they missed that 2.24(or
>>>> whatever) changed a default behavior. If this fits within the scope
>>>> of microversions then users will need to expect that, but it's
>>>> something that would be likely to trip me up as a user of the API.
>>> 
>>> I agree - that's always been the trade-off with microversions. You
>>> never get surprises, but you can't move to a new feature in 2.X
>>> without also having to get everything that was also introduced in
>>> 2.X-1 and before. The benefit, of course, is that the user will have
>>> changed something explicitly before getting the new behavior, and at
>>> least has a chance of figuring it out.
>>> 
>>> - -- 
>>> 
>>> - -- Ed Leafe
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>> Comment: GPGTools - https://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>> 
>>> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
>>> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
>>> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
>>> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
>>> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
>>> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
>>> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
>>> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
>>> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
>>> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
>>> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
>>> GcPgzIoclwLrVooRqOSf
>>> =Dqga
>>> -END PGP SIGNATURE-
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openst

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

[Doug Wiegley]

Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically gives it 
one nic with an IP, right?

So how is this changing that behavior? Making it harder to use, for the sake of 
preserving a really unusual corner case (no net with neutron), seems a much 
worse user experience here.

Thanks,
doug


> On Feb 12, 2016, at 1:51 PM, Ed Leafe  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/12/2016 02:41 PM, Andrew Laski wrote:
> 
>>> I think if the point of the experience for this API is to be
>>> working out
 of the box. So I very much like the idea of a defaults change
 here to the thing we want to be easy. And an explicit option to
 disable it if you want to do something more complicated.
> 
>> I think this creates a potential for confusing behavior for users. 
>> They're happily booting instances with no network on 2.1, as silly
>> as that might be, and then decide "ooh I'd like to use fancy new
>> flag foo which is available in 2.35". So they add the flag to their
>> request and set the version to 2.35 and suddenly multiple things
>> change about their boot process because they missed that 2.24(or
>> whatever) changed a default behavior. If this fits within the scope
>> of microversions then users will need to expect that, but it's
>> something that would be likely to trip me up as a user of the API.
> 
> I agree - that's always been the trade-off with microversions. You
> never get surprises, but you can't move to a new feature in 2.X
> without also having to get everything that was also introduced in
> 2.X-1 and before. The benefit, of course, is that the user will have
> changed something explicitly before getting the new behavior, and at
> least has a chance of figuring it out.
> 
> - -- 
> 
> - -- Ed Leafe
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/
> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw
> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t
> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA
> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3
> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh
> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM
> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO
> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx
> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll
> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9
> GcPgzIoclwLrVooRqOSf
> =Dqga
> -END PGP SIGNATURE-
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

[Doug Wiegley]

> On Feb 12, 2016, at 3:17 PM, Andrew Laski <and...@lascii.com> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
>> 
>>> On Feb 12, 2016, at 2:15 PM, Andrew Laski <and...@lascii.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>>>> Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically
>>>> gives it one nic with an IP, right?
>>>> 
>>>> So how is this changing that behavior? Making it harder to use, for the
>>>> sake of preserving a really unusual corner case (no net with neutron),
>>>> seems a much worse user experience here.
>>> 
>>> I was just going off of the behavior Matt described, that it was
>>> possible to boot with no network by leaving that out of the request. If
>>> the behavior already differs based on what networking backend is in use
>>> then we've put users in a bad spot, and IMO furthers my case for having
>>> explicit parameters in the request. I'm really not seeing how "--nic
>>> auto|none" is any harder than leaving all network related parameters off
>>> of the boot request, and it avoids potential confusion as to what will
>>> happen.
>> 
>> It hurts discoverability, and “expectedness”. If I’m new to openstack,
>> having it default boot unusable just means the first time I use ’nova
>> boot’, I’ll end up with a useless VM. People don’t read docs first, it
>> should “just work” as far as that’s sane. And OpenStack has a LOT of
>> these little annoyances for the sake of strict correctness while
>> optimizing for an unusual or rare case.
>> 
>> The original stated goal of this simpler neutron api was to get back to
>> the simpler nova boot. I’d like to see that happen.
> 
> I'm not suggesting that the default boot be unusable. I'm saying that
> just like it's required to pass in a flavor and image/volume to boot an
> instance why not require the user to specify something about the
> network. And that network request can be as simple as specifying "auto"
> or "none". That seems to meet all of the requirements without the
> confusion of needing to guess what the default behavior will be when
> it's left off because it can apparently mean different things based on
> which backed is in use. For users that don't read the docs they'll get
> an immediate failure response indicating that they need to specify
> something about the network versus the current and proposed state where
> it's not clear what will happen unless they've read the docs on
> microversions and understand which network service is being used.

I understand what you’re saying, and we’re almost down to style here. We have 
the previous nova-net ‘nova boot’ behavior, plus I think a VM with a network is 
kinda nonsensical, so adding that hoop for the default case doesn’t make sense 
to me. I’m not sure we’ll convince each other here, and that’s ok, I’ve said my 
peace.  :-)

Thanks,
doug

> 
>> 
>> Thanks,
>> doug
>> 
>>> 
>>>> 
>>>> Thanks,
>>>> doug
>>>> 
>>>> 
>>>>> On Feb 12, 2016, at 1:51 PM, Ed Leafe <e...@leafe.com> wrote:
>>>>> 
>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>> Hash: SHA512
>>>>> 
>>>>> On 02/12/2016 02:41 PM, Andrew Laski wrote:
>>>>> 
>>>>>>> I think if the point of the experience for this API is to be
>>>>>>> working out
>>>>>>>> of the box. So I very much like the idea of a defaults change
>>>>>>>> here to the thing we want to be easy. And an explicit option to
>>>>>>>> disable it if you want to do something more complicated.
>>>>> 
>>>>>> I think this creates a potential for confusing behavior for users. 
>>>>>> They're happily booting instances with no network on 2.1, as silly
>>>>>> as that might be, and then decide "ooh I'd like to use fancy new
>>>>>> flag foo which is available in 2.35". So they add the flag to their
>>>>>> request and set the version to 2.35 and suddenly multiple things
>>>>>> change about their boot process because they missed that 2.24(or
>>>>>> whatever) changed a default behavior. If this fits within the scope
>>>>>> of microversions then users will need to expect that, but it's
>>>>>> something that would be likely to trip me up as a user of t

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Doug Wiegley]

+1

Doug


> On Feb 4, 2016, at 7:06 PM, Brandon Logan  wrote:
> 
> +1
> 
>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
>> +1 from me!
>> 
>> From: Michael Johnson 
>> Sent: Thursday, February 4, 2016 7:03 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
>> Octavia Core
>> 
>> Octavia Team,
>> 
>> I would like to nominate Stephen Balukoff as a core reviewer for the
>> OpenStack Octavia project.  His contributions[1] are in line with
>> other cores and he has been an active member of our community.
>> 
>> Octavia cores please vote by replying to this e-mail.
>> 
>> Michael
>> 
>> [1] http://stackalytics.com/report/contribution/octavia/90
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases for multiple L3 backends

[Doug Wiegley]

The lbaas use case was something like having one flavor with hardware SSL 
offload and one that doesn’t, e.g. You can easily have multiple backends that 
can do both (in fact, you might even want to let the lower flavor provision 
onto the higher, if you have spare capacity on one and not the other.) And the 
initial “scheduler” in such cases was supposed to be a simple round robin or 
hash, to be revisted later, including the inevitable rescheduling problem, or 
oversubscription issue. It quickly becomes as the same hairy wart that nova has 
to deal with, and all are valid use cases.

doug


> On Feb 2, 2016, at 6:43 PM, Kevin Benton <blak...@gmail.com> wrote:
> 
> So flavors are for routers with different behaviors that you want the user to 
> be able to choose from (e.g. High performance, slow but free, packet logged, 
> etc). Multiple drivers are for when you have multiple backends providing the 
> same flavor (e.g. The high performance flavor has several drivers for various 
> bare metal routers).
> 
> On Feb 2, 2016 18:22, "rzang" <rui.z...@foxmail.com 
> <mailto:rui.z...@foxmail.com>> wrote:
> What advantage can we get from putting multiple drivers into one flavor over 
> strictly limit one flavor one driver (or whatever it is called).
> 
> Thanks,
> Rui
> 
> -- Original --
> From:  "Kevin Benton";<blak...@gmail.com <mailto:blak...@gmail.com>>;
> Send time: Wednesday, Feb 3, 2016 8:55 AM
> To: "OpenStack Development Mailing List (not for usage 
> questions)"<openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org>>;
> Subject:  Re: [openstack-dev] [neutron] - L3 flavors and issues with usecases 
> for multiple L3 backends
> 
> Choosing from multiple drivers for the same flavor is scheduling. I didn't 
> mean automatically selecting other flavors.
> 
> On Feb 2, 2016 17:53, "Eichberger, German" <german.eichber...@hpe.com 
> <mailto:german.eichber...@hpe.com>> wrote:
> Not that you could call it scheduling. The intent was that the user could 
> pick the best flavor for his task (e.g. a gold router as opposed to a silver 
> one). The system then would “schedule” the driver configured for gold or 
> silver. Rescheduling wasn’t really a consideration…
> 
> German
> 
> From: Doug Wiegley <doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com><mailto:doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com>>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org
>  <mailto:openstack-dev@lists.openstack.org>>>
> Date: Monday, February 1, 2016 at 8:17 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org 
> <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org
>  <mailto:openstack-dev@lists.openstack.org>>>
> Subject: Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases 
> for multiple L3 backends
> 
> Yes, scheduling was a big gnarly wart that was punted for the first pass. The 
> intention was that any driver you put in a single flavor had equivalent 
> capabilities/plumbed to the same networks/etc.
> 
> doug
> 
> 
> On Feb 1, 2016, at 7:08 AM, Kevin Benton <blak...@gmail.com 
> <mailto:blak...@gmail.com><mailto:blak...@gmail.com 
> <mailto:blak...@gmail.com>>> wrote:
> 
> 
> Hi all,
> 
> I've been working on an implementation of the multiple L3 backends RFE[1] 
> using the flavor framework and I've run into some snags with the use-cases.[2]
> 
> The first use cases are relatively straightforward where the user requests a 
> specific flavor and that request gets dispatched to a driver associated with 
> that flavor via a service profile. However, several of the use-cases are 
> based around the idea that there is a single flavor with multiple drivers and 
> a specific driver will need to be used depending on the placement of the 
> router interfaces. i.e. a router cannot be bound to a driver until an 
> interface is attached.
> 
> This creates some painful coordination problems amongst drivers. For example, 
> say the first two networks that a user attaches a router to can be reached by 
> all drivers because they use overlays so the first driver chosen by the 
> framework works  fine. Then the user connects to an external network which is 
> only reachable by a different driver. Do we immediately reschedule the entire 
> rout

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

[Doug Wiegley]

Yes, scheduling was a big gnarly wart that was punted for the first pass. The 
intention was that any driver you put in a single flavor had equivalent 
capabilities/plumbed to the same networks/etc.

doug


> On Feb 1, 2016, at 7:08 AM, Kevin Benton  wrote:
> 
> Hi all,
> 
> I've been working on an implementation of the multiple L3 backends RFE[1] 
> using the flavor framework and I've run into some snags with the use-cases.[2]
> 
> The first use cases are relatively straightforward where the user requests a 
> specific flavor and that request gets dispatched to a driver associated with 
> that flavor via a service profile. However, several of the use-cases are 
> based around the idea that there is a single flavor with multiple drivers and 
> a specific driver will need to be used depending on the placement of the 
> router interfaces. i.e. a router cannot be bound to a driver until an 
> interface is attached.
> 
> This creates some painful coordination problems amongst drivers. For example, 
> say the first two networks that a user attaches a router to can be reached by 
> all drivers because they use overlays so the first driver chosen by the 
> framework works  fine. Then the user connects to an external network which is 
> only reachable by a different driver. Do we immediately reschedule the entire 
> router at that point to the other driver and interrupt the traffic between 
> the first two networks?
> 
> Even if we are fine with a traffic interruption for rescheduling, what should 
> we do when a failure occurs half way through switching over because the new 
> driver fails to attach to one of the networks (or the old driver fails to 
> detach from one)? It would seem the correct API experience would be switch 
> everything back and then return a failure to the caller trying to add an 
> interface. This is where things get messy.
> 
> If there is a failure during the switch back, we now have a single router's 
> resources smeared across two drivers. We can drop the router into the ERROR 
> state and re-attempt the switch in a periodic task, or maybe just leave it 
> broken.
> 
> How should we handle this much orchestration? Should we pull in something 
> like taskflow, or maybe defer that use case for now?
> 
> What I want to avoid is what happened with ML2 where error handling is still 
> a TODO in several cases. (e.g. Any post-commit update or delete failures in 
> mechanism drivers will not trigger a revert in state.)
> 
> 1. https://bugs.launchpad.net/neutron/+bug/1461133 
> 
> 2. https://etherpad.openstack.org/p/ 
> neutron-modular-l3-router-plugin-use-cases
>  
> -- 
> Kevin Benton
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron] no neutron lib meeting

[Doug Wiegley]

Multiple cancels, and I'll be on a plane.

Thanks,
Doug

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

[openstack-dev] [neutron] mid cycle details

[Doug Wiegley]

Hi all,

Where: Minnesota (great planning for winter!)
When:Feb 23-26

Details:
https://etherpad.openstack.org/p/neutron-mitaka-midcycle

Please RSVP. And yell at Kyle for using that shade of red.

Thanks,
doug



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

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be optional on member create?

[Doug Wiegley]

But, by requiring an external subnet, you are assuming that the packets always 
originate from inside a neutron network. That is not necessarily the case with 
a physical device.

doug


> On Jan 19, 2016, at 11:55 AM, Michael Johnson  wrote:
> 
> I feel that the subnet should be mandatory as there are too many
> ambiguity issues due to overlapping subnets and multiple routes.
> In the case of an IP being outside of the tenant networks, the user
> would specify an external network that has the appropriate routes.  We
> cannot always assume which tenant network with an external (or VPN)
> route is the appropriate one to use.
> 
> Michael
> 
> On Mon, Jan 18, 2016 at 2:45 PM, Stephen Balukoff  
> wrote:
>> Vivek--
>> 
>> "Member" in this case refers to an IP address that (probably) lives on a
>> tenant back-end network. We can't specify just the IP address when talking
>> to such an IP since tenant subnets may use overlapping IP ranges (ie. in
>> this case, subnet is required). In the case of the namespace driver and
>> Octavia, we use the subnet parameter for all members to determine which
>> back-end networks the load balancing software needs a port on.
>> 
>> I think the original use case for making subnet optional was the idea that
>> sometimes a tenant would like to add a "member" IP that is not part of their
>> tenant networks at all--  this is more than likely an IP address that lives
>> outside the local cloud. The assumption, then, would be that this IP address
>> should be reachable through standard routing from wherever the load balancer
>> happens to live on the network. That is to say, the load balancer will try
>> to get to such an IP address via its default gateway, unless it has a more
>> specific route.
>> 
>> As far as I'm aware, this use case is still valid and being asked for by
>> tenants. Therefore, I'm in favor of making member subnet optional.
>> 
>> Stephen
>> 
>> On Mon, Jan 18, 2016 at 11:14 AM, Jain, Vivek  wrote:
>>> 
>>> If member port (IP address) is allocated by neutron, then why do we need
>>> to specify it explicitly? It can be derived by LBaaS driver implicitly.
>>> 
>>> Thanks,
>>> Vivek
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 1/17/16, 1:05 AM, "Samuel Bercovici"  wrote:
>>> 
 Btw.
 
 I am still in favor on associating the subnets to the LB and then not
 specify them per node at all.
 
 -Sam.
 
 
 -Original Message-
 From: Samuel Bercovici [mailto:samu...@radware.com]
 Sent: Sunday, January 17, 2016 10:14 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be
 optional on member create?
 
 +1
 Subnet should be mandatory
 
 The only thing this makes supporting load balancing servers which are not
 running in the cloud more challenging to support.
 But I do not see this as a huge user story (lb in cloud load balancing
 IPs outside the cloud)
 
 -Sam.
 
 -Original Message-
 From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
 Sent: Saturday, January 16, 2016 6:56 AM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron][LBaaS][Octavia] Should subnet be
 optional on member create?
 
 I filed a bug [1] a while ago that subnet_id should be an optional
 parameter for member creation.  Currently it is required.  Review [2] is
 makes it optional.
 
 The original thinking was that if the load balancer is ever connected to
 that same subnet, be it by another member on that subnet or the vip on that
 subnet, then the user does not need to specify the subnet for new member if
 that new member is on one of those subnets.
 
 At the midcycle we discussed it and we had an informal agreement that it
 required too many assumptions on the part of the end user, neutron lbaas,
 and driver.
 
 If anyone wants to voice their opinion on this matter, do so on the bug
 report, review, or in response to this thread.  Otherwise, it'll probably 
 be
 abandoned and not done at some point.
 
 Thanks,
 Brandon
 
 [1] https://bugs.launchpad.net/neutron/+bug/1426248
 [2] https://review.openstack.org/#/c/267935/
>>> 
> __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
> __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

Re: [openstack-dev] [neutron][api] GET call with huge argument list

[Doug Wiegley]

It would have to be a POST, but even that will start to have timeout issues. An 
API which requires that kind of input is kind of a bad idea. Perhaps you could 
describe what you’re trying to do?

Thanks,
doug

> On Jan 19, 2016, at 4:59 PM, Shraddha Pandhe  
> wrote:
> 
> Hi folks,
> 
> 
> I am writing a Neutron extension which needs to take 1000s of network-ids as 
> argument for filtering. The CURL call is as follows:
> 
> curl -i -X GET 
> 'http://hostname:port/neutron/v2.0/extension_name.json?net-id=fffecbd1-0f6d-4f02-aee7-ca62094830f5=fffeee07-4f94-4cff-bf8e-a2aa7be59e2e'
>  -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
> "X-Auth-Token: "
> 
> 
> The list of net-ids can go up to 1000s. The problem is, with such large url, 
> I get the "Request URI too long" error. I don't want to update this limit as 
> proxies can have their own limits.
> 
> What options do I have to send 1000s of network IDs? 
> 
> 1. -d '{}' is not a recommended option for GET call and wsgi Controller drops 
> the data part when routing the request.
> 
> 2. Use POST instead of GET? I will need to write the get_ logic 
> inside create_resource logic for this to work. Its a hack, but complies with 
> HTTP standard.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Neutron] Gate failure

[Doug Wiegley]

This fix failed to merge, due to a new regression in how another job is using 
dib.  Here's a non voting patch for that, until it gets debugged:

https://review.openstack.org/267223

The fail stack is now two deep.

Doug


> On Jan 13, 2016, at 11:41 AM, Armando M.  wrote:
> 
> It's the usual time of the week where I submit the dreaded email
> 
> Please do not push anything in the queue until change [1] merges.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/266885/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

[Doug Wiegley]

Hi Gary,

Thanks for filing.  Take a look at 
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html
 , which is work in progress to address the same issue. At the end of that, no 
one should be importing directly from neutron.

Thanks,
doug


> On Jan 12, 2016, at 5:31 AM, Gary Kotton <gkot...@vmware.com> wrote:
> 
> Hi,
> I have drafted 
> https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have 
> up as an example (https://review.openstack.org/266304) 
> for people to chew on...
> Thanks
> Gary
> 
> 
> 
> On 1/12/16, 1:08 PM, "Smigiel, Dariusz" <dariusz.smig...@intel.com> wrote:
> 
>>> 
>>> Hi,
>>> At the moment private methods are used all over the place. Examples for
>>> this are the address pairs and the security groups. If you do a grep of the 
>>> ML2
>>> plugin you will see these innocent private methods being used.
>>> The end goal would be for us to have these as public methods.
>>> Thanks
>>> Gary
>>> 
>> 
>> OK, get it. But just wanted to know, what is the outcome from email 
>> discussion.
>> Do we need to match changed/removed private methods with deprecation warning,
>> or just modify and tell plugins: "deal with it" :)
>> 
>> BR,
>> Dariusz (dasm) Smigiel
>> 
>>> 
>>> 
>>> 
>>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" <dariusz.smig...@intel.com> wrote:
>>> 
>>>> 
>>>> 
>>>>> Doug Wiegley <doug...@parksidesoftware.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>> wrote:
>>>>>>> 
>>>>>>> Sean M. Collins <s...@coreitpro.com> wrote:
>>>>>>> 
>>>>>>>>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>>>>>>>>>> On Fri, 8 Jan 2016, Gary Kotton wrote:
>>>>>>>>>> 
>>>>>>>>>> The commit
>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>> 3A__github.com
>>>>>>>>>> _openstack_neutron_commit_5d53dfb8d64186-
>>> 2D=BQICAg=Sqcl0Ez6
>>>>>>>>>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>>> uEs=VlZxHpZBmzzkWT5jqz9JYBk8Y
>>>>>>>>>> Teq9N3-
>>> diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
>>>>>>>>>> w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
>>>>>>>>>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
>>>>>>>>>> that make use of the method _get_tenant_id_for_create
>>>>>>>>> 
>>>>>>>>> Just out of curiosity, is it not standard practice that a plugin
>>>>>>>>> shouldn't use a private method?
>>>>>>>> 
>>>>>>>> +1 - hopefully decomposed plugins will audit their code and look
>>>>>>>> +for
>>>>>>>> other calls to private methods.
>>>>>>> 
>>>>>>> The fact that it broke *aas repos too suggests that we were not
>>>>>>> showing a proper example to those decomposed. I think it can be
>>>>>>> reasonable to restore the method until N, with a deprecation
>>>>>>> message, as Garry suggested in his patch. Especially since there
>>>>>>> is no actual burden to keep the method for another cycle.
>>>>>> 
>>>>>> The neutron community has been really lax about enforcing private
>>>>> methods.
>>>>>> And while we should absolutely reverse that trend, likely we should
>>>>>> give some warning. I agree with not going whole hog on that until N.
>>>>>> 
>>>>>> I'd suggest putting in a debtcollector reference when putting the
>>>>>> method
>>>>> back.
>>>>> 
>>>>> Done. https://review.openstack.org/265315
>>>> 
>>>> 
>>>> Do we have any consensus about treating private methods? Any general
>>> tips about it, or every time should it be left for author decision?
>>>> 
>>>> Should we use deprecation warning for all refactored private methods,
>>> treating it as "API" and rewriting underneath code?
>>>> 
>>>> Thanks, Dariusz (dasm) Smigiel
>>>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

[Doug Wiegley]

I don’t think it ninja merged. It had plenty of reviews, and was open during 
international hours. I don’t have any issue there.

I don’t like the crazy early meeting, so I set out to prove it didn’t matter:

Average attendance before rotating: 20.7 people
Average attendance on Monday afternoons (U.S. time): 20.9
Average attendance on Tuesday morning (U.S. time): 23.7

Stupid data, that’s not what I wanted to see.

I haven’t yet correlated people to which meeting time yet, but attendance was 
slightly up during the crazy early hated time, across the 1.25 years it was 
running (started 9/9/14). This is just people saying something; lurkers can 
just read the logs.

Data is from eavesdrop meeting logs, if anyone else wants to crunch it.

Thanks,
doug


> On Jan 12, 2016, at 4:32 PM, Tony Breeds  wrote:
> 
> On Tue, Jan 12, 2016 at 01:27:30PM +0100, Ihar Hrachyshka wrote:
>> Agreed with Gary on behalf of my European compatriots. (Note that I
>> *personally* +1’d the patch because I don’t mind, doing late hours anyway;
>> but it’s sad it was ninja merged without giving any chance for those from
>> affected timezones to express their concerns).
> 
> So Ninja merged has a negative connotation that I refute.
> 
> I merged it.  It was judgment error, and I apologise for that.
> 
> * I found and read through the list thread.
> * Saw only +1's yours included
>- known you'd be affected I used your +1 as a barometer
> 
> My mistake was not noticing your request to leave the review open for longer.
> 
> I also noted in my review that reverting it is pretty low cost to back it out
> if needed.
> 
> I understand that the 'root cause' for this change was the yaml2ical issue 
> that
> stemmed from having 2 odd week in a row.  We've fixed that [1]. I'm also
> working a a more human concept of biweekly meeting in yaml2ical.
> 
> Tony
> [1] the next time it could have been a problem is 2020/2021 ;P
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

[Doug Wiegley]

Move, refactor, or remove and code around, yes. If it’s meant to be a stable 
internal neutron api, some form of it will move and be versioned.

Thanks,
doug


> On Jan 12, 2016, at 9:20 AM, Gary Kotton <gkot...@vmware.com> wrote:
> 
> So Doug are you planning on moving all of the extensions and mixins to the 
> Neutron lib?
> My understanding was that was not part of the scope, but maybe I missed that 
> with all of the moving parts.
> Thanks
> Gary
> 
> 
> 
> On 1/12/16, 4:46 PM, "Doug Wiegley" <doug...@parksidesoftware.com> wrote:
> 
>> Hi Gary,
>> 
>> Thanks for filing.  Take a look at 
>> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-lib.html
>>  , which is work in progress to address the same issue. At the end of that, 
>> no one should be importing directly from neutron.
>> 
>> Thanks,
>> doug
>> 
>> 
>>> On Jan 12, 2016, at 5:31 AM, Gary Kotton <gkot...@vmware.com> wrote:
>>> 
>>> Hi,
>>> I have drafted 
>>> https://blueprints.launchpad.net/neutron/+spec/better-defined-apis and have 
>>> up as an example (https://review.openstack.org/266304) 
>>> for people to chew on...
>>> Thanks
>>> Gary
>>> 
>>> 
>>> 
>>> On 1/12/16, 1:08 PM, "Smigiel, Dariusz" <dariusz.smig...@intel.com> wrote:
>>> 
>>>>> 
>>>>> Hi,
>>>>> At the moment private methods are used all over the place. Examples for
>>>>> this are the address pairs and the security groups. If you do a grep of 
>>>>> the ML2
>>>>> plugin you will see these innocent private methods being used.
>>>>> The end goal would be for us to have these as public methods.
>>>>> Thanks
>>>>> Gary
>>>>> 
>>>> 
>>>> OK, get it. But just wanted to know, what is the outcome from email 
>>>> discussion.
>>>> Do we need to match changed/removed private methods with deprecation 
>>>> warning,
>>>> or just modify and tell plugins: "deal with it" :)
>>>> 
>>>> BR,
>>>> Dariusz (dasm) Smigiel
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 1/12/16, 11:52 AM, "Smigiel, Dariusz" <dariusz.smig...@intel.com> 
>>>>> wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Doug Wiegley <doug...@parksidesoftware.com> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka <ihrac...@redhat.com>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Sean M. Collins <s...@coreitpro.com> wrote:
>>>>>>>>> 
>>>>>>>>>>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
>>>>>>>>>>>> On Fri, 8 Jan 2016, Gary Kotton wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> The commit
>>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>> 3A__github.com
>>>>>>>>>>>> _openstack_neutron_commit_5d53dfb8d64186-
>>>>> 2D=BQICAg=Sqcl0Ez6
>>>>>>>>>>>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
>>>>> uEs=VlZxHpZBmzzkWT5jqz9JYBk8Y
>>>>>>>>>>>> Teq9N3-
>>>>> diTlNj4GyNc=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
>>>>>>>>>>>> w=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8=
>>>>>>>>>>>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
>>>>>>>>>>>> that make use of the method _get_tenant_id_for_create
>>>>>>>>>>> 
>>>>>>>>>>> Just out of curiosity, is it not standard practice that a plugin
>>>>>>>>>>> shouldn't use a private method?
>>>>>>>>>> 
>>>>>>>>>> +1 - hopefully decomposed plugins will audit their code and look
>>>>>>>>>> +for
>>>>>>>>>> other calls to private methods.
>>>>>>>>> 
>>>>>>>>> The fact that it broke *aas repos too suggests that we were not
>>>>>>>>&g

Re: [openstack-dev] [Neutron] Heads up for decomposed plugin break

[Doug Wiegley]

> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka  wrote:
> 
> Sean M. Collins  wrote:
> 
>>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
 On Fri, 8 Jan 2016, Gary Kotton wrote:
 
 The commit https://github.com/openstack/neutron/commit/5d53dfb8d64186-
 b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that make
 use of the method _get_tenant_id_for_create
>>> 
>>> Just out of curiosity, is it not standard practice that a plugin
>>> shouldn't use a private method?
>> 
>> +1 - hopefully decomposed plugins will audit their code and look for
>> other calls to private methods.
> 
> The fact that it broke *aas repos too suggests that we were not showing a 
> proper example to those decomposed. I think it can be reasonable to restore 
> the method until N, with a deprecation message, as Garry suggested in his 
> patch. Especially since there is no actual burden to keep the method for 
> another cycle.

The neutron community has been really lax about enforcing private methods.  And 
while we should absolutely reverse that trend, likely we should give some 
warning. I agree with not going whole hog on that until N. 

I'd suggest putting in a debtcollector reference when putting the method back. 

Doug

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

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

Re: [openstack-dev] [neutron] neutron-lib meetings canceled 12/23, 12/30

[Doug Wiegley]

Nothing on the agenda for tomorrow, and many of us will be local next week, so 
let’s cancel this week, and resume next.

Thanks,
doug

> On Dec 22, 2015, at 12:07 PM, Doug Wiegley <doug...@parksidesoftware.com> 
> wrote:
> 
> Happy holidays, see you all on 1/6.
> 
> Thanks,
> doug
> 


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

[openstack-dev] [neutron] neutron-lib meetings canceled 12/23, 12/30

[Doug Wiegley]

Happy holidays, see you all on 1/6.

Thanks,
doug


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

[openstack-dev] [neutron] neutron-lib subteam

[Doug Wiegley]

Hi all,

We are starting a formal neutron-lib subteam for work revolving around 
neutron-lib and general decoupling efforts of all neutron projects.

The first meeting is tomorrow at 1730 UTC in #openstack-meeting-4.

More info can be found here:

https://wiki.openstack.org/wiki/Network/Lib/Meetings
https://wiki.openstack.org/wiki/Neutron/Lib
https://review.openstack.org/#/q/status:open+project:openstack/neutron-lib,n,z
https://github.com/openstack/neutron-lib/blob/master/doc/source/review-guidelines.rst

Thanks,
doug



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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Dec 9, 2015, at 7:25 AM, Doug Hellmann  wrote:
> 
> Excerpts from Armando M.'s message of 2015-12-08 22:46:16 -0800:
>> On 3 December 2015 at 02:21, Thierry Carrez  wrote:
>> 
>>> Armando M. wrote:
 On 2 December 2015 at 01:16, Thierry Carrez > wrote:
>Armando M. wrote:
>>> One solution is, like you mentioned, to make some (or all) of
>>> them
>>> full-fledged project teams. Be aware that this means the TC
>>> would judge
>>> those new project teams individually and might reject them if we
>>> feel
>>> the requirements are not met. We might want to clarify what
>>> happens
>>> then.
>> 
>> That's a good point. Do we have existing examples of this or
>>> would we be
>> sailing in uncharted waters?
> 
>It's been pretty common that we rejected/delayed applications for
>projects where we felt they needed more alignment. In such cases,
>>> the
>immediate result for those projects if they are out of the Neutron
>"stadium" is that they would fall from the list of official
>>> projects.
>Again, I'm fine with that outcome, but I want to set expectations
>clearly :)
 
 Understood. It sounds to me that the outcome would be that those
 projects (that may end up being rejected) would show nowhere on [1], but
 would still be hosted and can rely on the support and services of the
 OpenStack community, right?
 
 [1] http://governance.openstack.org/reference/projects/
>>> 
>>> Yes they would still be hosted on OpenStack development infrastructure.
>>> Contributions would no longer count toward ATC status, so people who
>>> only contribute to those projects would no longer be able to vote in the
>>> Technical Committee election. They would not have "official" design
>>> summit space either -- they can still camp in the hallway though :)
>>> 
>> 
>> Hi folks,
>> 
>> For whom of you is interested in the conversation, the topic was brought
>> for discussion at the latest TC meeting [1]. Unfortunately I was unable to
>> join, however I would like to try and respond to some of the comments made
>> to clarify my position on the matter:
>> 
>>> ttx: the neutron PTL say he can't vouch for anything in the neutron
>> "stadium"
>> 
>> To be honest that's not entirely my position.
>> 
>> The problem stems from the fact that, if I am asked what the stadium means,
>> as a PTL I can't give a straight answer; ttx put it relatively well (and I
>> quote him): by adding all those projects under your own project team, you
>> bypass the Technical Committee approval that they behave like OpenStack
>> projects and are produced by the OpenStack community. The Neutron team
>> basically vouches for all of them to be on par. As far as the Technical
>> Committee goes, they are all being produced by the same team we originally
>> blessed (the Neutron project team).
>> 
>> The reality is: some of these projects are not produced by the same team,
>> they do not behave the same way, and they do not follow the same practices
>> and guidelines. For the stadium to make sense, in my humble opinion, a
> 
> This is the thing that's key, for me. As Anita points out elsewhere in
> this thread, we want to structure our project teams so that decision
> making and responsibility are placed in the same set of hands. It sounds
> like the Stadium concept has made it easy to let those diverge.
> 
>> definition of these practices should happen and enforcement should follow,
>> but who's got the time for policing and enforcing eviction, especially on a
>> large scale? So we either reduce the scale (which might not be feasible
>> because in OpenStack we're all about scaling and adding more and more and
>> more), or we address the problem more radically by evolving the
>> relationship from tight aggregation to loose association; this way who
>> needs to vouch for the Neutron relationship is not the Neutron PTL, but the
>> person sponsoring the project that wants to be associated to Neutron. On
>> the other end, the vouching may still be pursued, but for a much more
>> focused set of initiatives that are led by the same team.
>> 
>>> russellb: I attempted to start breaking down the different types of repos
>> that are part of the stadium (consumer, api, implementation of technology,
>> plugins/drivers).
>> 
>> The distinction between implementation of technology, plugins/drivers and
>> api is not justified IMO because from a neutron standpoint they all look
>> like the same: they leverage the pluggable extensions to the Neutron core
>> framework. As I attempted to say: we have existing plugins and drivers that
>> implement APIs, and we have plugins that implement technology, so the extra
>> classification seems overspecification.
>> 
>>> flaper87: I agree a driver should not be independent
>> 
>> Why, what's your rationale? If we dig deeper, 

Re: [openstack-dev] Fwd: [Neutron] Team meeting this Monday at 2100 UTC

[Doug Wiegley]

I actually found this week’s meeting more useful than normal. The typical 
agenda items feel rote and less useful to aligning things, sort of, thinking 
out loud.

doug

> On Dec 8, 2015, at 8:41 AM, Kyle Mestery  wrote:
> 
> On Tue, Dec 8, 2015 at 1:54 AM, Smigiel, Dariusz  > wrote:
> 
> > -Original Message-
> > From: Kevin Benton [mailto:blak...@gmail.com ]
> >
> > I liked using the meeting for it because it was a nice way for everyone to 
> > get
> > a snapshot of where each thing was at.
> 
> +1
> The idea of discussing everything on meeting is very good.
> Everyone interested is  on the same page.
> 
> 
> The meeting works nice, so I'm +1 for this type of usage.
>  
> Cheers,
> Darek Smigiel (dasm)
> ITP
> 
> >
> > On Dec 7, 2015 3:14 PM, "Armando M."  > 
> > > > wrote:
> >
> >
> >   Hi neutrinos,
> >
> >   During today's meeting [1] we went through the outstanding
> > blueprints, but we only managed to look at a little over half of them.
> >
> >   Would you guys like to continue the conversation during next week's
> > meeting or shall we ask for people's status updates offline? An update on
> > the BP's whiteboard like done in [2] would suffice.
> >
> >   Cheers,
> >   Armando
> >
> >   [1]
> > http://eavesdrop.openstack.org/meetings/networking/2015/networking.20 
> > 
> > 15-12-07-21.00.html
> >   [2] https://blueprints.launchpad.net/neutron/+spec/external-dns- 
> > 
> > resolution
> >
> >   -- Forwarded message --
> >   From: Armando M. 
> > > >
> >   Date: 4 December 2015 at 12:50
> >   Subject: [Neutron] Team meeting this Monday at 2100 UTC
> >   To: "OpenStack Development Mailing List (not for usage questions)"
> >  >   > 
> > d...@lists.openstack.org > >
> >
> >
> >
> >   Hi neutrinos,
> >
> >   A kind reminder for next week's meeting.
> >
> >   Being the meeting right after the milestone was cut, I'd like to take
> > most of the hour to talk about blueprints/specs, i.e. the beefy workload 
> > that
> > has merged, and has yet to merge.
> >
> >   We'll be brief on announcements and bugs, and skip the other
> > sections, docs and open agenda. More details on [1].
> >
> >   We'll run this specially focussed meetings throughout the release,
> > and we'll have meetings focussed on Docs and Bugs alone too in the future.
> > Stay tuned.
> >
> >   Cheers,
> >   Armando
> >
> >   [1] https://wiki.openstack.org/wiki/Network/Meetings 
> > 
> >  > >
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Doug Wiegley]

> On Dec 4, 2015, at 12:40 PM, Kyle Mestery  wrote:
> 
> On Fri, Dec 4, 2015 at 1:28 PM, Henry Gessau  > wrote:
> Kevin Benton > wrote:
> > So obviously the stuff in the client can be updated since most of that is
> > user-facing. However, on the server side maybe we can start out by keeping 
> > all
> > of the internal code and DB tables the same. Then all we need to worry about
> > is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the transition to
> > project_id internally at our own pace and in much less invasive chunks.
> 
> I agree with Kevin's suggestion.
> 
> 
> ++, and this is what Salvatore has previously suggested as well.

There was general consensus around this at the last neutron meeting, too.

And one thing missing from your analysis is subprojects that import neutron. 
Many will be referencing tenant or tenant_id in methods, models, or dicts, and 
though those are “internal”, providing backwards compatibility would be a sane 
thing to consider.

Thanks,
dogu



>  
> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz 
> > 
> > >> 
> > wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in Mitaka
> > [6], and probably forever. It will stay at least four releases, but we
> > need to decide, how to conquer problem of renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of 'tenant' 
> > to
> > 'project', and trying to find out all the details.
> > First attempt to solve this problem was raised in November 2013 [4][5] 
> > but
> > unfortunately, no one finished it. Although Keystone V3 API is already
> > supported in Neutron client [2], there are still some unknowns about
> > Neutron server side. Monty Taylor is trying to address necessary (if 
> > any)
> > changes [3].
> >
> > Findings:
> > I've focused on two projects: python-neutronclient and neutron.
> > grep found 429 occurrences of 'tenant' in Client while Server has 3021 
> > of
> > it. Some of them are just documentation and docstrings, but there are a
> > lot of places, where variables are tangled: defined in DB, used in 
> > server,
> > accessed by client. Most of places are just internal usages. The only
> > thing where I've found 'public' information about tenants is 'help'
> > command in neutron client.
> >
> > Suggested plan for conquer:
> > 1. First step would be to deal with neutronclient. It's much smaller
> > amount of code to look through, update all places and be successful :)
> > 2. Bigger challenge will be to change server side code. I'd suggest to
> > start with renaming db columns. It affects a lot of places, so when
> > finished should significantly lower number of remained "tenants".
> > 3. Deal with all other places.
> >
> > Pros:
> > - variable names unification in OpenStack code base. Someone needs to
> > start this job.
> > - one way to describe the same thing, instead of: 
> > tenant/account/project.
> > Helpful, especially for newcomers.
> > - alignment with Keystone V3 API
> >
> > Cons:
> > - A. Lot. Of. Work.
> > - dealing with DB migrations
> > - about 2-4 weeks of work for every part of code. Additional, a lot of
> > patchsets to be reviewed.
> >
> > What do you think about this? About proposed way of dealing with all 
> > changes?
> > Is this change necessary?
> > Did I forget about something?
> >
> > I'll be grateful for any kind of feedback.
> >
> > Thanks,
> >  Dariusz Smigiel (dasm)
> >  Intel Technology Poland
> >
> > [1] 
> > https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project 
> > 
> > [2]
> > 
> > https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
> >  
> > 
> > [3] https://bugs.launchpad.net/neutron/+bug/1503428 
> > 
> > [4]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> >  
> > 
> > [5]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> >  
> > 
> > [6]
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm 
> > 

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

[Doug Wiegley]

> On Dec 3, 2015, at 9:48 AM, Armando M.  wrote:
> 
> 
> 
>> On 3 December 2015 at 08:33, Ihar Hrachyshka  wrote:
>> Akihiro Motoki  wrote:
>> 
>>> Hi,
>>> 
>>> python-neutronclient still has XML support of Neutron API.
>>> I would like to discuss when we drop XML support in neutronclient.
>>> 
>>> Neutron API XML suppoort was marked as deprecated in Icehouse and Juno
>>> and was dropped in Kilo. Juno is now EOL and we have no gate testing which
>>> requires XML support. This is a minimum requirement.
>>> From this point, we can drop XML support now.
>>> 
>>> Another point is users who are OpenStack clouds using Juno or older versions
>>> may use the latest python-neutronclient.
>>> XML support in Neutron was deprecated since Icehouse, and if our deprecation
>>> notice works, XML API is used only in cloud deployed before Icehouse.
>>> In addition, older versions of neutronclient are available from
>>> various distributions and PyPI.
>>> Do we need to continue XML support for users of such cloud?
>>> Note that we no longer have a way to test XML API support is functional.
>>> 
>>> Thanks,
>>> Akihiro
>> 
>> Let’s not pretend anything ungated works in OpenStack world. If we don’t 
>> have infra to validate it, we should kill the support for it.
> 
> Kill it already! :)

With fire!


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

Re: [openstack-dev] [Neutron] Bug deputy process

[Doug Wiegley]

Roughly an hour a day, and super useful. I’d echo that anyone can volunteer, 
since a lot of the job is reaching out to various folks for input 
(docs/policies/neutron-teams.rst is the map of truth.)

I found a lot of bugs that I care about in the pre-mitaka backlog, that I 
didn’t know existed. This has been an education process for me, and I’ve been 
trying to triage one pre-mitaka bug for every mitaka one.

A rotating RFE deputy from the drivers team might also be useful, so the first 
pass isn’t always the drivers meeting. I tend to pay attention more when it’s 
my “assigned” turn. I shouldn’t, but I do.

Thanks,
doug



> On Dec 3, 2015, at 9:29 AM, Kyle Mestery  wrote:
> 
> On Wed, Dec 2, 2015 at 10:49 AM, Armando M.  > wrote:
> Hi neutrinos,
> 
> It's been a couple of months that the Bug deputy process has been in place 
> [1,2]. Since the beginning of Mitaka we have collected the following 
> statistics (for neutron and neutronclient):
> 
> Total bug reports: 373
> Fix committed: 144
> Unassigned: 73
> New: 17
> Incomplete: 20
> Confirmed: 27
> Triaged: 6
> 
> At first, it is clear that we do not fix issues nearly as fast as they come 
> in, but at least we managed to keep the number of unassigned/unvetted bugs 
> relatively small, so kudos to you all who participated in this experiment. I 
> don't have data based on older releases, so I can't see whether we've 
> improved or worsened, and I'd like to ask for feedback from the people who 
> played with this first hand, especially on the amount of time that has taken 
> them to do deputy duty for their assigned week.
> ihrachys
> regXboi
> markmcclain
> mestery
> mangelajo
> garyk
> rossella_s
> dougwig
> Many thanks,
> Armando
> 
> 
> I've found the process to be super useful. I found that by volunteering to be 
> the bug deputy it forced me to spend about an hour a day going through 
> incoming bugs. But the result is faster triage, and I was able to point some 
> bugs directly at people for quick resolution. Thanks for driving this 
> important initiative!
> 
> One concern I have is ensuring we rotate people, because it does take some 
> time, and if the same handful of rotate, they will burn out. So I actively 
> encourage more people to volunteer, you don't even have to be a Neutron core 
> reviewer to do this!
> 
> Thanks!
> Kyle
>  
> [1] https://wiki.openstack.org/wiki/Network/Meetings#Bug_deputy 
> 
> [2] 
> http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Release Notes for *aaS projects

[Doug Wiegley]

I’m in favor of things living in the repo where their code lives. The fewer 
dependencies the better. Especially if we stop adding them. So, I agree.

doug


> On Dec 2, 2015, at 9:38 AM, Kyle Mestery  wrote:
> 
> We're hoping to cut Neutron M-1 this week [1]. We have implemented
> release notes in the main Neutron repository [2] , but not in the *aaS
> repositories. At the time, I thought this was a good approach and we
> could collect all releasenotes there. But I think it makes sense to
> have releasenotes in the *aaS repositories as well.
> 
> What I'm going to propose is we cut Neutron M-1 as-is now, with any
> *aaS releasenotes done in the main repository. Once Neutron M-1 is
> cut, I'll add the releasenotes stuff into the *aaS repositories, and
> we can start using releasenotes independently in those repositories.
> 
> If anyone has issues with this approach please reply on this thread.
> 
> Thanks!
> Kyle
> 
> [1] https://review.openstack.org/#/c/251959/
> [2] https://review.openstack.org/241758
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 5:56 PM, Armando M.  wrote:
> 
> Hi folks,
> 
> The stadium concept was introduced more or less formally since April of this 
> year. At the time it was introduced (see [1]), the list of deliverables 
> included neutron, client, specs and *-aas services. As you may be well aware, 
> 6+ months is a long time in the OpenStack world, and lots of things happened 
> since then. The list has grown to [2]. 
> 
> When I think about what 'deliverables' are, I am inclined to think that all 
> of the projects that are part of the list will have to behave and follow the 
> same rules, provided that there is flexibility given by the tags. However, 
> reality has proven us that rules are somewhat difficult to follow and 
> enforce, and some boundaries may be too strict for some initiatives to comply 
> with. This is especially true if we go from a handful of projects that we had 
> when this had started to the nearly the two dozens we have now.
> As a result, there is quite an effort imposed on the PTL, the various 
> liaisons (release, infra, docs, testing, etc) and the core team to help 
> manage the existing relationships and to ensure that the picture stays 
> coherent over time. Sometimes the decision of being part of this list is even 
> presented before one can see any code, and that defeats the whole point of 
> the deliverable association. I have experienced first hand that this has 
> become a burden, and I fear that the stadium might be an extra layer of 
> governance/complexity that could even interfere with the existing 
> responsibilities of the TC and of OpenStack infra.
> 
> So my question is: would revisiting/clarifying the concept be due after some 
> time we have seen it in action? I would like to think so. To be fair, I am 
> not sure what the right answer is, but I know for a fact that some iterations 
> are in order, and I like to make a proposal:
> 
> I would like to suggest that we evolve the structure of the Neutron 
> governance, so that most of the deliverables that are now part of the Neutron 
> stadium become standalone projects that are entirely self-governed (they have 
> their own core/release teams, etc). In order to denote the initiatives that 
> are related to Neutron I would like to present two new tags that projects can 
> choose to label themselves with:
> 
Interesting proposal, and I’m just thinking out loud here. I’m generally in 
favor of separating the governance as we separate the dependencies, just 
because at some point what we’re doing doesn’t scale. To provide a little 
context, there are two points worth keeping in mind:

- The neutron stadium actually slightly pre-dates the big tent, and works 
around some earlier governance friction. So it may make less sense now in light 
of those changes.

- Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to be 
useful. These items are less useful to be considered standalone, as they need 
general oversight, co-gating, and such, to stay sane. As we break the massive 
coupling that exists, this point will get less and less relevant. 

- I think that part of the initial intent was that these small subprojects 
would have their own core teams, but be able to take advantage of the 
infrastructure that exists around neutron as a whole (specs, release team, 
stable team, co-gates, mentors).

For your proposal, are you suggesting:

1. That these projects are fully separate, with their own PTLs and everything, 
and just have tags that imply their neutron dependency?  OR,
2. That they stay stadium projects, but we use tags to differentiate them? Many 
already have different core teams and their own specs process.

Are there particular projects that add more overhead? Does your proposal make 
it easier to get code to our user base? Does it add a bunch of makework to fit 
into a new model (same question, really). Is the PTL overhead too high 
currently? Is the shed pink or blue?  :-)

Thanks,
doug




> 
> 'is-neutron-subsystem': this means that the project provides networking 
> services by implementing an integral part (or parts) of an end-to-end neutron 
> system. Examples are: a service plugin, an ML2 mech driver, a monolithic 
> plugin, an agent etc. It's something an admin has to use in order to deploy 
> Neutron in a certain configuration.
> 'use-neutron-system': this means that the project provides networking 
> services by using a pre-deployed end-to-end neutron system as is. No 
> modifications whatsoever.
> 
> As a result, there is no oversight by the Neutron core team, the PTL or 
> liasons, but that should not stop people from being involved if they choose 
> to. We would not lose the important piece of information which is the 
> association to Neutron, and at the same time that would relieve some of us 
> from the onus of dealing with initiatives for which we lack enough context 
> and ability of providing effective guidance.
> 
> In the process, the core team 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 9:11 PM, Russell Bryant  wrote:
> 
> Some additional context: there are a few proposals for additional git
> repositories for Neutron that have been put on hold while we sort this out.
> 
> Add networking-bagpipe:
>  https://review.openstack.org/#/c/244736/
> 
> Add the Astara driver:
>  https://review.openstack.org/#/c/230699/
> 
> Add tap-as-a-service:
>  https://review.openstack.org/#/c/229869/
> 
> On 11/30/2015 07:56 PM, Armando M. wrote:
>> I would like to suggest that we evolve the structure of the Neutron
>> governance, so that most of the deliverables that are now part of the
>> Neutron stadium become standalone projects that are entirely
>> self-governed (they have their own core/release teams, etc). In order to
>> denote the initiatives that are related to Neutron I would like to
>> present two new tags that projects can choose to label themselves with:
>> 
>>  * 'is-neutron-subsystem': this means that the project provides
>>networking services by implementing an integral part (or parts) of
>>an end-to-end neutron system. Examples are: a service plugin, an ML2
>>mech driver, a monolithic plugin, an agent etc. It's something an
>>admin has to use in order to deploy Neutron in a certain configuration.
>>  * 'use-neutron-system': this means that the project provides
>>networking services by using a pre-deployed end-to-end neutron
>>system as is. No modifications whatsoever.
> 
> I just want to clarify the proposal.  IIUC, you propose splitting most
> of what is currently separately deliverables of the Neutron team and
> making them separate projects in terms of OpenStack governance.  When I
> originally proposed including networking-ovn under Neutron (and more
> generally, making room for all drivers to be included), making them
> separate projects was one of the options on the table, but it didn't
> seem best at the time.  For reference, that thread was here:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062310.html
> 
> When I was originally proposing this, I was only thinking about Neutron
> drivers, the stuff that connects Neutron to some other system to make
> Neutron do something.  The list has grown to include other things, as well.
> 
> I'm not sure where you propose the line to be, but for the sake of
> discussion, let's assume every deliverable in the governance definition
> for Neutron is under consideration for being split out with the
> exception of neutron, neutron-specs, and python-neutronclient.  The
> remaining deliverables are:
> 
>dragonflow:
>kuryr:
>networking-ale-omniswitch:
>networking-arista:
>networking-bgpvpn:
>networking-calico:
>networking-cisco:
>networking-fortinet:
>networking-hpe:
>networking-hyperv:
>networking-infoblox:
>networking-fujitsu:
>networking-l2gw:
>networking-lenovo:
>networking-midonet:
>networking-odl:
>networking-ofagent:
>networking-onos:
>networking-ovn:
>networking-plumgrid:
>networking-powervm:
>networking-sfc:
>networking-vsphere:
>octavia:
>python-neutron-pd-driver:
>vmware-nsx:
> 
> I think it's helpful to break these into categories, because the answer
> may be different for each group.  Here's my attempt at breaking this
> list into some categories:
> 
> 1) A consumer of Neutron
> 
>kuryr
> 
> IIUC, kuryr is a consumer of Neutron.  Its interaction with Neutron is
> via using Neutron's REST APIs.  You could think of kuryr's use of
> Neutron as architecturally similar to how Nova uses Neutron.
> 
> I think this project makes a ton of sense to become independent.
> 
> 2) Implementation of a networking technology
> 
>dragonflow
> 
> The dragonflow repo includes a couple of things.  It includes dragonflow
> itself, and the Neutron driver to connect to it.  Using Astara as an
> example to follow, dragonflow itself could be an independent project.
> 
> Following that, the built-in ML2/ovs or ML2/lb control plane could be
> separate, too, though that's much more painful and complex in practice.
> 
>octavia
> 
> Octavia also seems to fall into this category, just for LBaaS.  It's not
> just a driver, it's a LBaaS service VM orchestrator (which is in part
> what Astara is, too).

From the perspective of our users, I tend to consider neutron-lbaas and octavia 
as a unit, technical distinctions aside.

> 
> It seems reasonable to propose these as independent projects.
> 
> 3) New APIs
> 
> There are some repos that are implementing new REST APIs for Neutron.
> They're independent enough to need their own driver layer, but coupled
> with Neutron enough to still need to run inside of Neutron as they can't
> do everything they need to do by only interfacing with Neutron REST APIs
> (today, at least).
> 
>networking-l2gw:
>networking-sfc:
> 
> Here things start to get less clear to me.  Unless the only interaction
> with Neutron is via its REST API, 

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Doug Wiegley]

> On Nov 30, 2015, at 10:15 PM, Armando M. <arma...@gmail.com> wrote:
> 
> 
> 
> On 30 November 2015 at 20:47, Doug Wiegley <doug...@parksidesoftware.com 
> <mailto:doug...@parksidesoftware.com>> wrote:
> 
>> On Nov 30, 2015, at 5:56 PM, Armando M. <arma...@gmail.com 
>> <mailto:arma...@gmail.com>> wrote:
>> 
>> Hi folks,
>> 
>> The stadium concept was introduced more or less formally since April of this 
>> year. At the time it was introduced (see [1]), the list of deliverables 
>> included neutron, client, specs and *-aas services. As you may be well 
>> aware, 6+ months is a long time in the OpenStack world, and lots of things 
>> happened since then. The list has grown to [2]. 
>> 
>> When I think about what 'deliverables' are, I am inclined to think that all 
>> of the projects that are part of the list will have to behave and follow the 
>> same rules, provided that there is flexibility given by the tags. However, 
>> reality has proven us that rules are somewhat difficult to follow and 
>> enforce, and some boundaries may be too strict for some initiatives to 
>> comply with. This is especially true if we go from a handful of projects 
>> that we had when this had started to the nearly the two dozens we have now.
>> As a result, there is quite an effort imposed on the PTL, the various 
>> liaisons (release, infra, docs, testing, etc) and the core team to help 
>> manage the existing relationships and to ensure that the picture stays 
>> coherent over time. Sometimes the decision of being part of this list is 
>> even presented before one can see any code, and that defeats the whole point 
>> of the deliverable association. I have experienced first hand that this has 
>> become a burden, and I fear that the stadium might be an extra layer of 
>> governance/complexity that could even interfere with the existing 
>> responsibilities of the TC and of OpenStack infra.
>> 
>> So my question is: would revisiting/clarifying the concept be due after some 
>> time we have seen it in action? I would like to think so. To be fair, I am 
>> not sure what the right answer is, but I know for a fact that some 
>> iterations are in order, and I like to make a proposal:
>> 
>> I would like to suggest that we evolve the structure of the Neutron 
>> governance, so that most of the deliverables that are now part of the 
>> Neutron stadium become standalone projects that are entirely self-governed 
>> (they have their own core/release teams, etc). In order to denote the 
>> initiatives that are related to Neutron I would like to present two new tags 
>> that projects can choose to label themselves with:
>> 
> 
> Interesting proposal, and I’m just thinking out loud here. I’m generally in 
> favor of separating the governance as we separate the dependencies, just 
> because at some point what we’re doing doesn’t scale. To provide a little 
> context, there are two points worth keeping in mind:
> 
> - The neutron stadium actually slightly pre-dates the big tent, and works 
> around some earlier governance friction. So it may make less sense now in 
> light of those changes.
> 
> If my memory doesn't fail me, the first time I recall of talks about the big 
> tent is September 2014, in this email thread:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html 
> <http://lists.openstack.org/pipermail/openstack-dev/2014-September/046437.html>
> 
> So, no I don't think we were a novelty :)
>  
> 
> - Many of the neutron subprojects *MUST RELEASE IN LOCKSTEP WITH NEUTRON* to 
> be useful. These items are less useful to be considered standalone, as they 
> need general oversight, co-gating, and such, to stay sane. As we break the 
> massive coupling that exists, this point will get less and less relevant. 
> 
> I don't think that requires the oversight of a single individual, but you're 
> right that this point will fade away over time.
>  
> 
> - I think that part of the initial intent was that these small subprojects 
> would have their own core teams, but be able to take advantage of the 
> infrastructure that exists around neutron as a whole (specs, release team, 
> stable team, co-gates, mentors).
> 
> For your proposal, are you suggesting:
> 
> 1. That these projects are fully separate, with their own PTLs and 
> everything, and just have tags that imply their neutron dependency?  OR,
> 
> My point is: the project decides what's best, I don't have to have an opinion 
> :)

I don’t think you *have* to have an opinion in either scheme. That sounds 
self-imposed. Delegate it.

> 
&g

[openstack-dev] [neutron][lbaas][fwaas] mitaka mid-cycle 1/12-1/15

[Doug Wiegley]

Hi all,

The LBaaS/Octavia/FWaaS mid-cycle will be in San Antonio this winter, from 
January 12-15.

Etherpad with details;

https://etherpad.openstack.org/p/lbaas-mitaka-midcycle

Please update if you are going to attend, so our host can get an accurate 
headcount. Hope to see you there!

Thanks,
doug



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

Re: [openstack-dev] [lbaas] [octavia] Proposing Bertrand Lallau as Octavia Core

[Doug Wiegley]

+1

> On Nov 19, 2015, at 11:39 AM, Brandon Logan  
> wrote:
> 
> +1
> 
> On Thu, 2015-11-19 at 17:35 +, Eichberger, German wrote:
>> All,
>> 
>> 
>> 
>> As I said in a previous e-mail I am really excited about the deep talent in 
>> the Octavia sub-project. So it is my pleasure to propose Bertrand Lallau 
>> (irc blallau) as a new core for the OpenStack Neutron Octavia sub project. 
>> His contributions [1] are in line with other cores and he has been an active 
>> member of our community. Current cores please vote by replying to this 
>> e-mail.
>> 
>> Thanks,
>> German 
>> 
>> 
>> [1] http://stackalytics.com/?project_type=openstack=octavia
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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