Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/29/2015 09:19 PM, Jeremy Stanley wrote:
> On 2015-04-29 16:46:13 -0700 (-0700), Joe Gordon wrote:
>> On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery  wrote:
>>> On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
> [...]
 1) Project governance has moved to a "big tent" model [1].  The vast
 majority of projects that used to be in Stackforge are being folded in
>>>
>> I think the phrase 'vast majority' is misleading, there are still a lot of
>> projects on stackforge.
> [...]
> 
> Even the word "majority" is incorrect, at least for the moment.
> Ignoring openstack-attic and stackforge-attic, of the 627
> non-retired git repositories hosted in our infrastructure, 55% are
> stackforge and 45% are openstack.*.
> 
> ssh -p 29418 review.openstack.org gerrit ls-projects \
> |cut -d/ -f1|sort|uniq -c
> 
> The majority (by any sense of the word) are currently still squarely
> stackforge. Once all the chef cookbooks and puppet modules switch
> then the percentages there invert, but I have to agree with Joe that
> it's by no means "vast" even then. If all the fuel repos also move
> then that brings us to a 60/40 split in favor of openstack. Maybe
> that starts to count as vast?
> 
> Regardless, the stackforge/networking-.* repos only make up 3% of
> the total count.

I apologize for the poor choice of words "vast majority".

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Jeremy Stanley]

On 2015-04-29 16:46:13 -0700 (-0700), Joe Gordon wrote:
> On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery  wrote:
> > On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
[...]
> >> 1) Project governance has moved to a "big tent" model [1].  The vast
> >> majority of projects that used to be in Stackforge are being folded in
> >
> I think the phrase 'vast majority' is misleading, there are still a lot of
> projects on stackforge.
[...]

Even the word "majority" is incorrect, at least for the moment.
Ignoring openstack-attic and stackforge-attic, of the 627
non-retired git repositories hosted in our infrastructure, 55% are
stackforge and 45% are openstack.*.

ssh -p 29418 review.openstack.org gerrit ls-projects \
|cut -d/ -f1|sort|uniq -c

The majority (by any sense of the word) are currently still squarely
stackforge. Once all the chef cookbooks and puppet modules switch
then the percentages there invert, but I have to agree with Joe that
it's by no means "vast" even then. If all the fuel repos also move
then that brings us to a 60/40 split in favor of openstack. Maybe
that starts to count as vast?

Regardless, the stackforge/networking-.* repos only make up 3% of
the total count.
-- 
Jeremy Stanley

__
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] A big tent home for Neutron backend code

[loy wolfe]

On Thu, Apr 30, 2015 at 2:44 AM, Russell Bryant  wrote:
> On 04/29/2015 01:25 PM, Doug Wiegley wrote:
>> My take on the “where does it fit” yardstick:
>>
>> Does it stand on its own and add value? Then consider it a standalone
>> project, *or* part of neutron if you and neutron agree that it fits.
>>
>> Does it *require* neutron to be useful? Then consider having it under
>> the neutron umbrella/stadium/tent/yurt.
>
> ...arena/coliseum/dome...
>
> That's a nice summary.  Thanks.  :-)
>
> --
> Russell Bryant
>
>

By this definition, nearly all standalone SDN controller would not be
classified as neutron tent (including OVN by its design doc), because
they are not born for neutron at all. It seems that the only exception
is ofagent.

While most hardware MD can be treated as under neutron tent, for they
just do one thing: driver hardware on behalf on neutron.

__
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] A big tent home for Neutron backend code

[Joe Gordon]

On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery  wrote:

> On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
> wrote:
>
>> Hello!
>>
>> A couple of things I've been working on lately are project governance
>> issues as a TC member and also implementation of a new virtual
>> networking alternative with a Neutron driver.  So, naturally I started
>> thinking about how the Neutron driver code fits in to OpenStack
>> governance.
>>
>> Thanks for starting this conversation Russell.
>
>
>> There are basically two areas with a lot of movement related to this
>> issue.
>>
>> 1) Project governance has moved to a "big tent" model [1].  The vast
>> majority of projects that used to be in Stackforge are being folded in
>>
>
I think the phrase 'vast majority' is misleading, there are still a lot of
projects on stackforge.


> to a larger definition of the OpenStack project.  Projects making this
>> move meet the following criteria as being "one of us":
>>
>> http://governance.openstack.org/reference/new-projects-requirements.html
>>
>> Official project teams are tracked in this file along with the git repos
>> they are responsible for:
>>
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>
>> which is also reflected here:
>>
>> http://governance.openstack.org/reference/projects/
>>
>> The TC has also been working through defining a system to help
>> differentiate efforts by using a set of "tags" [4].  So far, we have
>> tags describing the release handling for a repository, as well as a tag
>> for team diversity.  We've also had a lot of discussion about tags to
>> help describe maturity, but that is still a work in progress.
>>
>>
>> 2) In Neutron, some fairly significant good changes are being made to
>> help scale the development process.  Advanced services were split out
>> into their own repos [2].  Most of the plugin and driver code has also
>> been split out into repos [3].
>>
>> In terms of project teams, the Neutron team is defined as owning the
>> following repos:
>>
>>   http://governance.openstack.org/reference/projects/neutron.html
>>
>>  - openstack/neutron
>>  - openstack/neutron-fwaas
>>  - openstack/neutron-lbaas
>>  - openstack/neutron-vpnaas
>>  - openstack/neutron-specs
>>  - openstack/python-neutronclient
>>
>> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
>> repos.
>>
>> We also have a large set of repositories related to Neutron backend code:
>>
>>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>>
>>  - stackforge/networking-arista
>>  - stackforge/networking-bagpipe-l2
>>  - stackforge/networking-bgpvpn
>>  - stackforge/networking-bigswitch
>>  - stackforge/networking-brocade
>>  - stackforge/networking-cisco
>>  - stackforge/networking-edge-vpn
>>  - stackforge/networking-hyperv
>>  - stackforge/networking-ibm
>>  - stackforge/networking-l2gw
>>  - stackforge/networking-midonet
>>  - stackforge/networking-mlnx
>>  - stackforge/networking-nec
>>  - stackforge/networking-odl
>>  - stackforge/networking-ofagent
>>  - stackforge/networking-ovn
>>  - stackforge/networking-ovs-dpdk
>>  - stackforge/networking-plumgrid
>>  - stackforge/networking-portforwarding
>>  - stackforge/networking-vsphere
>>
>> Note that not all of these are equivalent.  This is just a list of
>> stackforge/networking-*.
>>
>> In some cases there is a split between code in the Neutron tree and in
>> this repo.  In those cases, a shim is in the Neutron tree, but most of
>> the code is in the external repo.  It's also possible to have all of the
>> code in the external repo.
>>
>> There's also a big range of maturity.  Some are quite mature and are
>> already used in production.  networking-ovn as an example is quite new
>> and being developed in parallel with OVN in the Open vSwitch project.
>>
>>
>> So, my question is: Where should these repositories live in terms of
>> OpenStack governance and project teams?
>>
>> Here are a few paths I think we could take, along with some of my
>> initial thoughts on pros/cons.
>>
>> a) Adopt these as repositories under the Neutron project team.
>>
>> In this case, I would see them operating with their own review teams as
>> they do today to avoid imposing additional load on the neutron-core or
>> neutron-specs-core teams.  However, by being a part of the Neutron team,
>> the backend team would submit to oversight by the Neutron PTL.
>>
>> Out of your options proposed, this seems like the most logical one to me.
> I don't really see this imposing a ton of strain on the existing core
> reviewer team, because we'll keep whatever core reviewer teams are already
> in the networking-foo projects.
>
>
>> There are some other details to work out to ensure expectations are
>> clearly set for everyone involved.  If this is the path that makes
>> sense, we can work through those as a next step.
>>
>> Pros:
>>  + Seems to be the most natural first choice
>>
>
Saying something is your first choice isn't a real benefit.  It is imply

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/29/2015 01:25 PM, Doug Wiegley wrote:
> My take on the “where does it fit” yardstick:
> 
> Does it stand on its own and add value? Then consider it a standalone
> project, *or* part of neutron if you and neutron agree that it fits.
> 
> Does it *require* neutron to be useful? Then consider having it under
> the neutron umbrella/stadium/tent/yurt.

...arena/coliseum/dome...

That's a nice summary.  Thanks.  :-)

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Doug Wiegley]

My take on the “where does it fit” yardstick:

Does it stand on its own and add value? Then consider it a standalone project, 
*or* part of neutron if you and neutron agree that it fits.

Does it *require* neutron to be useful? Then consider having it under the 
neutron umbrella/stadium/tent/yurt.

Thanks,
doug


> On Apr 29, 2015, at 10:33 AM, neil.jer...@metaswitch.com wrote:
> 
> ‎Thanks Russell and Kyle for explaining. I think I get the picture now, in 
> particular of how these backend projects are mostly under separate 
> management, but at the same time subject to PTL oversight and 'part of the 
> wider Neutron effort'.
> 
> May I drill down further on what is anticipated, though, by considering what 
> this might mean for my own project, Calico?‎ I don't mean to self-advertise, 
> but it's obviously the example that I know best! :-)
> 
> Calico is a (potential) way of using Neutron for networking in an OpenStack 
> deployment. But it's also broader than that, because it also targets 
> (non-OpenStack-based) container systems. So it wouldn't be right to propose 
> moving the whole ‎of project Calico to be one of these Neutron backend 
> projects. 
> 
> When Calico is used with Neutron, it takes the form of an ML2 mechanism 
> driver. So perhaps that mechanism driver might be what would go into a 
> networking-calico project? However,
> 
> - the wonderful workings of the entry_points mechanism, combined with the 
> existence of a stable API for mechanism drivers, mean that we don't strongly 
> need to do that; and
> 
> - on its non-OpenStack-facing side, our mechanism driver's implementation 
> shares common code with other pieces in the wider Calico project. 
> 
> So it's not really compelling ‎to move the mechanism driver to a 
> networking-calico project either - even though we do want to advertise and 
> evangelise about Calico working with Neutron. 
> 
> So what then could go into a networking-calico project? Perhaps some 
> OpenStack ecosystem documentation about using Calico in OpenStack, and/or 
> perhaps some utilities that were specific to both Calico and the OpenStack 
> environment? 
> 
> Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd 
> really appreciate further comments and/or corrections to my understanding so 
> far. I would guess that what I've raised might apply similarly to other big‎ 
> networking projects, for example Open Daylight. 
> 
> Many thanks, 
> Neil
> 
> PS. As I'm just about to send this, I wonder if our DHCP agent modifications 
> might be a good example... Something that is definitely OpenStack-specific, 
> but not yet clear if and how our changes should be folded into the main 
> Neutron code. Perhaps that is the kind of thing that you have in mind? 
> 
> 
> 
>   Original Message  
> ‎
> From: Russell Bryant‎
> Sent: Tuesday, 28 April 2015 18:57
> To: openstack-dev@lists.openstack.org
> Reply To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend 
> code
> 
> On 04/28/2015 01:17 PM, Neil Jerram wrote:
>> Apologies for commenting so late, but I'm not clear on the concept of
>> bringing all possible backend projects back inside Neutron.
>> 
>> 
>> I think my question is similar to what Henry and Mathieu are getting at
>> below - viz:
>> 
>> 
>> We just recently decided to move a lot of vendor-specific ML2 mechanism
>> driver code _out_ of the Neutron tree; and I thought that the main
>> motivation for that was that it wasn't reasonably possible for most
>> Neutron developers to understand, review and maintain that code to the
>> same level as they can with the Neutron core code.
>> 
>> 
>> How then does it now make sense to bring a load of vendor-specific code
>> back into the Neutron fold? Has some important factor changed? Or have
>> I misunderstood what is now being proposed?
> 
> The suggestion is to recognize that these are all part of the larger
> Neutron effort. It is *not* to suggest that the same group of
> developers needs to be reviewing all of it. It's mostly an
> organizational thing. The way teams operate should not change too much.
> 
> -- 
> Russell Bryant
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
&

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/29/2015 12:33 PM, neil.jer...@metaswitch.com wrote:
> ‎Thanks Russell and Kyle for explaining. I think I get the picture
> now, in particular of how these backend projects are mostly under
> separate management, but at the same time subject to PTL oversight
> and 'part of the wider Neutron effort'.
> 
> May I drill down further on what is anticipated, though, by
> considering what this might mean for my own project, Calico?‎ I don't
> mean to self-advertise, but it's obviousl,  the example that I know
> best! :-)
> 
> Calico is a (potential) way of using Neutron for networking in an
> OpenStack deployment. But it's also broader than that, because it
> also targets (non-OpenStack-based) container systems. So it wouldn't
> be right to propose moving the whole ‎of project Calico to be one of
> these Neutron backend projects.

Right.  Calico itself is something separate.  It's analagous to
OpenDaylight, OVN, or others.  There's a separate project elsewhere
implementing the core of the technology.  What makes sense to be in
Neutron is just the plugin/driver/agents needed to integrate Neutron
with that technology.

> When Calico is used with Neutron, it takes the form of an ML2
> mechanism driver. So perhaps that mechanism driver might be what
> would go into a networking-calico project? However,

Yes.

> - the wonderful workings of the entry_points mechanism, combined with
> the existence of a stable API for mechanism drivers, mean that we
> don't strongly need to do that; and

Right, you certainly don't have to.  It's optional.

You have to do things "the OpenStack way" when it comes to your
processes.  You submit to TC and Neutron PTL oversight.  The benefit is
that you're more closely associated with OpenStack and the Neutron
project.  I also hope that the groups included in the larger Neutron
effort officially make some increased effort to collaborate with each
other and the core Neutron project.

> - on its non-OpenStack-facing side, our mechanism driver's
> implementation shares common code with other pieces in the wider
> Calico project.

That's not a big deal.  Your driver can have custom dependencies.
Presumably there's still some separation between what's Neutron driver
code, and what's calico library code.

> So it's not really compelling ‎to move the mechanism driver to a
> networking-calico project either - even though we do want to
> advertise and evangelise about Calico working with Neutron.

Well, it's up to you, but I'm not convinced there's a technical reason
not to do it based on the above description.  I'm not really here to
push one way or the other.  I just want to help guide a discussion and
understanding.

> So what then could go into a networking-calico project? Perhaps some
> OpenStack ecosystem documentation about using Calico in OpenStack,
> and/or perhaps some utilities that were specific to both Calico and
> the OpenStack environment?
> 
> Perhaps I'm going down an unnecessary rabbit hole with this musing -
> but I'd really appreciate further comments and/or corrections to my
> understanding so far. I would guess that what I've raised might apply
> similarly to other big‎ networking projects, for example Open
> Daylight.
> 
> Many thanks, Neil
> 
> PS. As I'm just about to send this, I wonder if our DHCP agent
> modifications might be a good example... Something that is definitely
> OpenStack-specific, but not yet clear if and how our changes should
> be folded into the main Neutron code. Perhaps that is the kind of
> thing that you have in mind?

