Open Stack

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.Jerram at 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 at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev