Open Stack

‎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