These modifications sound like a separate issue.  If you have
modifications to the DHCP agent, it makes sense to work with others in
the Neutron team to figure out how to make it generic enough that the
changes could be accepted.

I suppose the alternative is carrying your own DHCP agent, and it sounds
like that's what you're doing now.  However, I think collaboration
around this to either upstream your changes or at least figure out what
code can be shared is ideal, wherever that makes sense.  If you continue
with your own agent that is OpenStack specific, that's something that
makes sense to be in a "networking-calico" repo, IMO.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Neil.Jerram]

‎Thanks Russell and Kyle for explaining. I think I get the picture now, in 
particular of how these backend projects are mostly under separate management, 
but at the same time subject to PTL oversight and 'part of the wider Neutron 
effort'.

May I drill down further on what is anticipated, though, by considering what 
this might mean for my own project, Calico?‎ I don't mean to self-advertise, 
but it's obviously the example that I know best! :-)

Calico is a (potential) way of using Neutron for networking in an OpenStack 
deployment. But it's also broader than that, because it also targets 
(non-OpenStack-based) container systems. So it wouldn't be right to propose 
moving the whole ‎of project Calico to be one of these Neutron backend 
projects. 

When Calico is used with Neutron, it takes the form of an ML2 mechanism driver. 
So perhaps that mechanism driver might be what would go into a 
networking-calico project? However,

- the wonderful workings of the entry_points mechanism, combined with the 
existence of a stable API for mechanism drivers, mean that we don't strongly 
need to do that; and

- on its non-OpenStack-facing side, our mechanism driver's implementation 
shares common code with other pieces in the wider Calico project. 

So it's not really compelling ‎to move the mechanism driver to a 
networking-calico project either - even though we do want to advertise and 
evangelise about Calico working with Neutron. 

So what then could go into a networking-calico project? Perhaps some OpenStack 
ecosystem documentation about using Calico in OpenStack, and/or perhaps some 
utilities that were specific to both Calico and the OpenStack environment? 

Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd 
really appreciate further comments and/or corrections to my understanding so 
far. I would guess that what I've raised might apply similarly to other big‎ 
networking projects, for example Open Daylight. 

Many thanks, 
    Neil

PS. As I'm just about to send this, I wonder if our DHCP agent modifications 
might be a good example... Something that is definitely OpenStack-specific, but 
not yet clear if and how our changes should be folded into the main Neutron 
code. Perhaps that is the kind of thing that you have in mind? 



  Original Message  
‎
From: Russell Bryant‎
Sent: Tuesday, 28 April 2015 18:57
To: openstack-dev@lists.openstack.org
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On 04/28/2015 01:17 PM, Neil Jerram wrote:
> Apologies for commenting so late, but I'm not clear on the concept of
> bringing all possible backend projects back inside Neutron.
> 
> 
> I think my question is similar to what Henry and Mathieu are getting at
> below - viz:
> 
> 
> We just recently decided to move a lot of vendor-specific ML2 mechanism
> driver code _out_ of the Neutron tree; and I thought that the main
> motivation for that was that it wasn't reasonably possible for most
> Neutron developers to understand, review and maintain that code to the
> same level as they can with the Neutron core code.
> 
> 
> How then does it now make sense to bring a load of vendor-specific code
> back into the Neutron fold? Has some important factor changed? Or have
> I misunderstood what is now being proposed?

The suggestion is to recognize that these are all part of the larger
Neutron effort. It is *not* to suggest that the same group of
developers needs to be reviewing all of it. It's mostly an
organizational thing. The way teams operate should not change too much.

-- 
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] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Tue, Apr 28, 2015 at 8:00 AM, Russell Bryant  wrote:

> On 04/27/2015 08:52 PM, Armando M. wrote:
> >
> > Any project that fails to meet the criteria later can be dropped at
> any
> > time.  For example, if some repo is clearly unmaintained, it can be
> > removed.
> >
> >
> > If we open the door to excluding projects down the road, then wouldn't
> > we need to take into account some form of 3rd party CI validation as
> > part of the criteria to 'ensure quality' (or lack thereof)? Would you
> > consider that part of the inclusion criteria too?
>
> My suggestion would be to use the state of 3rd party CI validation in
> whatever is used to indicate the current level of maturity, but not to
> directly decide what's considered in the OpenStack Neutron project.
>
> If we take networking-ovn as an example, it's very actively developed
> and certainly "one of us", in my opinion.  It has CI jobs, but they're
> not running tempest yet.  It seems wrong to say it's not an OpenStack
> project because of that.  What we need is to be able to clearly
> communicate that it's very new and immature, which is something different.
>
> For something that has been around much longer and has had CI fully
> working, I would view it a bit different.  If the tests break and stay
> broken for a long time, that sounds like an early indicator that the
> code is unmaintained and may get dropped and moved to "openstack-attic"
> at some point.
>
>
I think in general, outside the scope of this discussion, third-party CI
needs some re-thinking in Neutron. We currently have no automated way to
validate any of it, so it's a best effort affair. Perhaps discussing this
at the Summit would be something useful to do in person, I'll add that to
the agenda.

Thanks,
Kyle


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Mon, Apr 27, 2015 at 3:58 PM, Russell Bryant  wrote:

> On 04/22/2015 02:19 PM, Russell Bryant wrote:
> > a) Adopt these as repositories under the Neutron project team.
> >
> > In this case, I would see them operating with their own review teams as
> > they do today to avoid imposing additional load on the neutron-core or
> > neutron-specs-core teams.  However, by being a part of the Neutron team,
> > the backend team would submit to oversight by the Neutron PTL.
> >
> > There are some other details to work out to ensure expectations are
> > clearly set for everyone involved.  If this is the path that makes
> > sense, we can work through those as a next step.
>
> Based on the feedback on this thread so far, this seems like the best
> choice.  I said I'd come back with some more proposed details, so here
> we are.  Let me know what seems off or missing here.
>
>
> 1) Process
>
> The process for proposing the move of a repo into openstack/ and under
> the Neutron project is to propose a patch to the openstack/governance
> repository.  For example, if I were proposing moving networking-ovn, I
> would add the following entry under Neutron in reference/projects.yaml:
>
> - repo: openstack/networking-ovn
>   tags:
> - name: release:independent
>
> For more information about the release:independent tag (and other
> currently defined tags) see:
>
> http://governance.openstack.org/reference/tags/
>
> The Neutron PTL must approve the change.  The TC clarified that once a
> project has been approved (Neutron in this case), the project can add
> additional repos without needing TC approval as long as the added
> repositories are within the existing approved scope of the project.
>
>
>
> http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d
>
>
> 2) Responsibilities
>
> All affected repositories already have their own review teams.  The
> sub-team working on the sub-project is entirely responsible for
> day-to-day development.  That includes reviews, bug tracking, and
> working on testing.
>
> By being included, the project accepts oversight by the TC as a part of
> being in OpenStack, and also accepts oversight by the Neutron PTL.
>
>
> 3) Criteria
>
> As mentioned before, the Neutron PTL must approve the inclusion of each
> additional repository under the Neutron project.  I suggest that the
> primary criteria used should be the same as what the TC uses for new
> OpenStack projects, at least where it makes sense:
>
> http://governance.openstack.org/reference/new-projects-requirements.html
>
> One detail that I expect might be controversial is around maturity.  I
> think it's important that we recognize and embrace that from the very
> beginning of many projects, they are indeed "one of us", even if it's
> early in the development process.  We should *not* be using that as
> entry criteria into what's considered OpenStack.
>
> Instead, we should be looking to define project metadata to help people
> understand what things are, including their features, limitations, and
> maturity level.  The tags system being used by the TC is intended to
> address this at an OpenStack-wide level.  Some additional work could be
> done specific to Neutron, just with a page that lists backends and
> information about them.
>
> Any project that fails to meet the criteria later can be dropped at any
> time.  For example, if some repo is clearly unmaintained, it can be
> removed.
>
>
I'm +1 for all of this. Thanks for driving this Russell!


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Tue, Apr 28, 2015 at 12:17 PM, Neil Jerram 
wrote:

>  Apologies for commenting so late, but I'm not clear on the concept of
> bringing all possible backend projects back inside Neutron.
>
>
>  I think my question is similar to what Henry and Mathieu are getting at
> below - viz:
>
>
>  We just recently decided to move a lot of vendor-specific ML2 mechanism
> driver code _out_ of the Neutron tree; and I thought that the main
> motivation for that was that it wasn't reasonably possible for most Neutron
> developers to understand, review and maintain that code to the same level
> as they can with the Neutron core code.
>
>
>  How then does it now make sense to bring a load of vendor-specific code
> back into the Neutron fold?  Has some important factor changed?  Or have I
> misunderstood what is now being proposed?
>
>
>
I think you're confusing where the code lives with which core team reviews
it and merges code. The reason for moving the backend logic code out was so
the respective vendor or open source team could review and merge code in
those trees. What we're talking about here is where those repositories
live. They would not fall under the neutron core review team. They would
simply defer to being governed by OpenStack governance, namely the Neutron
PTL.

Thanks,
Kyle

>  Many thanks,
>
> Neil
>
>
>  --
> *From:* Mathieu Rohon 
> *Sent:* 23 April 2015 15:05
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] A big tent home for Neutron
> backend code
>
>
>
> On Thu, Apr 23, 2015 at 10:28 AM, henry hly  wrote:
>
>> On Thu, Apr 23, 2015 at 10:44 AM, Armando M.  wrote:
>> >>
>> >> Could you please also pay some attention on Cons of this ultimate
>> >> splitting Kyle? I'm afraid it would hurt the user experiences.
>> >>
>> >> On the position of Dev, A naked Neutron without "official" built-in
>> >> reference implementation probably has a more clear architecture. On
>> >> the other side, users would be forced to make choice between a long
>> >> list of backend implementations, which is very difficult for
>> >> non-professionals.
>> >>
>> >> In most of the time, users need a off-the-shelf solution without
>> >> paying much extra integration effort, and they have less interest to
>> >> study which SDN controller is powerful and is better than others. Can
>> >> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
>> >> volume driver [See Deployment Profiles section in 1a] ? Shall we
>> >> really decide to make Neutron the only Openstack project which has not
>> >> any in tree official implementation?
>> >
>> >
>> > I think the analogy here is between the agent reference implementation
>> vs
>> > KVM or Ceph, rather than the plumbing that taps into the underlying
>> > technology. Nova doesn't build/package KVM as Cinder doesn't
>> build/package
>> > Ceph. Neutron could rely on other open source solutions (ODL,
>> OpenContrail,
>> > OVN, etc), and still be similar to the other projects.
>> >
>> > I think there's still room for clarifying what the split needs to be,
>> but I
>> > have always seen Neutron as the exception rather than norm, where, for
>> > historic reasons, we had to build everything from the ground up for
>> lack of
>> > viable open source solutions at the time the project was conceived.
>> >
>>
>> Thanks for bring in this interesting topic, maybe it should not be
>> scoped only inside Neutron, also I found a similar discuss from John
>> griffith on Cinder vs SDS controller :-)
>>
>>
>> https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/
>>
>> It's clear that an typical Cloud deployment is composed of two
>> distinct part: workload engine vs. supervisor. The engine part
>> obviously do not belong to Openstack project, which include open
>> sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
>> like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
>> hardware gears or virtualized service VMs.
>>
>> However for the supervisor part, there is some blurring for debates:
>> Should Openstack provide complete in-house implementation of
>> controlling functions which could directly drive backend workload
>> engine (via backend driver), or just thin API/DB layer which need to
>> integrate some 3rd ex

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/28/2015 01:17 PM, Neil Jerram wrote:
> Apologies for commenting so late, but I'm not clear on the concept of
> bringing all possible backend projects back inside Neutron.
> 
> 
> I think my question is similar to what Henry and Mathieu are getting at
> below - viz:
> 
> 
> We just recently decided to move a lot of vendor-specific ML2 mechanism
> driver code _out_ of the Neutron tree; and I thought that the main
> motivation for that was that it wasn't reasonably possible for most
> Neutron developers to understand, review and maintain that code to the
> same level as they can with the Neutron core code.
> 
> 
> How then does it now make sense to bring a load of vendor-specific code
> back into the Neutron fold?  Has some important factor changed?  Or have
> I misunderstood what is now being proposed?

The suggestion is to recognize that these are all part of the larger
Neutron effort.  It is *not* to suggest that the same group of
developers needs to be reviewing all of it.  It's mostly an
organizational thing.  The way teams operate should not change too much.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Neil Jerram]

Apologies for commenting so late, but I'm not clear on the concept of bringing 
all possible backend projects back inside Neutron.


I think my question is similar to what Henry and Mathieu are getting at below - 
viz:


We just recently decided to move a lot of vendor-specific ML2 mechanism driver 
code _out_ of the Neutron tree; and I thought that the main motivation for that 
was that it wasn't reasonably possible for most Neutron developers to 
understand, review and maintain that code to the same level as they can with 
the Neutron core code.


How then does it now make sense to bring a load of vendor-specific code back 
into the Neutron fold?  Has some important factor changed?  Or have I 
misunderstood what is now being proposed?


Many thanks,

Neil



From: Mathieu Rohon 
Sent: 23 April 2015 15:05
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code



On Thu, Apr 23, 2015 at 10:28 AM, henry hly 
mailto:henry4...@gmail.com>> wrote:
On Thu, Apr 23, 2015 at 10:44 AM, Armando M. 
mailto:arma...@gmail.com>> wrote:
>>
>> Could you please also pay some attention on Cons of this ultimate
>> splitting Kyle? I'm afraid it would hurt the user experiences.
>>
>> On the position of Dev, A naked Neutron without "official" built-in
>> reference implementation probably has a more clear architecture. On
>> the other side, users would be forced to make choice between a long
>> list of backend implementations, which is very difficult for
>> non-professionals.
>>
>> In most of the time, users need a off-the-shelf solution without
>> paying much extra integration effort, and they have less interest to
>> study which SDN controller is powerful and is better than others. Can
>> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
>> volume driver [See Deployment Profiles section in 1a] ? Shall we
>> really decide to make Neutron the only Openstack project which has not
>> any in tree official implementation?
>
>
> I think the analogy here is between the agent reference implementation vs
> KVM or Ceph, rather than the plumbing that taps into the underlying
> technology. Nova doesn't build/package KVM as Cinder doesn't build/package
> Ceph. Neutron could rely on other open source solutions (ODL, OpenContrail,
> OVN, etc), and still be similar to the other projects.
>
> I think there's still room for clarifying what the split needs to be, but I
> have always seen Neutron as the exception rather than norm, where, for
> historic reasons, we had to build everything from the ground up for lack of
> viable open source solutions at the time the project was conceived.
>

