Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
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 mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant rbry...@redhat.com [...] 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
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
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
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 __ 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
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
On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 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 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 implying some sort of benefit but I cannot define what the benefit actually is. Cons: - A lot of changes have been made precisely because Neutron has gotten so big. A single project team/PTL may not be able
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On 2015-04-29 16:46:13 -0700 (-0700), Joe Gordon wrote: On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant rbry...@redhat.com [...] 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
On Thu, Apr 30, 2015 at 2:44 AM, Russell Bryant rbry...@redhat.com 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
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
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
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 mathieu.ro...@gmail.com 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 henry4...@gmail.commailto:henry4...@gmail.com wrote: On Thu, Apr 23, 2015 at 10:44 AM, Armando M. arma...@gmail.commailto: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. 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
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Mon, Apr 27, 2015 at 3:58 PM, Russell Bryant rbry...@redhat.com 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
On Tue, Apr 28, 2015 at 8:00 AM, Russell Bryant rbry...@redhat.com 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
On Tue, Apr 28, 2015 at 12:17 PM, Neil Jerram neil.jer...@metaswitch.com 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 mathieu.ro...@gmail.com *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 henry4...@gmail.com wrote: On Thu, Apr 23, 2015 at 10:44 AM, Armando M. 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
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
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
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
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
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. arma...@gmail.com wrote: On 22 April 2015 at 11:19, Russell Bryant 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. 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
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
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 :) -- 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
On 23 April 2015 at 01:49, Thierry Carrez thie...@openstack.org 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
On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto: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. 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
On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto: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. -- 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
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
On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M kevin@pnnl.gov 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
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
+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 OVSLB, 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 - openstack/networking-portforwarding - openstack/networking-vsphere Pros
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto: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 -- 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
On 04/23/2015 03:23 PM, Kyle Mestery wrote: On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto: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. 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
On Apr 23, 2015, at 1:42 PM, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 03:23 PM, Kyle Mestery wrote: On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto: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. 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
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 doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 1:42 PM, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 03:23 PM, Kyle Mestery wrote: On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.com mailto:doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto: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. 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
On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 11:57 AM, Russell Bryant rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto: rbry...@redhat.com mailto:rbry...@redhat.com mailto: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
Russell Bryant wrote: On 04/23/2015 03:23 PM, Kyle Mestery wrote: On Thu, Apr 23, 2015 at 2:18 PM, Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote: On Apr 23, 2015, at 11:57 AM, Russell Bryantrbry...@redhat.com mailto:rbry...@redhat.com wrote: On 04/23/2015 01:19 PM, Armando M. wrote: On 23 April 2015 at 09:58, Russell Bryantrbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.commailto:rbry...@redhat.com wrote: On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryantrbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.com mailto:rbry...@redhat.commailto:rbry...@redhat.com mailto:rbry...@redhat.commailto: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. 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
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
On 04/23/2015 12:14 PM, Armando M. wrote: On 23 April 2015 at 07:32, Russell Bryant rbry...@redhat.com mailto: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. -- 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
On Thu, Apr 23, 2015 at 10:28 AM, henry hly henry4...@gmail.com wrote: On Thu, Apr 23, 2015 at 10:44 AM, Armando M. 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. 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 OVSLB, 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
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Thu, Apr 23, 2015 at 10:44 AM, Armando M. 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 [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 OVSLB, 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
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
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
[openstack-dev] [Neutron] A big tent home for Neutron backend code
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 under
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 rbry...@redhat.commailto: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 those as a next step. Pros: + Seems to be the most natural
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 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 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 being a platform, because that's exactly where I want it to go in Liberty as well. To that end, I expect to
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
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
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 OVSLB, 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 - openstack/networking-portforwarding - openstack/networking-vsphere Pros: + There's no additional load on the Neutron project team and PTL. + Avoids a proliferation of new project teams for each Neutron backend. + Puts efforts
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On 22 April 2015 at 11:19, Russell Bryant 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. 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 the big tent is not there yet? [4a] https://review.openstack.org/#/c/175954 In
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Wed, Apr 22, 2015 at 7:44 PM, Armando M. arma...@gmail.com wrote: On 22 April 2015 at 11:19, Russell Bryant 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. 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 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
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
On Thu, Apr 23, 2015 at 3:30 AM, Kyle Mestery mest...@mestery.com wrote: On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant 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 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 being a platform, because
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
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 kevin@pnnl.gov 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 rbry...@redhat.commailto: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
