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