Thanks for bring in this interesting topic, maybe it should not be
scoped only inside Neutron, also I found a similar discuss from John
griffith on Cinder vs SDS controller :-)

https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/

It's clear that an typical Cloud deployment is composed of two
distinct part: workload engine vs. supervisor. The engine part
obviously do not belong to Openstack project, which include open
sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
hardware gears or virtualized service VMs.

However for the supervisor part, there is some blurring for debates:
Should Openstack provide complete in-house implementation of
controlling functions which could directly drive backend workload
engine (via backend driver), or just thin API/DB layer which need to
integrate some 3rd external controller projects to finish those works:
scheduling, pooling and service logic abstraction? For networking, how
should we regard the functions of plugin/agent and SDN controller, are
they classified in the same layer of "real" backends working engine
like Switchs/Routers/Firewalls?

For Nova & Cinder, it seems former is adopted: a single unified
central framework including API, scheduling, abstraction service
logic, rpc & message queue, and a common agent side framework of
compute/volume manager, then with a bunch of virt/volume drivers
plugged to abstract the all kinds of backends. There are standalone
backends like KVM and LVM, and aggregated clustering backends like
vcenter and ceph.

The Neutron was just like a developing game of continuously
re-factoring: plugin, meta plugin, ML2, and now the "platform". Next
ML2 plugin suddenly became just a "reference" for concept proving, and
no plugin/agent would be maintained in-tree officially anymore, while
the reason is confusingly "not to compete with other 3rd SDN
controllers" :-P

I agree with henry here.
Arma

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/27/2015 08:52 PM, Armando M. wrote:
> 
> Any project that fails to meet the criteria later can be dropped at any
> time.  For example, if some repo is clearly unmaintained, it can be
> removed.
> 
> 
> If we open the door to excluding projects down the road, then wouldn't
> we need to take into account some form of 3rd party CI validation as
> part of the criteria to 'ensure quality' (or lack thereof)? Would you
> consider that part of the inclusion criteria too?

My suggestion would be to use the state of 3rd party CI validation in
whatever is used to indicate the current level of maturity, but not to
directly decide what's considered in the OpenStack Neutron project.

If we take networking-ovn as an example, it's very actively developed
and certainly "one of us", in my opinion.  It has CI jobs, but they're
not running tempest yet.  It seems wrong to say it's not an OpenStack
project because of that.  What we need is to be able to clearly
communicate that it's very new and immature, which is something different.

For something that has been around much longer and has had CI fully
working, I would view it a bit different.  If the tests break and stay
broken for a long time, that sounds like an early indicator that the
code is unmaintained and may get dropped and moved to "openstack-attic"
at some point.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
>
> Any project that fails to meet the criteria later can be dropped at any
> time.  For example, if some repo is clearly unmaintained, it can be
> removed.
>

If we open the door to excluding projects down the road, then wouldn't we
need to take into account some form of 3rd party CI validation as part of
the criteria to 'ensure quality' (or lack thereof)? Would you consider that
part of the inclusion criteria too?


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/22/2015 02:19 PM, Russell Bryant wrote:
> a) Adopt these as repositories under the Neutron project team.
> 
> In this case, I would see them operating with their own review teams as
> they do today to avoid imposing additional load on the neutron-core or
> neutron-specs-core teams.  However, by being a part of the Neutron team,
> the backend team would submit to oversight by the Neutron PTL.
> 
> There are some other details to work out to ensure expectations are
> clearly set for everyone involved.  If this is the path that makes
> sense, we can work through those as a next step.

Based on the feedback on this thread so far, this seems like the best
choice.  I said I'd come back with some more proposed details, so here
we are.  Let me know what seems off or missing here.


1) Process

The process for proposing the move of a repo into openstack/ and under
the Neutron project is to propose a patch to the openstack/governance
repository.  For example, if I were proposing moving networking-ovn, I
would add the following entry under Neutron in reference/projects.yaml:

- repo: openstack/networking-ovn
  tags:
- name: release:independent

For more information about the release:independent tag (and other
currently defined tags) see:

http://governance.openstack.org/reference/tags/

The Neutron PTL must approve the change.  The TC clarified that once a
project has been approved (Neutron in this case), the project can add
additional repos without needing TC approval as long as the added
repositories are within the existing approved scope of the project.


http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d


2) Responsibilities

All affected repositories already have their own review teams.  The
sub-team working on the sub-project is entirely responsible for
day-to-day development.  That includes reviews, bug tracking, and
working on testing.

By being included, the project accepts oversight by the TC as a part of
being in OpenStack, and also accepts oversight by the Neutron PTL.


3) Criteria

As mentioned before, the Neutron PTL must approve the inclusion of each
additional repository under the Neutron project.  I suggest that the
primary criteria used should be the same as what the TC uses for new
OpenStack projects, at least where it makes sense:

http://governance.openstack.org/reference/new-projects-requirements.html

One detail that I expect might be controversial is around maturity.  I
think it's important that we recognize and embrace that from the very
beginning of many projects, they are indeed "one of us", even if it's
early in the development process.  We should *not* be using that as
entry criteria into what's considered OpenStack.

Instead, we should be looking to define project metadata to help people
understand what things are, including their features, limitations, and
maturity level.  The tags system being used by the TC is intended to
address this at an OpenStack-wide level.  Some additional work could be
done specific to Neutron, just with a page that lists backends and
information about them.

Any project that fails to meet the criteria later can be dropped at any
time.  For example, if some repo is clearly unmaintained, it can be removed.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
> If we've reached the point where we're arguing about naming, dos this mean
>> we've built consensus on the "yes, it makes sense for these to live under
>> Neutron" argument?
>>
>
>
I think we are in agreement that these projects need to find a more obvious
home, they feel somewhat orphan otherwise. Most of them are extensions or
plugins to Neutron and since they cannot stand alone, it makes sense to
have them associated with it. As far as I am concerned I think the matter
is about the inclusion methodology as well as the timing.

Cheers,
Armando
__
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] A big tent home for Neutron backend code

[Jeremy Stanley]

On 2015-04-23 12:45:14 -0700 (-0700), Joshua Harlow wrote:
> Maybe about time we make something like:
> 
> http://projects.apache.org/indexes/category.html
> 
> And link names to repos there...?

http://governance.openstack.org/reference/projects/ is sort of our
analogue there, I think. It's not exact, but each project subpage
lists and links to the various Git repositories it encompasses along
with descriptive tag metadata (and growing richer every week).
-- 
Jeremy Stanley

__
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] A big tent home for Neutron backend code

[Salvatore Orlando]

Doug, HMS Octavia was a British mine sweeper that served during WW2
figthing German warships and u-boats somewhere in the sea.
I therefore believe if you have anything against this name you are secretly
a nazi.

Does that work for the Godwin's law call?

Salvatore

On 23 April 2015 at 22:09, Doug Wiegley 
wrote:

>
> > On Apr 23, 2015, at 1:42 PM, Russell Bryant  wrote:
> >
> > On 04/23/2015 03:23 PM, Kyle Mestery wrote:
> >> On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
> >> mailto:doug...@parksidesoftware.com>>
> wrote:
> >>
> >>
> >>> On Apr 23, 2015, at 11:57 AM, Russell Bryant  >>> wrote:
> >>>
> >>> On 04/23/2015 01:19 PM, Armando M. wrote:
> 
> 
>  On 23 April 2015 at 09:58, Russell Bryant  >>
>  >> wrote:
> 
>    On 04/23/2015 12:14 PM, Armando M. wrote:
> >
> >
> > On 23 April 2015 at 07:32, Russell Bryant  >>  >>>
> > 
> >> >
> >   On 04/22/2015 10:33 PM, Armando M. wrote:
> >>
> >>   Would it make sense to capture these projects as simply
> >>   'affiliated', ie. with a loose relationship to Neutron,
> >   because
> >>   they use/integrate with Neutron in some form or
>    another (e.g.
> >>   having 3rd-party, extending-api,
>    integrating-via-plugin-model,
> >>   etc)? Then we could simply consider extending the
> >   projects.yaml
> >>   to capture this new concept (for Neutron or any
>    other project)
> >>   once we defined its ontology.
> >>
> >>   Thoughts?
> >>
> >>
> >>   That seems interesting, but given the communities stated
>    goals
> >>   around Big Tent, it seems to me like affiliation or not,
>    adding
> >>   these under the Neutron tent, inside the larger
>    OpenStack Bigger
> >>   Tent, would be a good thing.
> >>
> >>   Thanks,
> >>   Kyle
> >>
> >>
> >>
> >> Thanks for clearing some of the questions I raised. I should
> >   stress the
> >> fact that I welcome the idea of finding a more sensible home
>    for these
> >> projects in light of the big tent developments, but it seems
>    like
> >   we're
> >> still pouring down the foundations. I'd rather get us to a
>    point where
> >> the landscape is clear, and the dust settled. That would help us
> >   make a
> >> more informed decision compared to the one we can make right
>    now.
> >
> >   Can you be a bit more specific about what's not clear and
>    would help
> >   make you feel more informed?
> >
> >
> > I am not clear on how we make a decision, as to which project
>    belongs or
> > doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
> >>we end
> > up calling it :)
> 
>    OK, that's fine.  Figuring that out is the next step if folks
> >>agree with
>    Neutron as the home for networking-foo repos.  I'm happy to
> >>write up a
>    strawman proposal for inclusion criteria and a set of expectations
>    around responsibilities and communication.
> 
> 
>  What about the other Neutron related ones that didn't strictly follow
>  the networking- prefix in the name, would the naming convention
> >>be one
>  of the criteria? I look forward to your proposal.
> >>>
> >>> Good question.  I think consistency is good, especially when there are
> >>> so many of them.  It helps make it clear that they're all
> >>following some
> >>> sort of pattern.  Luckily we do have a way to get repos renamed if
> >>needed.
> >>
> >>There is one existing project, stackforge/octavia, which is quite
> >>active and has used its codename extensively. Suggested naming I’d
> >>be ok with, but enforced naming seems… confining.
> >
> > To be honest, I really don't care about the names.  All it takes is some
> > pretty easy docs to help people figure out what things are and where
> > they live.  Making it a recommendation is fine with me.
> >
> >>
> >> If we've reached the point where we're arguing about naming, dos this
> >> mean we've built consensus on the "yes, it makes sense for these to live
> >> under Neutron" argument?
> >
> > Ha.  I figured I'd give it at least another day before stirring up more
> > debate with a proposal around criteria / responsibilities / expectations.
>
> Quick, someone invoke Godwin’s law, and then let’s ship this thing.
>
> doug
>
>
> >
> > --
> > Russell Bryant
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> >

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Doug Wiegley]

> On Apr 23, 2015, at 1:42 PM, Russell Bryant  wrote:
> 
> On 04/23/2015 03:23 PM, Kyle Mestery wrote:
>> On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
>> mailto:doug...@parksidesoftware.com>> wrote:
>> 
>> 
>>> On Apr 23, 2015, at 11:57 AM, Russell Bryant >> wrote:
>>> 
>>> On 04/23/2015 01:19 PM, Armando M. wrote:
 
 
 On 23 April 2015 at 09:58, Russell Bryant >
 >> wrote:
 
   On 04/23/2015 12:14 PM, Armando M. wrote:
> 
> 
> On 23 April 2015 at 07:32, Russell Bryant > >>
> 
>> 
>   On 04/22/2015 10:33 PM, Armando M. wrote:
>> 
>>   Would it make sense to capture these projects as simply
>>   'affiliated', ie. with a loose relationship to Neutron,
>   because
>>   they use/integrate with Neutron in some form or
   another (e.g.
>>   having 3rd-party, extending-api,
   integrating-via-plugin-model,
>>   etc)? Then we could simply consider extending the
>   projects.yaml
>>   to capture this new concept (for Neutron or any
   other project)
>>   once we defined its ontology.
>> 
>>   Thoughts?
>> 
>> 
>>   That seems interesting, but given the communities stated
   goals
>>   around Big Tent, it seems to me like affiliation or not,
   adding
>>   these under the Neutron tent, inside the larger
   OpenStack Bigger
>>   Tent, would be a good thing.
>> 
>>   Thanks,
>>   Kyle
>> 
>> 
>> 
>> Thanks for clearing some of the questions I raised. I should
>   stress the
>> fact that I welcome the idea of finding a more sensible home
   for these
>> projects in light of the big tent developments, but it seems
   like
>   we're
>> still pouring down the foundations. I'd rather get us to a
   point where
>> the landscape is clear, and the dust settled. That would help us
>   make a
>> more informed decision compared to the one we can make right
   now.
> 
>   Can you be a bit more specific about what's not clear and
   would help
>   make you feel more informed?
> 
> 
> I am not clear on how we make a decision, as to which project
   belongs or
> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
>>we end
> up calling it :)
 
   OK, that's fine.  Figuring that out is the next step if folks
>>agree with
   Neutron as the home for networking-foo repos.  I'm happy to
>>write up a
   strawman proposal for inclusion criteria and a set of expectations
   around responsibilities and communication.
 
 
 What about the other Neutron related ones that didn't strictly follow
 the networking- prefix in the name, would the naming convention
>>be one
 of the criteria? I look forward to your proposal.
>>> 
>>> Good question.  I think consistency is good, especially when there are
>>> so many of them.  It helps make it clear that they're all
>>following some
>>> sort of pattern.  Luckily we do have a way to get repos renamed if
>>needed.
>> 
>>There is one existing project, stackforge/octavia, which is quite
>>active and has used its codename extensively. Suggested naming I’d
>>be ok with, but enforced naming seems… confining.
> 
> To be honest, I really don't care about the names.  All it takes is some
> pretty easy docs to help people figure out what things are and where
> they live.  Making it a recommendation is fine with me.
> 
>> 
>> If we've reached the point where we're arguing about naming, dos this
>> mean we've built consensus on the "yes, it makes sense for these to live
>> under Neutron" argument?
> 
> Ha.  I figured I'd give it at least another day before stirring up more
> debate with a proposal around criteria / responsibilities / expectations.

Quick, someone invoke Godwin’s law, and then let’s ship this thing.

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] [Neutron] A big tent home for Neutron backend code

[Joshua Harlow]

Russell Bryant wrote:

On 04/23/2015 03:23 PM, Kyle Mestery wrote:

