Open Stack

On 04/29/2015 12:33 PM, 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 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