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