On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
mailto:doug...@parksidesoftware.com>>  wrote:


 >  On Apr 23, 2015, at 11:57 AM, Russell Bryantmailto:rbry...@redhat.com>>  wrote:
 >
 >  On 04/23/2015 01:19 PM, Armando M. wrote:
 >>
 >>
 >>  On 23 April 2015 at 09:58, Russell Bryantmailto:rbry...@redhat.com>
 >>  >>  wrote:
 >>
 >> On 04/23/2015 12:14 PM, Armando M. wrote:
 >>>
 >>>
 >>>  On 23 April 2015 at 07:32, Russell Bryantmailto:rbry...@redhat.com>  >
 >>>  
 >>
 >>> On 04/22/2015 10:33 PM, Armando M. wrote:
 
  Would it make sense to capture these projects as simply
  'affiliated', ie. with a loose relationship to Neutron,
 >>> because
  they use/integrate with Neutron in some form or
 >> another (e.g.
  having 3rd-party, extending-api,
 >> integrating-via-plugin-model,
  etc)? Then we could simply consider extending the
 >>> projects.yaml
  to capture this new concept (for Neutron or any
 >> other project)
  once we defined its ontology.
 
  Thoughts?
 
 
  That seems interesting, but given the communities stated
 >> goals
  around Big Tent, it seems to me like affiliation or not,
 >> adding
  these under the Neutron tent, inside the larger
 >> OpenStack Bigger
  Tent, would be a good thing.
 
  Thanks,
  Kyle
 
 
 
   Thanks for clearing some of the questions I raised. I should
 >>> stress the
   fact that I welcome the idea of finding a more sensible home
 >> for these
   projects in light of the big tent developments, but it seems
 >> like
 >>> we're
   still pouring down the foundations. I'd rather get us to a
 >> point where
   the landscape is clear, and the dust settled. That would help us
 >>> make a
   more informed decision compared to the one we can make right
 >> now.
 >>>
 >>> Can you be a bit more specific about what's not clear and
 >> would help
 >>> make you feel more informed?
 >>>
 >>>
 >>>  I am not clear on how we make a decision, as to which project
 >> belongs or
 >>>  doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
 we end
 >>>  up calling it :)
 >>
 >> OK, that's fine.  Figuring that out is the next step if folks
 agree with
 >> Neutron as the home for networking-foo repos.  I'm happy to
 write up a
 >> strawman proposal for inclusion criteria and a set of expectations
 >> around responsibilities and communication.
 >>
 >>
 >>  What about the other Neutron related ones that didn't strictly follow
 >>  the networking- prefix in the name, would the naming convention
 be one
 >>  of the criteria? I look forward to your proposal.
 >
 >  Good question.  I think consistency is good, especially when there are
 >  so many of them.  It helps make it clear that they're all
 following some
 >  sort of pattern.  Luckily we do have a way to get repos renamed if
 needed.

 There is one existing project, stackforge/octavia, which is quite
 active and has used its codename extensively. Suggested naming I’d
 be ok with, but enforced naming seems… confining.


To be honest, I really don't care about the names.  All it takes is some
pretty easy docs to help people figure out what things are and where
they live.  Making it a recommendation is fine with me.


Maybe about time we make something like:

http://projects.apache.org/indexes/category.html

And link names to repos there...?




If we've reached the point where we're arguing about naming, dos this
mean we've built consensus on the "yes, it makes sense for these to live
under Neutron" argument?


Ha.  I figured I'd give it at least another day before stirring up more
debate with a proposal around criteria / responsibilities / expectations.



__
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] A big tent home for Neutron backend code

[Russell Bryant]

On 04/23/2015 03:23 PM, Kyle Mestery wrote:
> On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley
> mailto:doug...@parksidesoftware.com>> wrote:
> 
> 
> > On Apr 23, 2015, at 11:57 AM, Russell Bryant  > wrote:
> >
> > On 04/23/2015 01:19 PM, Armando M. wrote:
> >>
> >>
> >> On 23 April 2015 at 09:58, Russell Bryant  
> >> >> wrote:
> >>
> >>On 04/23/2015 12:14 PM, Armando M. wrote:
> >>>
> >>>
> >>> On 23 April 2015 at 07:32, Russell Bryant    >
> >>> 
>  >>>
> >>>On 04/22/2015 10:33 PM, Armando M. wrote:
> 
> Would it make sense to capture these projects as simply
> 'affiliated', ie. with a loose relationship to Neutron,
> >>>because
> they use/integrate with Neutron in some form or
> >>another (e.g.
> having 3rd-party, extending-api,
> >>integrating-via-plugin-model,
> etc)? Then we could simply consider extending the
> >>>projects.yaml
> to capture this new concept (for Neutron or any
> >>other project)
> once we defined its ontology.
> 
> Thoughts?
> 
> 
> That seems interesting, but given the communities stated
> >>goals
> around Big Tent, it seems to me like affiliation or not,
> >>adding
> these under the Neutron tent, inside the larger
> >>OpenStack Bigger
> Tent, would be a good thing.
> 
> Thanks,
> Kyle
> 
> 
> 
>  Thanks for clearing some of the questions I raised. I should
> >>>stress the
>  fact that I welcome the idea of finding a more sensible home
> >>for these
>  projects in light of the big tent developments, but it seems
> >>like
> >>>we're
>  still pouring down the foundations. I'd rather get us to a
> >>point where
>  the landscape is clear, and the dust settled. That would help us
> >>>make a
>  more informed decision compared to the one we can make right
> >>now.
> >>>
> >>>Can you be a bit more specific about what's not clear and
> >>would help
> >>>make you feel more informed?
> >>>
> >>>
> >>> I am not clear on how we make a decision, as to which project
> >>belongs or
> >>> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however
> we end
> >>> up calling it :)
> >>
> >>OK, that's fine.  Figuring that out is the next step if folks
> agree with
> >>Neutron as the home for networking-foo repos.  I'm happy to
> write up a
> >>strawman proposal for inclusion criteria and a set of expectations
> >>around responsibilities and communication.
> >>
> >>
> >> What about the other Neutron related ones that didn't strictly follow
> >> the networking- prefix in the name, would the naming convention
> be one
> >> of the criteria? I look forward to your proposal.
> >
> > Good question.  I think consistency is good, especially when there are
> > so many of them.  It helps make it clear that they're all
> following some
> > sort of pattern.  Luckily we do have a way to get repos renamed if
> needed.
> 
> There is one existing project, stackforge/octavia, which is quite
> active and has used its codename extensively. Suggested naming I’d
> be ok with, but enforced naming seems… confining.

To be honest, I really don't care about the names.  All it takes is some
pretty easy docs to help people figure out what things are and where
they live.  Making it a recommendation is fine with me.

> 
> If we've reached the point where we're arguing about naming, dos this
> mean we've built consensus on the "yes, it makes sense for these to live
> under Neutron" argument?

Ha.  I figured I'd give it at least another day before stirring up more
debate with a proposal around criteria / responsibilities / expectations.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley 
wrote:

>
> > On Apr 23, 2015, at 11:57 AM, Russell Bryant  wrote:
> >
> > On 04/23/2015 01:19 PM, Armando M. wrote:
> >>
> >>
> >> On 23 April 2015 at 09:58, Russell Bryant  >> > wrote:
> >>
> >>On 04/23/2015 12:14 PM, Armando M. wrote:
> >>>
> >>>
> >>> On 23 April 2015 at 07:32, Russell Bryant  rbry...@redhat.com>
> >>> >> wrote:
> >>>
> >>>On 04/22/2015 10:33 PM, Armando M. wrote:
> 
> Would it make sense to capture these projects as simply
> 'affiliated', ie. with a loose relationship to Neutron,
> >>>because
> they use/integrate with Neutron in some form or
> >>another (e.g.
> having 3rd-party, extending-api,
> >>integrating-via-plugin-model,
> etc)? Then we could simply consider extending the
> >>>projects.yaml
> to capture this new concept (for Neutron or any
> >>other project)
> once we defined its ontology.
> 
> Thoughts?
> 
> 
> That seems interesting, but given the communities stated
> >>goals
> around Big Tent, it seems to me like affiliation or not,
> >>adding
> these under the Neutron tent, inside the larger
> >>OpenStack Bigger
> Tent, would be a good thing.
> 
> Thanks,
> Kyle
> 
> 
> 
>  Thanks for clearing some of the questions I raised. I should
> >>>stress the
>  fact that I welcome the idea of finding a more sensible home
> >>for these
>  projects in light of the big tent developments, but it seems
> >>like
> >>>we're
>  still pouring down the foundations. I'd rather get us to a
> >>point where
>  the landscape is clear, and the dust settled. That would help us
> >>>make a
>  more informed decision compared to the one we can make right
> >>now.
> >>>
> >>>Can you be a bit more specific about what's not clear and
> >>would help
> >>>make you feel more informed?
> >>>
> >>>
> >>> I am not clear on how we make a decision, as to which project
> >>belongs or
> >>> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
> >>> up calling it :)
> >>
> >>OK, that's fine.  Figuring that out is the next step if folks agree
> with
> >>Neutron as the home for networking-foo repos.  I'm happy to write up
> a
> >>strawman proposal for inclusion criteria and a set of expectations
> >>around responsibilities and communication.
> >>
> >>
> >> What about the other Neutron related ones that didn't strictly follow
> >> the networking- prefix in the name, would the naming convention be one
> >> of the criteria? I look forward to your proposal.
> >
> > Good question.  I think consistency is good, especially when there are
> > so many of them.  It helps make it clear that they're all following some
> > sort of pattern.  Luckily we do have a way to get repos renamed if
> needed.
>
> There is one existing project, stackforge/octavia, which is quite active
> and has used its codename extensively. Suggested naming I’d be ok with, but
> enforced naming seems… confining.
>
> Thanks,
> doug
>
>
>
If we've reached the point where we're arguing about naming, dos this mean
we've built consensus on the "yes, it makes sense for these to live under
Neutron" argument?

Thanks,
Kyle


> >
> > --
> > 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
>
__
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] A big tent home for Neutron backend code

[Doug Wiegley]

> On Apr 23, 2015, at 11:57 AM, Russell Bryant  wrote:
> 
> On 04/23/2015 01:19 PM, Armando M. wrote:
>> 
>> 
>> On 23 April 2015 at 09:58, Russell Bryant > > wrote:
>> 
>>On 04/23/2015 12:14 PM, Armando M. wrote:
>>> 
>>> 
>>> On 23 April 2015 at 07:32, Russell Bryant >> 
>>> >> wrote:
>>> 
>>>On 04/22/2015 10:33 PM, Armando M. wrote:
 
Would it make sense to capture these projects as simply
'affiliated', ie. with a loose relationship to Neutron,
>>>because
they use/integrate with Neutron in some form or
>>another (e.g.
having 3rd-party, extending-api,
>>integrating-via-plugin-model,
etc)? Then we could simply consider extending the
>>>projects.yaml
to capture this new concept (for Neutron or any
>>other project)
once we defined its ontology.
 
Thoughts?
 
 
That seems interesting, but given the communities stated
>>goals
around Big Tent, it seems to me like affiliation or not,
>>adding
these under the Neutron tent, inside the larger
>>OpenStack Bigger
Tent, would be a good thing.
 
Thanks,
Kyle
 
 
 
 Thanks for clearing some of the questions I raised. I should
>>>stress the
 fact that I welcome the idea of finding a more sensible home
>>for these
 projects in light of the big tent developments, but it seems
>>like
>>>we're
 still pouring down the foundations. I'd rather get us to a
>>point where
 the landscape is clear, and the dust settled. That would help us
>>>make a
 more informed decision compared to the one we can make right
>>now.
>>> 
>>>Can you be a bit more specific about what's not clear and
>>would help
>>>make you feel more informed?
>>> 
>>> 
>>> I am not clear on how we make a decision, as to which project
>>belongs or
>>> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
>>> up calling it :)
>> 
>>OK, that's fine.  Figuring that out is the next step if folks agree with
>>Neutron as the home for networking-foo repos.  I'm happy to write up a
>>strawman proposal for inclusion criteria and a set of expectations
>>around responsibilities and communication.
>> 
>> 
>> What about the other Neutron related ones that didn't strictly follow
>> the networking- prefix in the name, would the naming convention be one
>> of the criteria? I look forward to your proposal.
> 
> Good question.  I think consistency is good, especially when there are
> so many of them.  It helps make it clear that they're all following some
> sort of pattern.  Luckily we do have a way to get repos renamed if needed.

There is one existing project, stackforge/octavia, which is quite active and 
has used its codename extensively. Suggested naming I’d be ok with, but 
enforced naming seems… confining.

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] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M  wrote:

>  Yeah. In the end, its what git repo the source for a given rpm you
> install comes from. Ops will not care that neutron-openvswitch-agent comes
> from repo foo.git instead of bar.git.
>
>

That's really the tl;dr of the proposed split.

Thanks,
Kyle


> Thanks,
> Kevin
>  --
> *From:* Armando M. [arma...@gmail.com]
> *Sent:* Thursday, April 23, 2015 9:10 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] A big tent home for Neutron
> backend code
>
>
>>>   I agree with henry here.
>>  Armando, If we use your analogy with nova that doesn't build and
>> deliver KVM, we can say that Neutron doesn't build or deliver OVS. It
>> builds a driver and an agent which manage OVS, just like nova which
>> provides a driver to manage libvirt/KVM.
>>  Moreover, external SDN controllers are much more complex than Neutron
>> with its reference drivers. I feel like forcing the cloud admin to deploy
>> and maintain an external SDN controller would be a terrible experience for
>> him if he just needs a simple way manage connectivity between VMs.
>> At the end of the day, it might be detrimental for the neutron project.
>>
>>
>
>  I don't think that anyone is saying that cloud admins are going to be
> forced to deploy and maintain an external SDN controller. There are plenty
> of deployment examples where people are just happy with network
> virtualization the way Neutron has been providing for years and we should
> not regress on that. To me it's mostly a matter of responsibilities of who
> develops what, and what that what is :)
>
>  The consumption model is totally a different matter.
>
>
> __
> 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] A big tent home for Neutron backend code

[Fox, Kevin M]

Yeah. In the end, its what git repo the source for a given rpm you install 
comes from. Ops will not care that neutron-openvswitch-agent comes from repo 
foo.git instead of bar.git.

Thanks,
Kevin

From: Armando M. [arma...@gmail.com]
Sent: Thursday, April 23, 2015 9:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code


I agree with henry here.
Armando, If we use your analogy with nova that doesn't build and deliver KVM, 
we can say that Neutron doesn't build or deliver OVS. It builds a driver and an 
agent which manage OVS, just like nova which provides a driver to manage 
libvirt/KVM.
Moreover, external SDN controllers are much more complex than Neutron with its 
reference drivers. I feel like forcing the cloud admin to deploy and maintain 
an external SDN controller would be a terrible experience for him if he just 
needs a simple way manage connectivity between VMs.
At the end of the day, it might be detrimental for the neutron project.


I don't think that anyone is saying that cloud admins are going to be forced to 
deploy and maintain an external SDN controller. There are plenty of deployment 
examples where people are just happy with network virtualization the way 
Neutron has been providing for years and we should not regress on that. To me 
it's mostly a matter of responsibilities of who develops what, and what that 
what is :)

The consumption model is totally a different matter.

__
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] A big tent home for Neutron backend code

[Russell Bryant]

On 04/23/2015 01:19 PM, Armando M. wrote:
> 
> 
> On 23 April 2015 at 09:58, Russell Bryant  > wrote:
> 
> On 04/23/2015 12:14 PM, Armando M. wrote:
> >
> >
> > On 23 April 2015 at 07:32, Russell Bryant  
> > >> wrote:
> >
> > On 04/22/2015 10:33 PM, Armando M. wrote:
> > >
> > > Would it make sense to capture these projects as simply
> > > 'affiliated', ie. with a loose relationship to Neutron,
> > because
> > > they use/integrate with Neutron in some form or
> another (e.g.
> > > having 3rd-party, extending-api,
> integrating-via-plugin-model,
> > > etc)? Then we could simply consider extending the
> > projects.yaml
> > > to capture this new concept (for Neutron or any
> other project)
> > > once we defined its ontology.
> > >
> > > Thoughts?
> > >
> > >
> > > That seems interesting, but given the communities stated
> goals
> > > around Big Tent, it seems to me like affiliation or not,
> adding
> > > these under the Neutron tent, inside the larger
> OpenStack Bigger
> > > Tent, would be a good thing.
> > >
> > > Thanks,
> > > Kyle
> > >
> > >
> > >
> > > Thanks for clearing some of the questions I raised. I should
> > stress the
> > > fact that I welcome the idea of finding a more sensible home
> for these
> > > projects in light of the big tent developments, but it seems
> like
> > we're
> > > still pouring down the foundations. I'd rather get us to a
> point where
> > > the landscape is clear, and the dust settled. That would help us
> > make a
> > > more informed decision compared to the one we can make right
> now.
> >
> > Can you be a bit more specific about what's not clear and
> would help
> > make you feel more informed?
> >
> >
> > I am not clear on how we make a decision, as to which project
> belongs or
> > doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
> > up calling it :)
> 
> OK, that's fine.  Figuring that out is the next step if folks agree with
> Neutron as the home for networking-foo repos.  I'm happy to write up a
> strawman proposal for inclusion criteria and a set of expectations
> around responsibilities and communication.
> 
> 
> What about the other Neutron related ones that didn't strictly follow
> the networking- prefix in the name, would the naming convention be one
> of the criteria? I look forward to your proposal.

Good question.  I think consistency is good, especially when there are
so many of them.  It helps make it clear that they're all following some
sort of pattern.  Luckily we do have a way to get repos renamed if needed.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

On 23 April 2015 at 09:58, Russell Bryant  wrote:

> On 04/23/2015 12:14 PM, Armando M. wrote:
> >
> >
> > On 23 April 2015 at 07:32, Russell Bryant  > > wrote:
> >
> > On 04/22/2015 10:33 PM, Armando M. wrote:
> > >
> > > Would it make sense to capture these projects as simply
> > > 'affiliated', ie. with a loose relationship to Neutron,
> > because
> > > they use/integrate with Neutron in some form or another
> (e.g.
> > > having 3rd-party, extending-api,
> integrating-via-plugin-model,
> > > etc)? Then we could simply consider extending the
> > projects.yaml
> > > to capture this new concept (for Neutron or any other
> project)
> > > once we defined its ontology.
> > >
> > > Thoughts?
> > >
> > >
> > > That seems interesting, but given the communities stated goals
> > > around Big Tent, it seems to me like affiliation or not, adding
> > > these under the Neutron tent, inside the larger OpenStack
> Bigger
> > > Tent, would be a good thing.
> > >
> > > Thanks,
> > > Kyle
> > >
> > >
> > >
> > > Thanks for clearing some of the questions I raised. I should
> > stress the
> > > fact that I welcome the idea of finding a more sensible home for
> these
> > > projects in light of the big tent developments, but it seems like
> > we're
> > > still pouring down the foundations. I'd rather get us to a point
> where
> > > the landscape is clear, and the dust settled. That would help us
> > make a
> > > more informed decision compared to the one we can make right now.
> >
> > Can you be a bit more specific about what's not clear and would help
> > make you feel more informed?
> >
> >
> > I am not clear on how we make a decision, as to which project belongs or
> > doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
> > up calling it :)
>
> OK, that's fine.  Figuring that out is the next step if folks agree with
> Neutron as the home for networking-foo repos.  I'm happy to write up a
> strawman proposal for inclusion criteria and a set of expectations
> around responsibilities and communication.
>
>
What about the other Neutron related ones that didn't strictly follow the
networking- prefix in the name, would the naming convention be one of the
criteria? I look forward to your proposal.

Thanks,
Armando


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/23/2015 12:14 PM, Armando M. wrote:
> 
> 
> On 23 April 2015 at 07:32, Russell Bryant  > wrote:
> 
> On 04/22/2015 10:33 PM, Armando M. wrote:
> >
> > Would it make sense to capture these projects as simply
> > 'affiliated', ie. with a loose relationship to Neutron,
> because
> > they use/integrate with Neutron in some form or another (e.g.
> > having 3rd-party, extending-api, integrating-via-plugin-model,
> > etc)? Then we could simply consider extending the
> projects.yaml
> > to capture this new concept (for Neutron or any other project)
> > once we defined its ontology.
> >
> > Thoughts?
> >
> >
> > That seems interesting, but given the communities stated goals
> > around Big Tent, it seems to me like affiliation or not, adding
> > these under the Neutron tent, inside the larger OpenStack Bigger
> > Tent, would be a good thing.
> >
> > Thanks,
> > Kyle
> >
> >
> >
> > Thanks for clearing some of the questions I raised. I should
> stress the
> > fact that I welcome the idea of finding a more sensible home for these
> > projects in light of the big tent developments, but it seems like
> we're
> > still pouring down the foundations. I'd rather get us to a point where
> > the landscape is clear, and the dust settled. That would help us
> make a
> > more informed decision compared to the one we can make right now.
> 
> Can you be a bit more specific about what's not clear and would help
> make you feel more informed?
> 
> 
> I am not clear on how we make a decision, as to which project belongs or
> doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end
> up calling it :)

OK, that's fine.  Figuring that out is the next step if folks agree with
Neutron as the home for networking-foo repos.  I'm happy to write up a
strawman proposal for inclusion criteria and a set of expectations
around responsibilities and communication.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Fox, Kevin M]

+1

From: Armando M. [arma...@gmail.com]
Sent: Wednesday, April 22, 2015 7:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code


Could you please also pay some attention on Cons of this ultimate
splitting Kyle? I'm afraid it would hurt the user experiences.

On the position of Dev, A naked Neutron without "official" built-in
reference implementation probably has a more clear architecture. On
the other side, users would be forced to make choice between a long
list of backend implementations, which is very difficult for
non-professionals.

In most of the time, users need a off-the-shelf solution without
paying much extra integration effort, and they have less interest to
study which SDN controller is powerful and is better than others. Can
we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
volume driver [See Deployment Profiles section in 1a] ? Shall we
really decide to make Neutron the only Openstack project which has not
any in tree official implementation?

I think the analogy here is between the agent reference implementation vs KVM 
or Ceph, rather than the plumbing that taps into the underlying technology. 
Nova doesn't build/package KVM as Cinder doesn't build/package Ceph. Neutron 
could rely on other open source solutions (ODL, OpenContrail, OVN, etc), and 
still be similar to the other projects.

I think there's still room for clarifying what the split needs to be, but I 
have always seen Neutron as the exception rather than norm, where, for historic 
reasons, we had to build everything from the ground up for lack of viable open 
source solutions at the time the project was conceived.


[1a] 
http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

Here is my personal suggestion: decomposition decision needs some
trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
with OVS&LB, based on the survey result of 1a above]. While we are
progressing radically with architecture re-factoring, smooth
experience and easy to adoption should also be cared.

>
> One thing which is worth bringing up in this context is the potential
> overlap between this implementations. I think having them all under the
> Neutron project would allow me as PTL and the rest of the team work to
> combine things when it makes sense.
>
> Kyle
>
> [1] http://www.faqs.org/rfcs/rfc1149.html
>
>>
>> b) Let each interested group define a new project team for their backend
>> code.
>>
> To be honest, I don't this is a scalable option. I'm involved with 2 of
> these networking-foo projects, and there is not enough participation so far
> to warrant an entirely new project, PTL and infra around it. This is just my
> opinion, but it's an opinion I've taken after having contributed to
> networking-odl and networking-ovn for the past 5 months.
>
>>
>> So, as an example, the group of people working on Neutron integration
>> with OpenDaylight could propose a new project team that would be a
>> projects.yaml entry that looks something like:
>>
>> Neutron-OpenDaylight:
>>   ptl: Some Person (ircnick)
>>   service: OpenDaylight Networking
>>   mission: >
>> To implement Neutron support for the OpenDaylight project.
>>   url: ...
>>   projects:
>> - repo: openstack/networking-odl
>>
>> Pros:
>>  + There's no additional load on the Neutron project team and PTL.
>>
>> Cons:
>>  - Having all of these efforts organized under a single project team and
>> PTL might be better for ensuring some level of collaboration and
>> consistency.
>>
>> c) A single new project team could be created that is led by a single
>> person to coordinate the sub-teams working on each repo.  In this
>> scenario, I could see the overall collaboration being around ensuring
>> consistent approaches to development process, testing, documentation,
>> and releases.
>>
>> That would be something like this (note that the project list would be
>> limited to those who actually want to be included in the official
>> project team and meet some set of inclusion criteria).
>>
>> Neutron-Backends:
>>   ptl: Some Person (ircnick)
>>   service: Networking Backends
>>   mission: >
>> To implement Neutron backend support for various networking
>> technologies.
>>   url: ...
>>   projects:
>> - openstack/networking-arista
>> - openstack/networking-bagpipe-l2
>> - openstack/networking-bgpvpn
>> - openstack/networking-bigswitch
>> - openstack/networking-brocade
>&

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

On 23 April 2015 at 07:32, Russell Bryant  wrote:

> On 04/22/2015 10:33 PM, Armando M. wrote:
> >
> > Would it make sense to capture these projects as simply
> > 'affiliated', ie. with a loose relationship to Neutron, because
> > they use/integrate with Neutron in some form or another (e.g.
> > having 3rd-party, extending-api, integrating-via-plugin-model,
> > etc)? Then we could simply consider extending the projects.yaml
> > to capture this new concept (for Neutron or any other project)
> > once we defined its ontology.
> >
> > Thoughts?
> >
> >
> > That seems interesting, but given the communities stated goals
> > around Big Tent, it seems to me like affiliation or not, adding
> > these under the Neutron tent, inside the larger OpenStack Bigger
> > Tent, would be a good thing.
> >
> > Thanks,
> > Kyle
> >
> >
> >
> > Thanks for clearing some of the questions I raised. I should stress the
> > fact that I welcome the idea of finding a more sensible home for these
> > projects in light of the big tent developments, but it seems like we're
> > still pouring down the foundations. I'd rather get us to a point where
> > the landscape is clear, and the dust settled. That would help us make a
> > more informed decision compared to the one we can make right now.
>
> Can you be a bit more specific about what's not clear and would help
> make you feel more informed?
>
>
I am not clear on how we make a decision, as to which project belongs or
doesn't to the Neutron 'umbrella', 'tent', 'stadium' or however we end up
calling it :)


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
>
>> I agree with henry here.
> Armando, If we use your analogy with nova that doesn't build and deliver
> KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
> driver and an agent which manage OVS, just like nova which provides a
> driver to manage libvirt/KVM.
> Moreover, external SDN controllers are much more complex than Neutron with
> its reference drivers. I feel like forcing the cloud admin to deploy and
> maintain an external SDN controller would be a terrible experience for him
> if he just needs a simple way manage connectivity between VMs.
> At the end of the day, it might be detrimental for the neutron project.
>
>

I don't think that anyone is saying that cloud admins are going to be
forced to deploy and maintain an external SDN controller. There are plenty
of deployment examples where people are just happy with network
virtualization the way Neutron has been providing for years and we should
not regress on that. To me it's mostly a matter of responsibilities of who
develops what, and what that what is :)

The consumption model is totally a different matter.
__
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] A big tent home for Neutron backend code

[Armando M.]

On 23 April 2015 at 01:49, Thierry Carrez  wrote:

> Armando M. wrote:
> > Is it sensible to assume that Stackforge is going away entirely at some
> > point in the future, and we'll have a single namespace - OpenStack?
>
> The key difference between Stackforge and OpenStack is governance. Any
> project can be in Stackforge. Projects that are considered "OpenStack"
> projects are special in two ways:
>
> 1- They need to fit the "OpenStack" requirements as defined by the TC
> 2- They need to place themselves under the oversight of the TC
>
> In return, they get voting rights to elect the TC itself.
>
> While most projects in Stackforge actually fit (1) and accept (2), not
> all of them do. It's also not a decision that can be made for them (due
> to (2)), so we can't just migrate them.
>
> > It's my understanding that StackForge projects are bound to the same
> > governance model, or am I mistaken?
>
> Of course they aren't. They don't sign up for anything, and our
> governance model has no sort of control over them.
>

I have always considered StackForge projects (the vast majority anyway)
projects that have the ultimate desire to be an integral part of the
OpenStack ecosystem, and as such would need to follow the same model of the
other openstack projects (at least before the latest governance changes).
This is what I meant 'by bound to the same governance model', ie. besides
the legalities, following the same rules as any other OpenStack project,
but I can see I may have generated confusion with my point.

Thierry, thanks for the clarification.


> --
> 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] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/22/2015 10:33 PM, Armando M. wrote:
> 
> Would it make sense to capture these projects as simply
> 'affiliated', ie. with a loose relationship to Neutron, because
> they use/integrate with Neutron in some form or another (e.g.
> having 3rd-party, extending-api, integrating-via-plugin-model,
> etc)? Then we could simply consider extending the projects.yaml
> to capture this new concept (for Neutron or any other project)
> once we defined its ontology.
> 
> Thoughts?
> 
> 
> That seems interesting, but given the communities stated goals
> around Big Tent, it seems to me like affiliation or not, adding
> these under the Neutron tent, inside the larger OpenStack Bigger
> Tent, would be a good thing.
> 
> Thanks,
> Kyle
>  
> 
> 
> Thanks for clearing some of the questions I raised. I should stress the
> fact that I welcome the idea of finding a more sensible home for these
> projects in light of the big tent developments, but it seems like we're
> still pouring down the foundations. I'd rather get us to a point where
> the landscape is clear, and the dust settled. That would help us make a
> more informed decision compared to the one we can make right now.

Can you be a bit more specific about what's not clear and would help
make you feel more informed?

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

On 04/22/2015 09:55 PM, Anita Kuno wrote:
> On 04/22/2015 09:46 PM, Kyle Mestery wrote:
>> On Wed, Apr 22, 2015 at 7:44 PM, Armando M.  wrote:
>>
>>>
>>>
>>> On 22 April 2015 at 11:19, Russell Bryant  wrote:
>>>
 Hello!

 A couple of things I've been working on lately are project governance
 issues as a TC member and also implementation of a new virtual
 networking alternative with a Neutron driver.  So, naturally I started
 thinking about how the Neutron driver code fits in to OpenStack
 governance.

 There are basically two areas with a lot of movement related to this
 issue.

 1) Project governance has moved to a "big tent" model [1].  The vast
 majority of projects that used to be in Stackforge are being folded in
 to a larger definition of the OpenStack project.  Projects making this
 move meet the following criteria as being "one of us":
>>>
>>>
>>> Is it sensible to assume that Stackforge is going away entirely at some
>>> point in the future, and we'll have a single namespace - OpenStack?
>>>
>>>
>>
>> IMHO, I'm not sure what the StackForge designation means anymore now that
>> we have the Big Tent. I obviously also don't have the authority to make the
>> call on when it goes away however.
> Moving everything from Stackforge into the OpenStack namespace is
> something that Jim Blair has said he would like to see happen. There has
> been no resolution or focused discussion on this exact point that has
> been put before the TC that I have seen.

I think things are moving fast enough.  We need to make sure all of the
repos are properly captured under a team, but it seems momentum is
picking up.  This thread is part of that.

-- 
Russell Bryant

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Mathieu Rohon]

On Thu, Apr 23, 2015 at 10:28 AM, henry hly  wrote:

> On Thu, Apr 23, 2015 at 10:44 AM, Armando M.  wrote:
> >>
> >> Could you please also pay some attention on Cons of this ultimate
> >> splitting Kyle? I'm afraid it would hurt the user experiences.
> >>
> >> On the position of Dev, A naked Neutron without "official" built-in
> >> reference implementation probably has a more clear architecture. On
> >> the other side, users would be forced to make choice between a long
> >> list of backend implementations, which is very difficult for
> >> non-professionals.
> >>
> >> In most of the time, users need a off-the-shelf solution without
> >> paying much extra integration effort, and they have less interest to
> >> study which SDN controller is powerful and is better than others. Can
> >> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
> >> volume driver [See Deployment Profiles section in 1a] ? Shall we
> >> really decide to make Neutron the only Openstack project which has not
> >> any in tree official implementation?
> >
> >
> > I think the analogy here is between the agent reference implementation vs
> > KVM or Ceph, rather than the plumbing that taps into the underlying
> > technology. Nova doesn't build/package KVM as Cinder doesn't
> build/package
> > Ceph. Neutron could rely on other open source solutions (ODL,
> OpenContrail,
> > OVN, etc), and still be similar to the other projects.
> >
> > I think there's still room for clarifying what the split needs to be,
> but I
> > have always seen Neutron as the exception rather than norm, where, for
> > historic reasons, we had to build everything from the ground up for lack
> of
> > viable open source solutions at the time the project was conceived.
> >
>
> Thanks for bring in this interesting topic, maybe it should not be
> scoped only inside Neutron, also I found a similar discuss from John
> griffith on Cinder vs SDS controller :-)
>
>
> https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/
>
> It's clear that an typical Cloud deployment is composed of two
> distinct part: workload engine vs. supervisor. The engine part
> obviously do not belong to Openstack project, which include open
> sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
> like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
> hardware gears or virtualized service VMs.
>
> However for the supervisor part, there is some blurring for debates:
> Should Openstack provide complete in-house implementation of
> controlling functions which could directly drive backend workload
> engine (via backend driver), or just thin API/DB layer which need to
> integrate some 3rd external controller projects to finish those works:
> scheduling, pooling and service logic abstraction? For networking, how
> should we regard the functions of plugin/agent and SDN controller, are
> they classified in the same layer of "real" backends working engine
> like Switchs/Routers/Firewalls?
>
> For Nova & Cinder, it seems former is adopted: a single unified
> central framework including API, scheduling, abstraction service
> logic, rpc & message queue, and a common agent side framework of
> compute/volume manager, then with a bunch of virt/volume drivers
> plugged to abstract the all kinds of backends. There are standalone
> backends like KVM and LVM, and aggregated clustering backends like
> vcenter and ceph.
>
> The Neutron was just like a developing game of continuously
> re-factoring: plugin, meta plugin, ML2, and now the "platform". Next
> ML2 plugin suddenly became just a "reference" for concept proving, and
> no plugin/agent would be maintained in-tree officially anymore, while
> the reason is confusingly "not to compete with other 3rd SDN
> controllers" :-P
>

I agree with henry here.
Armando, If we use your analogy with nova that doesn't build and deliver
KVM, we can say that Neutron doesn't build or deliver OVS. It builds a
driver and an agent which manage OVS, just like nova which provides a
driver to manage libvirt/KVM.
Moreover, external SDN controllers are much more complex than Neutron with
its reference drivers. I feel like forcing the cloud admin to deploy and
maintain an external SDN controller would be a terrible experience for him
if he just needs a simple way manage connectivity between VMs.
At the end of the day, it might be detrimental for the neutron project.


> >
> >>
> >>
> >> [1a]
> >>
> http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014
> >>
> >> Here is my personal suggestion: decomposition decision needs some
> >> trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
> >> with OVS&LB, based on the survey result of 1a above]. While we are
> >> progressing radically with architecture re-factoring, smooth
> >> experience and easy to adoption should also be cared.
> >>
> >> >
> >> > One thing which is worth bringing up in this context is the potential
> >> > overlap be

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Thierry Carrez]

Armando M. wrote:
> Is it sensible to assume that Stackforge is going away entirely at some
> point in the future, and we'll have a single namespace - OpenStack?

The key difference between Stackforge and OpenStack is governance. Any
project can be in Stackforge. Projects that are considered "OpenStack"
projects are special in two ways:

1- They need to fit the "OpenStack" requirements as defined by the TC
2- They need to place themselves under the oversight of the TC

In return, they get voting rights to elect the TC itself.

While most projects in Stackforge actually fit (1) and accept (2), not
all of them do. It's also not a decision that can be made for them (due
to (2)), so we can't just migrate them.

> It's my understanding that StackForge projects are bound to the same
> governance model, or am I mistaken? 

Of course they aren't. They don't sign up for anything, and our
governance model has no sort of control over them.

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

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[henry hly]

On Thu, Apr 23, 2015 at 10:44 AM, Armando M.  wrote:
>>
>> Could you please also pay some attention on Cons of this ultimate
>> splitting Kyle? I'm afraid it would hurt the user experiences.
>>
>> On the position of Dev, A naked Neutron without "official" built-in
>> reference implementation probably has a more clear architecture. On
>> the other side, users would be forced to make choice between a long
>> list of backend implementations, which is very difficult for
>> non-professionals.
>>
>> In most of the time, users need a off-the-shelf solution without
>> paying much extra integration effort, and they have less interest to
>> study which SDN controller is powerful and is better than others. Can
>> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
>> volume driver [See Deployment Profiles section in 1a] ? Shall we
>> really decide to make Neutron the only Openstack project which has not
>> any in tree official implementation?
>
>
> I think the analogy here is between the agent reference implementation vs
> KVM or Ceph, rather than the plumbing that taps into the underlying
> technology. Nova doesn't build/package KVM as Cinder doesn't build/package
> Ceph. Neutron could rely on other open source solutions (ODL, OpenContrail,
> OVN, etc), and still be similar to the other projects.
>
> I think there's still room for clarifying what the split needs to be, but I
> have always seen Neutron as the exception rather than norm, where, for
> historic reasons, we had to build everything from the ground up for lack of
> viable open source solutions at the time the project was conceived.
>

Thanks for bring in this interesting topic, maybe it should not be
scoped only inside Neutron, also I found a similar discuss from John
griffith on Cinder vs SDS controller :-)

https://griffithscorner.wordpress.com/2014/05/16/the-problem-with-sds-under-cinder/

It's clear that an typical Cloud deployment is composed of two
distinct part: workload engine vs. supervisor. The engine part
obviously do not belong to Openstack project, which include open
sourced like KVM, Ceph, OVS/Linuxstack/haproxy/openswan, and vendor's
like Vcenter/ESXi, SAN disk arrays, and all kinds of networking
hardware gears or virtualized service VMs.

However for the supervisor part, there is some blurring for debates:
Should Openstack provide complete in-house implementation of
controlling functions which could directly drive backend workload
engine (via backend driver), or just thin API/DB layer which need to
integrate some 3rd external controller projects to finish those works:
scheduling, pooling and service logic abstraction? For networking, how
should we regard the functions of plugin/agent and SDN controller, are
they classified in the same layer of "real" backends working engine
like Switchs/Routers/Firewalls?

For Nova & Cinder, it seems former is adopted: a single unified
central framework including API, scheduling, abstraction service
logic, rpc & message queue, and a common agent side framework of
compute/volume manager, then with a bunch of virt/volume drivers
plugged to abstract the all kinds of backends. There are standalone
backends like KVM and LVM, and aggregated clustering backends like
vcenter and ceph.

The Neutron was just like a developing game of continuously
re-factoring: plugin, meta plugin, ML2, and now the "platform". Next
ML2 plugin suddenly became just a "reference" for concept proving, and
no plugin/agent would be maintained in-tree officially anymore, while
the reason is confusingly "not to compete with other 3rd SDN
controllers" :-P

>
>>
>>
>> [1a]
>> http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014
>>
>> Here is my personal suggestion: decomposition decision needs some
>> trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
>> with OVS&LB, based on the survey result of 1a above]. While we are
>> progressing radically with architecture re-factoring, smooth
>> experience and easy to adoption should also be cared.
>>
>> >
>> > One thing which is worth bringing up in this context is the potential
>> > overlap between this implementations. I think having them all under the
>> > Neutron project would allow me as PTL and the rest of the team work to
>> > combine things when it makes sense.
>> >
>> > Kyle
>> >
>> > [1] http://www.faqs.org/rfcs/rfc1149.html
>> >
>> >>
>> >> b) Let each interested group define a new project team for their
>> >> backend
>> >> code.
>> >>
>> > To be honest, I don't this is a scalable option. I'm involved with 2 of
>> > these networking-foo projects, and there is not enough participation so
>> > far
>> > to warrant an entirely new project, PTL and infra around it. This is
>> > just my
>> > opinion, but it's an opinion I've taken after having contributed to
>> > networking-odl and networking-ovn for the past 5 months.
>> >
>> >>
>> >> So, as an example, the group of people working on Neutron integration
>> >> with OpenDaylight co

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
>
> Could you please also pay some attention on Cons of this ultimate
> splitting Kyle? I'm afraid it would hurt the user experiences.
>
> On the position of Dev, A naked Neutron without "official" built-in
> reference implementation probably has a more clear architecture. On
> the other side, users would be forced to make choice between a long
> list of backend implementations, which is very difficult for
> non-professionals.
>
> In most of the time, users need a off-the-shelf solution without
> paying much extra integration effort, and they have less interest to
> study which SDN controller is powerful and is better than others. Can
> we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
> volume driver [See Deployment Profiles section in 1a] ? Shall we
> really decide to make Neutron the only Openstack project which has not
> any in tree official implementation?
>

I think the analogy here is between the agent reference implementation vs
KVM or Ceph, rather than the plumbing that taps into the underlying
technology. Nova doesn't build/package KVM as Cinder doesn't build/package
Ceph. Neutron could rely on other open source solutions (ODL, OpenContrail,
OVN, etc), and still be similar to the other projects.

I think there's still room for clarifying what the split needs to be, but I
have always seen Neutron as the exception rather than norm, where, for
historic reasons, we had to build everything from the ground up for lack of
viable open source solutions at the time the project was conceived.


>
> [1a]
> http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014
>
> Here is my personal suggestion: decomposition decision needs some
> trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
> with OVS&LB, based on the survey result of 1a above]. While we are
> progressing radically with architecture re-factoring, smooth
> experience and easy to adoption should also be cared.
>
> >
> > One thing which is worth bringing up in this context is the potential
> > overlap between this implementations. I think having them all under the
> > Neutron project would allow me as PTL and the rest of the team work to
> > combine things when it makes sense.
> >
> > Kyle
> >
> > [1] http://www.faqs.org/rfcs/rfc1149.html
> >
> >>
> >> b) Let each interested group define a new project team for their backend
> >> code.
> >>
> > To be honest, I don't this is a scalable option. I'm involved with 2 of
> > these networking-foo projects, and there is not enough participation so
> far
> > to warrant an entirely new project, PTL and infra around it. This is
> just my
> > opinion, but it's an opinion I've taken after having contributed to
> > networking-odl and networking-ovn for the past 5 months.
> >
> >>
> >> So, as an example, the group of people working on Neutron integration
> >> with OpenDaylight could propose a new project team that would be a
> >> projects.yaml entry that looks something like:
> >>
> >> Neutron-OpenDaylight:
> >>   ptl: Some Person (ircnick)
> >>   service: OpenDaylight Networking
> >>   mission: >
> >> To implement Neutron support for the OpenDaylight project.
> >>   url: ...
> >>   projects:
> >> - repo: openstack/networking-odl
> >>
> >> Pros:
> >>  + There's no additional load on the Neutron project team and PTL.
> >>
> >> Cons:
> >>  - Having all of these efforts organized under a single project team and
> >> PTL might be better for ensuring some level of collaboration and
> >> consistency.
> >>
> >> c) A single new project team could be created that is led by a single
> >> person to coordinate the sub-teams working on each repo.  In this
> >> scenario, I could see the overall collaboration being around ensuring
> >> consistent approaches to development process, testing, documentation,
> >> and releases.
> >>
> >> That would be something like this (note that the project list would be
> >> limited to those who actually want to be included in the official
> >> project team and meet some set of inclusion criteria).
> >>
> >> Neutron-Backends:
> >>   ptl: Some Person (ircnick)
> >>   service: Networking Backends
> >>   mission: >
> >> To implement Neutron backend support for various networking
> >> technologies.
> >>   url: ...
> >>   projects:
> >> - openstack/networking-arista
> >> - openstack/networking-bagpipe-l2
> >> - openstack/networking-bgpvpn
> >> - openstack/networking-bigswitch
> >> - openstack/networking-brocade
> >> - openstack/networking-cisco
> >> - openstack/networking-edge-vpn
> >> - openstack/networking-hyperv
> >> - openstack/networking-ibm
> >> - openstack/networking-l2gw
> >> - openstack/networking-midonet
> >> - openstack/networking-mlnx
> >> - openstack/networking-nec
> >> - openstack/networking-odl
> >> - openstack/networking-ofagent
> >> - openstack/networking-ovn
> >> - openstack/networking-ovs-dpdk
> >> - openstack/networking-plumgrid
> 

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

>
>
>> Would it make sense to capture these projects as simply 'affiliated', ie.
>> with a loose relationship to Neutron, because they use/integrate with
>> Neutron in some form or another (e.g. having 3rd-party, extending-api,
>> integrating-via-plugin-model, etc)? Then we could simply consider extending
>> the projects.yaml to capture this new concept (for Neutron or any other
>> project) once we defined its ontology.
>>
>> Thoughts?
>>
>>
> That seems interesting, but given the communities stated goals around Big
> Tent, it seems to me like affiliation or not, adding these under the
> Neutron tent, inside the larger OpenStack Bigger Tent, would be a good
> thing.
>
> Thanks,
> Kyle
>
>

Thanks for clearing some of the questions I raised. I should stress the
fact that I welcome the idea of finding a more sensible home for these
projects in light of the big tent developments, but it seems like we're
still pouring down the foundations. I'd rather get us to a point where the
landscape is clear, and the dust settled. That would help us make a more
informed decision compared to the one we can make right now.

Cheers,
Armando
__
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] A big tent home for Neutron backend code

[loy wolfe]

On Thu, Apr 23, 2015 at 3:30 AM, Kyle Mestery  wrote:
> On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant  wrote:
>>
>> Hello!
>>
>> A couple of things I've been working on lately are project governance
>> issues as a TC member and also implementation of a new virtual
>> networking alternative with a Neutron driver.  So, naturally I started
>> thinking about how the Neutron driver code fits in to OpenStack
>> governance.
>>
> Thanks for starting this conversation Russell.
>
>>
>> There are basically two areas with a lot of movement related to this
>> issue.
>>
>> 1) Project governance has moved to a "big tent" model [1].  The vast
>> majority of projects that used to be in Stackforge are being folded in
>> to a larger definition of the OpenStack project.  Projects making this
>> move meet the following criteria as being "one of us":
>>
>> http://governance.openstack.org/reference/new-projects-requirements.html
>>
>> Official project teams are tracked in this file along with the git repos
>> they are responsible for:
>>
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>
>> which is also reflected here:
>>
>> http://governance.openstack.org/reference/projects/
>>
>> The TC has also been working through defining a system to help
>> differentiate efforts by using a set of "tags" [4].  So far, we have
>> tags describing the release handling for a repository, as well as a tag
>> for team diversity.  We've also had a lot of discussion about tags to
>> help describe maturity, but that is still a work in progress.
>>
>>
>> 2) In Neutron, some fairly significant good changes are being made to
>> help scale the development process.  Advanced services were split out
>> into their own repos [2].  Most of the plugin and driver code has also
>> been split out into repos [3].
>>
>> In terms of project teams, the Neutron team is defined as owning the
>> following repos:
>>
>>   http://governance.openstack.org/reference/projects/neutron.html
>>
>>  - openstack/neutron
>>  - openstack/neutron-fwaas
>>  - openstack/neutron-lbaas
>>  - openstack/neutron-vpnaas
>>  - openstack/neutron-specs
>>  - openstack/python-neutronclient
>>
>> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
>> repos.
>>
>> We also have a large set of repositories related to Neutron backend code:
>>
>>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>>
>>  - stackforge/networking-arista
>>  - stackforge/networking-bagpipe-l2
>>  - stackforge/networking-bgpvpn
>>  - stackforge/networking-bigswitch
>>  - stackforge/networking-brocade
>>  - stackforge/networking-cisco
>>  - stackforge/networking-edge-vpn
>>  - stackforge/networking-hyperv
>>  - stackforge/networking-ibm
>>  - stackforge/networking-l2gw
>>  - stackforge/networking-midonet
>>  - stackforge/networking-mlnx
>>  - stackforge/networking-nec
>>  - stackforge/networking-odl
>>  - stackforge/networking-ofagent
>>  - stackforge/networking-ovn
>>  - stackforge/networking-ovs-dpdk
>>  - stackforge/networking-plumgrid
>>  - stackforge/networking-portforwarding
>>  - stackforge/networking-vsphere
>>
>> Note that not all of these are equivalent.  This is just a list of
>> stackforge/networking-*.
>>
>> In some cases there is a split between code in the Neutron tree and in
>> this repo.  In those cases, a shim is in the Neutron tree, but most of
>> the code is in the external repo.  It's also possible to have all of the
>> code in the external repo.
>>
>> There's also a big range of maturity.  Some are quite mature and are
>> already used in production.  networking-ovn as an example is quite new
>> and being developed in parallel with OVN in the Open vSwitch project.
>>
>>
>> So, my question is: Where should these repositories live in terms of
>> OpenStack governance and project teams?
>>
>> Here are a few paths I think we could take, along with some of my
>> initial thoughts on pros/cons.
>>
>> a) Adopt these as repositories under the Neutron project team.
>>
>> In this case, I would see them operating with their own review teams as
>> they do today to avoid imposing additional load on the neutron-core or
>> neutron-specs-core teams.  However, by being a part of the Neutron team,
>> the backend team would submit to oversight by the Neutron PTL.
>>
> Out of your options proposed, this seems like the most logical one to me. I
> don't really see this imposing a ton of strain on the existing core reviewer
> team, because we'll keep whatever core reviewer teams are already in the
> networking-foo projects.
>
>>
>> There are some other details to work out to ensure expectations are
>> clearly set for everyone involved.  If this is the path that makes
>> sense, we can work through those as a next step.
>>
>> Pros:
>>  + Seems to be the most natural first choice
>>
>> Cons:
>>  - A lot of changes have been made precisely because Neutron has gotten
>> so big.  A single project team/PTL may not be able to effectively
>> coordinate all of the addi

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Anita Kuno]

On 04/22/2015 09:46 PM, Kyle Mestery wrote:
> On Wed, Apr 22, 2015 at 7:44 PM, Armando M.  wrote:
> 
>>
>>
>> On 22 April 2015 at 11:19, Russell Bryant  wrote:
>>
>>> Hello!
>>>
>>> A couple of things I've been working on lately are project governance
>>> issues as a TC member and also implementation of a new virtual
>>> networking alternative with a Neutron driver.  So, naturally I started
>>> thinking about how the Neutron driver code fits in to OpenStack
>>> governance.
>>>
>>> There are basically two areas with a lot of movement related to this
>>> issue.
>>>
>>> 1) Project governance has moved to a "big tent" model [1].  The vast
>>> majority of projects that used to be in Stackforge are being folded in
>>> to a larger definition of the OpenStack project.  Projects making this
>>> move meet the following criteria as being "one of us":
>>
>>
>> Is it sensible to assume that Stackforge is going away entirely at some
>> point in the future, and we'll have a single namespace - OpenStack?
>>
>>
> 
> IMHO, I'm not sure what the StackForge designation means anymore now that
> we have the Big Tent. I obviously also don't have the authority to make the
> call on when it goes away however.
Moving everything from Stackforge into the OpenStack namespace is
something that Jim Blair has said he would like to see happen. There has
been no resolution or focused discussion on this exact point that has
been put before the TC that I have seen.

Thanks,
Anita.
> 
> 
>>
>>> http://governance.openstack.org/reference/new-projects-requirements.html
>>>
>>> Official project teams are tracked in this file along with the git repos
>>> they are responsible for:
>>>
>>>
>>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>>
>>> which is also reflected here:
>>>
>>> http://governance.openstack.org/reference/projects/
>>>
>>> The TC has also been working through defining a system to help
>>> differentiate efforts by using a set of "tags" [4].  So far, we have
>>> tags describing the release handling for a repository, as well as a tag
>>> for team diversity.  We've also had a lot of discussion about tags to
>>> help describe maturity, but that is still a work in progress.
>>>
>>>
>>> 2) In Neutron, some fairly significant good changes are being made to
>>> help scale the development process.  Advanced services were split out
>>> into their own repos [2].  Most of the plugin and driver code has also
>>> been split out into repos [3].
>>>
>>
>> This is too still a work in progress. A lot has been achieved during the
>> Kilo timeframe, but more is still to be done, like the 'lib-ification - if
>> that's even a word' of Neutron [1a], the split of plugins out of the *aas
>> drivers [2b], and the rest of the core-vendor-decomp (latest status update
>> is available in [3b])
>>
>>
> Don't forget about the split out of the tree of the reference
> implementation, defined here:
> 
> https://review.openstack.org/#/c/176501/
> 
> 
>> [1a] https://review.openstack.org/#/c/154736/
>> [2b] https://review.openstack.org/#/c/174619/
>> [3b] https://review.openstack.org/#/c/173549/
>>
>>
>>>
>>> In terms of project teams, the Neutron team is defined as owning the
>>> following repos:
>>>
>>>   http://governance.openstack.org/reference/projects/neutron.html
>>>
>>>  - openstack/neutron
>>>  - openstack/neutron-fwaas
>>>  - openstack/neutron-lbaas
>>>  - openstack/neutron-vpnaas
>>>  - openstack/neutron-specs
>>>  - openstack/python-neutronclient
>>>
>>> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
>>> repos.
>>>
>>> We also have a large set of repositories related to Neutron backend code:
>>>
>>>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>>>
>>>  - stackforge/networking-arista
>>>  - stackforge/networking-bagpipe-l2
>>>  - stackforge/networking-bgpvpn
>>>  - stackforge/networking-bigswitch
>>>  - stackforge/networking-brocade
>>>  - stackforge/networking-cisco
>>>  - stackforge/networking-edge-vpn
>>>  - stackforge/networking-hyperv
>>>  - stackforge/networking-ibm
>>>  - stackforge/networking-l2gw
>>>  - stackforge/networking-midonet
>>>  - stackforge/networking-mlnx
>>>  - stackforge/networking-nec
>>>  - stackforge/networking-odl
>>>  - stackforge/networking-ofagent
>>>  - stackforge/networking-ovn
>>>  - stackforge/networking-ovs-dpdk
>>>  - stackforge/networking-plumgrid
>>>  - stackforge/networking-portforwarding
>>>  - stackforge/networking-vsphere
>>>
>>> Note that not all of these are equivalent.  This is just a list of
>>> stackforge/networking-*.
>>>
>>> In some cases there is a split between code in the Neutron tree and in
>>> this repo.  In those cases, a shim is in the Neutron tree, but most of
>>> the code is in the external repo.  It's also possible to have all of the
>>> code in the external repo.
>>>
>>> There's also a big range of maturity.  Some are quite mature and are
>>> already used in production.  networking-ovn as an example is quite new
>>> and being

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Wed, Apr 22, 2015 at 7:44 PM, Armando M.  wrote:

>
>
> On 22 April 2015 at 11:19, Russell Bryant  wrote:
>
>> Hello!
>>
>> A couple of things I've been working on lately are project governance
>> issues as a TC member and also implementation of a new virtual
>> networking alternative with a Neutron driver.  So, naturally I started
>> thinking about how the Neutron driver code fits in to OpenStack
>> governance.
>>
>> There are basically two areas with a lot of movement related to this
>> issue.
>>
>> 1) Project governance has moved to a "big tent" model [1].  The vast
>> majority of projects that used to be in Stackforge are being folded in
>> to a larger definition of the OpenStack project.  Projects making this
>> move meet the following criteria as being "one of us":
>
>
> Is it sensible to assume that Stackforge is going away entirely at some
> point in the future, and we'll have a single namespace - OpenStack?
>
>

IMHO, I'm not sure what the StackForge designation means anymore now that
we have the Big Tent. I obviously also don't have the authority to make the
call on when it goes away however.


>
>> http://governance.openstack.org/reference/new-projects-requirements.html
>>
>> Official project teams are tracked in this file along with the git repos
>> they are responsible for:
>>
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>>
>> which is also reflected here:
>>
>> http://governance.openstack.org/reference/projects/
>>
>> The TC has also been working through defining a system to help
>> differentiate efforts by using a set of "tags" [4].  So far, we have
>> tags describing the release handling for a repository, as well as a tag
>> for team diversity.  We've also had a lot of discussion about tags to
>> help describe maturity, but that is still a work in progress.
>>
>>
>> 2) In Neutron, some fairly significant good changes are being made to
>> help scale the development process.  Advanced services were split out
>> into their own repos [2].  Most of the plugin and driver code has also
>> been split out into repos [3].
>>
>
> This is too still a work in progress. A lot has been achieved during the
> Kilo timeframe, but more is still to be done, like the 'lib-ification - if
> that's even a word' of Neutron [1a], the split of plugins out of the *aas
> drivers [2b], and the rest of the core-vendor-decomp (latest status update
> is available in [3b])
>
>
Don't forget about the split out of the tree of the reference
implementation, defined here:

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


> [1a] https://review.openstack.org/#/c/154736/
> [2b] https://review.openstack.org/#/c/174619/
> [3b] https://review.openstack.org/#/c/173549/
>
>
>>
>> In terms of project teams, the Neutron team is defined as owning the
>> following repos:
>>
>>   http://governance.openstack.org/reference/projects/neutron.html
>>
>>  - openstack/neutron
>>  - openstack/neutron-fwaas
>>  - openstack/neutron-lbaas
>>  - openstack/neutron-vpnaas
>>  - openstack/neutron-specs
>>  - openstack/python-neutronclient
>>
>> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
>> repos.
>>
>> We also have a large set of repositories related to Neutron backend code:
>>
>>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>>
>>  - stackforge/networking-arista
>>  - stackforge/networking-bagpipe-l2
>>  - stackforge/networking-bgpvpn
>>  - stackforge/networking-bigswitch
>>  - stackforge/networking-brocade
>>  - stackforge/networking-cisco
>>  - stackforge/networking-edge-vpn
>>  - stackforge/networking-hyperv
>>  - stackforge/networking-ibm
>>  - stackforge/networking-l2gw
>>  - stackforge/networking-midonet
>>  - stackforge/networking-mlnx
>>  - stackforge/networking-nec
>>  - stackforge/networking-odl
>>  - stackforge/networking-ofagent
>>  - stackforge/networking-ovn
>>  - stackforge/networking-ovs-dpdk
>>  - stackforge/networking-plumgrid
>>  - stackforge/networking-portforwarding
>>  - stackforge/networking-vsphere
>>
>> Note that not all of these are equivalent.  This is just a list of
>> stackforge/networking-*.
>>
>> In some cases there is a split between code in the Neutron tree and in
>> this repo.  In those cases, a shim is in the Neutron tree, but most of
>> the code is in the external repo.  It's also possible to have all of the
>> code in the external repo.
>>
>> There's also a big range of maturity.  Some are quite mature and are
>> already used in production.  networking-ovn as an example is quite new
>> and being developed in parallel with OVN in the Open vSwitch project.
>>
>>
>> So, my question is: Where should these repositories live in terms of
>> OpenStack governance and project teams?
>
>
> It's my understanding that StackForge projects are bound to the same
> governance model, or am I mistaken?
>
>
I'm not sure they are.


>> Here are a few paths I think we could take, along with some of my
>> initial thoughts on pros/cons.
>>
>> a) Adopt these as re

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Armando M.]

On 22 April 2015 at 11:19, Russell Bryant  wrote:

> Hello!
>
> A couple of things I've been working on lately are project governance
> issues as a TC member and also implementation of a new virtual
> networking alternative with a Neutron driver.  So, naturally I started
> thinking about how the Neutron driver code fits in to OpenStack governance.
>
> There are basically two areas with a lot of movement related to this issue.
>
> 1) Project governance has moved to a "big tent" model [1].  The vast
> majority of projects that used to be in Stackforge are being folded in
> to a larger definition of the OpenStack project.  Projects making this
> move meet the following criteria as being "one of us":


Is it sensible to assume that Stackforge is going away entirely at some
point in the future, and we'll have a single namespace - OpenStack?


>
> http://governance.openstack.org/reference/new-projects-requirements.html
>
> Official project teams are tracked in this file along with the git repos
> they are responsible for:
>
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> which is also reflected here:
>
> http://governance.openstack.org/reference/projects/
>
> The TC has also been working through defining a system to help
> differentiate efforts by using a set of "tags" [4].  So far, we have
> tags describing the release handling for a repository, as well as a tag
> for team diversity.  We've also had a lot of discussion about tags to
> help describe maturity, but that is still a work in progress.
>
>
> 2) In Neutron, some fairly significant good changes are being made to
> help scale the development process.  Advanced services were split out
> into their own repos [2].  Most of the plugin and driver code has also
> been split out into repos [3].
>

This is too still a work in progress. A lot has been achieved during the
Kilo timeframe, but more is still to be done, like the 'lib-ification - if
that's even a word' of Neutron [1a], the split of plugins out of the *aas
drivers [2b], and the rest of the core-vendor-decomp (latest status update
is available in [3b])

[1a] https://review.openstack.org/#/c/154736/
[2b] https://review.openstack.org/#/c/174619/
[3b] https://review.openstack.org/#/c/173549/


>
> In terms of project teams, the Neutron team is defined as owning the
> following repos:
>
>   http://governance.openstack.org/reference/projects/neutron.html
>
>  - openstack/neutron
>  - openstack/neutron-fwaas
>  - openstack/neutron-lbaas
>  - openstack/neutron-vpnaas
>  - openstack/neutron-specs
>  - openstack/python-neutronclient
>
> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
> repos.
>
> We also have a large set of repositories related to Neutron backend code:
>
>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>
>  - stackforge/networking-arista
>  - stackforge/networking-bagpipe-l2
>  - stackforge/networking-bgpvpn
>  - stackforge/networking-bigswitch
>  - stackforge/networking-brocade
>  - stackforge/networking-cisco
>  - stackforge/networking-edge-vpn
>  - stackforge/networking-hyperv
>  - stackforge/networking-ibm
>  - stackforge/networking-l2gw
>  - stackforge/networking-midonet
>  - stackforge/networking-mlnx
>  - stackforge/networking-nec
>  - stackforge/networking-odl
>  - stackforge/networking-ofagent
>  - stackforge/networking-ovn
>  - stackforge/networking-ovs-dpdk
>  - stackforge/networking-plumgrid
>  - stackforge/networking-portforwarding
>  - stackforge/networking-vsphere
>
> Note that not all of these are equivalent.  This is just a list of
> stackforge/networking-*.
>
> In some cases there is a split between code in the Neutron tree and in
> this repo.  In those cases, a shim is in the Neutron tree, but most of
> the code is in the external repo.  It's also possible to have all of the
> code in the external repo.
>
> There's also a big range of maturity.  Some are quite mature and are
> already used in production.  networking-ovn as an example is quite new
> and being developed in parallel with OVN in the Open vSwitch project.
>
>
> So, my question is: Where should these repositories live in terms of
> OpenStack governance and project teams?


It's my understanding that StackForge projects are bound to the same
governance model, or am I mistaken?


>
> Here are a few paths I think we could take, along with some of my
> initial thoughts on pros/cons.
>
> a) Adopt these as repositories under the Neutron project team.
>

I fully understand how this is implemented in, can you elaborate? Would
that translate into something like [4a]? The other concern I have is that
the list is bound to change due to the WIP nature of the work we're going
through, and I wouldn't want to freeze it just yet, as we can't.

Would just renaming the existing repos from stackforge/* to openstack/*
suffice? Do we ask people to submit the new ones to the openstack namespace
from now on? Would that slow down their ability to decompose because

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Brandon Logan]

I prefer option a) as well.  It does seem like most of the projects would 
really see no change at all other than being officially sanctioned as an 
Openstack project with some kind of tag. There's also the possibility the PTL 
may request some changes to improve the bigger picture of the 
Networking/Neutron project.  Other than that it sounds like nothing much would 
change.​  Is this to solve the whole issue regarding projects graduating to 
become openstack projects?  If so, it sounds like those issues might just be 
shuffled to the decision of whether a project should "graduate" to a "better" 
tag.  I'm sure this has come up in the tags discussions, and its a bit out of 
scope of this email, but it's just a concern I have.


Thanks,

Brandon


From: Fox, Kevin M 
Sent: Wednesday, April 22, 2015 2:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

+1

I was in the middle of writing an email asking about the possibility of 
splitting out the reference implementation. you beat me to it. :)

I also like the idea of having the PTL on top to help pass up/down ideas where 
code can be shared, benefiting everyone.

Thanks,
Kevin

From: Kyle Mestery [mest...@mestery.com]
Sent: Wednesday, April 22, 2015 12:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
Hello!

A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

Thanks for starting this conversation Russell.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a "big tent" model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being "one of us":

http://governance.openstack.org/reference/new-projects-requirements.html

Official project teams are tracked in this file along with the git repos
they are responsible for:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

which is also reflected here:

http://governance.openstack.org/reference/projects/

The TC has also been working through defining a system to help
differentiate efforts by using a set of "tags" [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.


2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:

  http://governance.openstack.org/reference/projects/neutron.html

 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas
repos.

We also have a large set of repositories related to Neutron backend code:

  http://git.openstack.org/cgit/?q=stackforge%2Fnetworking

 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of
stackforge/networking-*.

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Fox, Kevin M]

+1

I was in the middle of writing an email asking about the possibility of 
splitting out the reference implementation. you beat me to it. :)

I also like the idea of having the PTL on top to help pass up/down ideas where 
code can be shared, benefiting everyone.

Thanks,
Kevin

From: Kyle Mestery [mest...@mestery.com]
Sent: Wednesday, April 22, 2015 12:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
Hello!

A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

Thanks for starting this conversation Russell.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a "big tent" model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being "one of us":

http://governance.openstack.org/reference/new-projects-requirements.html

Official project teams are tracked in this file along with the git repos
they are responsible for:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

which is also reflected here:

http://governance.openstack.org/reference/projects/

The TC has also been working through defining a system to help
differentiate efforts by using a set of "tags" [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.


2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:

  http://governance.openstack.org/reference/projects/neutron.html

 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas
repos.

We also have a large set of repositories related to Neutron backend code:

  http://git.openstack.org/cgit/?q=stackforge%2Fnetworking

 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of
stackforge/networking-*.

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed in parallel with OVN in the Open vSwitch project.


So, my question is: Where should these repositories live in terms of
OpenStack governance and project teams?

Here are a few paths I think we could take, along with some of my
initial thoughts on pros/cons.

a) Adopt these as repositories under the Neutron project team.

In this case, I would see them operating with their own review teams as
they do today to avoid imposing additional load on the neutron-core or
neutron-specs-core teams.  However, by being a part of the Neutron team,
the backend team would submit to oversight by the Neutron PTL.

Out of your options proposed, this seems like the most logical one to me. I 
don't really see this imposing a ton of strain on the existing core reviewer 
team, because we'll keep whatever core reviewer teams are already in the 
networking-foo projects.

There are some other details to work out to ensure expectations are
clearly set for everyone involved.  If this is the path that makes
sense, we can work through 

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

[Kyle Mestery]

On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant  wrote:

> Hello!
>
> A couple of things I've been working on lately are project governance
> issues as a TC member and also implementation of a new virtual
> networking alternative with a Neutron driver.  So, naturally I started
> thinking about how the Neutron driver code fits in to OpenStack governance.
>
> Thanks for starting this conversation Russell.


> There are basically two areas with a lot of movement related to this issue.
>
> 1) Project governance has moved to a "big tent" model [1].  The vast
> majority of projects that used to be in Stackforge are being folded in
> to a larger definition of the OpenStack project.  Projects making this
> move meet the following criteria as being "one of us":
>
> http://governance.openstack.org/reference/new-projects-requirements.html
>
> Official project teams are tracked in this file along with the git repos
> they are responsible for:
>
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> which is also reflected here:
>
> http://governance.openstack.org/reference/projects/
>
> The TC has also been working through defining a system to help
> differentiate efforts by using a set of "tags" [4].  So far, we have
> tags describing the release handling for a repository, as well as a tag
> for team diversity.  We've also had a lot of discussion about tags to
> help describe maturity, but that is still a work in progress.
>
>
> 2) In Neutron, some fairly significant good changes are being made to
> help scale the development process.  Advanced services were split out
> into their own repos [2].  Most of the plugin and driver code has also
> been split out into repos [3].
>
> In terms of project teams, the Neutron team is defined as owning the
> following repos:
>
>   http://governance.openstack.org/reference/projects/neutron.html
>
>  - openstack/neutron
>  - openstack/neutron-fwaas
>  - openstack/neutron-lbaas
>  - openstack/neutron-vpnaas
>  - openstack/neutron-specs
>  - openstack/python-neutronclient
>
> The advanced services split is reflected by the fwaas, lbaas, and vpnaas
> repos.
>
> We also have a large set of repositories related to Neutron backend code:
>
>   http://git.openstack.org/cgit/?q=stackforge%2Fnetworking
>
>  - stackforge/networking-arista
>  - stackforge/networking-bagpipe-l2
>  - stackforge/networking-bgpvpn
>  - stackforge/networking-bigswitch
>  - stackforge/networking-brocade
>  - stackforge/networking-cisco
>  - stackforge/networking-edge-vpn
>  - stackforge/networking-hyperv
>  - stackforge/networking-ibm
>  - stackforge/networking-l2gw
>  - stackforge/networking-midonet
>  - stackforge/networking-mlnx
>  - stackforge/networking-nec
>  - stackforge/networking-odl
>  - stackforge/networking-ofagent
>  - stackforge/networking-ovn
>  - stackforge/networking-ovs-dpdk
>  - stackforge/networking-plumgrid
>  - stackforge/networking-portforwarding
>  - stackforge/networking-vsphere
>
> Note that not all of these are equivalent.  This is just a list of
> stackforge/networking-*.
>
> In some cases there is a split between code in the Neutron tree and in
> this repo.  In those cases, a shim is in the Neutron tree, but most of
> the code is in the external repo.  It's also possible to have all of the
> code in the external repo.
>
> There's also a big range of maturity.  Some are quite mature and are
> already used in production.  networking-ovn as an example is quite new
> and being developed in parallel with OVN in the Open vSwitch project.
>
>
> So, my question is: Where should these repositories live in terms of
> OpenStack governance and project teams?
>
> Here are a few paths I think we could take, along with some of my
> initial thoughts on pros/cons.
>
> a) Adopt these as repositories under the Neutron project team.
>
> In this case, I would see them operating with their own review teams as
> they do today to avoid imposing additional load on the neutron-core or
> neutron-specs-core teams.  However, by being a part of the Neutron team,
> the backend team would submit to oversight by the Neutron PTL.
>
> Out of your options proposed, this seems like the most logical one to me.
I don't really see this imposing a ton of strain on the existing core
reviewer team, because we'll keep whatever core reviewer teams are already
in the networking-foo projects.


> There are some other details to work out to ensure expectations are
> clearly set for everyone involved.  If this is the path that makes
> sense, we can work through those as a next step.
>
> Pros:
>  + Seems to be the most natural first choice
>
> Cons:
>  - A lot of changes have been made precisely because Neutron has gotten
> so big.  A single project team/PTL may not be able to effectively
> coordinate all of the additional work.  Maybe the core Neutron project
> would be better off focusing on being a platform, and other project
> teams organize work on backends.
>
> It's interesting you mention neutron 

[openstack-dev] [Neutron] A big tent home for Neutron backend code

[Russell Bryant]

Hello!

A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a "big tent" model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being "one of us":

http://governance.openstack.org/reference/new-projects-requirements.html

Official project teams are tracked in this file along with the git repos
they are responsible for:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

which is also reflected here:

http://governance.openstack.org/reference/projects/

The TC has also been working through defining a system to help
differentiate efforts by using a set of "tags" [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.


2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:

  http://governance.openstack.org/reference/projects/neutron.html

 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas
repos.

We also have a large set of repositories related to Neutron backend code:

  http://git.openstack.org/cgit/?q=stackforge%2Fnetworking

 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of
stackforge/networking-*.

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed in parallel with OVN in the Open vSwitch project.


So, my question is: Where should these repositories live in terms of
OpenStack governance and project teams?

Here are a few paths I think we could take, along with some of my
initial thoughts on pros/cons.

a) Adopt these as repositories under the Neutron project team.

In this case, I would see them operating with their own review teams as
they do today to avoid imposing additional load on the neutron-core or
neutron-specs-core teams.  However, by being a part of the Neutron team,
the backend team would submit to oversight by the Neutron PTL.

There are some other details to work out to ensure expectations are
clearly set for everyone involved.  If this is the path that makes
sense, we can work through those as a next step.

Pros:
 + Seems to be the most natural first choice

Cons:
 - A lot of changes have been made precisely because Neutron has gotten
so big.  A single project team/PTL may not be able to effectively
coordinate all of the additional work.  Maybe the core Neutron project
would be better off focusing on being a platform, and other project
teams organize work on backends.

b) Let each interested group define a new project team for their backend
code.

So, as an example, the group of people working on Neutron integration
with OpenDaylight could propose a new project team that would be a
projects.yaml entry that looks something like:

Neutron-OpenDaylight:
  ptl: Some Person (ircnick)
  service: OpenDaylight Networking
  mission: >
To implement Neutron support for the OpenDaylight project.
  url: ...
  projects:
- repo: openstack/networking-odl

Pros:
 + There's no additional load on the Neutron project team and PTL.

Cons:
 - Having all of these efforts organized