I agree with Armando that at the end of the day user requirements should drive these decisions. I think you did a good job in listing what are the pro and the cons of choosing standalone plugin rather than a ML2 driver.
The most important point you made, in my opinion, concerns the ability of supporting multiple backends. I find your analysis correct; however I might simplify it by saying that as the Calico driver is probably unlikely to interact with any other mechanism driver, then the remaining value of adopting ML2 is probably more a way to re-use code and implement common Neutron "paradigms" - and as you wrote you can still retain ML2's architecture even in a new plugin. Further, it is also true what Ian wrote - even with a standalone plugin you will still be constrained by entities which are meant to represent L2 constructs. Salvatore On 24 January 2016 at 23:45, Armando M. <arma...@gmail.com> wrote: > > > On 22 January 2016 at 10:35, Neil Jerram <neil.jer...@metaswitch.com> > wrote: > >> networking-calico [1] is currently implemented as an ML2 mechanism >> driver, but >> I'm wondering if it might be better as its own core plugin, and I'm >> looking for >> input about the implications of that, or for experience with that kind of >> change; and also for experience and understanding of hybrid ML2 >> networking. >> >> Here the considerations that I'm aware of: >> >> * Why change from ML2 to core plugin? >> >> - It could be seen as resolving a conceptual mismatch. >> networking-calico uses >> IP routing to provide L3 connectivity between VMs, whereas ML2 is >> ostensibly >> all about layer 2 mechanisms. Arguably it's the Wrong Thing for a >> L3-based >> network to be implemented as an ML2 driver, and changing to a core >> plugin >> would fix that. >> >> On the other hand, the current ML2 implementation seems to work fine, >> and I >> think that the L2 focus of ML2 may be seen as traditional assumption >> just >> like the previously assumed L2 semantics of neutron Networks; and it >> may be >> that the scope of 'ML2' could and should be expanded to both L2- and >> L3-based >> implementations, just as [2] is proposing to expand the scope of the >> neutron >> Network object to encompass L3-only behaviour as well as L2/L3. >> >> - Some simplification of the required config. A single 'core_plugin = >> calico' >> setting could replace 'core_plugin = ml2' plus a handful of ML2 >> settings. >> >> - Code-wise, it's a much smaller change than you might imagine, because >> the new >> core plugin can still derive from ML2, and so internally retain the ML2 >> coding architecture. >> >> * Why stay as an ML2 driver? >> >> - Perhaps because of ML2's support for multiple networking >> implementations in >> the same cluster. To the extent that it makes sense, I'd like >> networking-calico networks to coexist with other networking >> implementations >> in the same data center. >> >> But I'm not sure to what extent such hybrid networking is a real >> thing, and >> this is the main point on which I'd appreciate input. In principle ML2 >> supports multiple network Types and multiple network Mechanisms, but I >> wonder >> how far that really works - or is useful - in practice. >> >> Let's look at Types first. ML2 supports multiple provider network >> types, >> with the Type for each network being specified explicitly by the >> provider API >> extension (provider:network_type), or else defaulting to the >> 'external_network_type' ML2 config setting. However, would a cloud >> operator >> ever actually use more than one provider Type? My understanding is that >> provider networks are designed to map closely onto the real network, >> and I >> guess that an operator would also favour a uniform design there, hence >> just >> using a single provider network Type. >> >> For tenant networks ML2 allows multiple network Types to be configured >> in the >> 'tenant_network_types' setting. However, if my reading of the code is >> correct, only the first of these Types will ever be used for a tenant >> network >> - unless the system runs out of the 'resources' needed for that Type, >> for >> example if the first Type is 'vlan' but there are no VLAN IDs left to >> use. >> Is that a feature that is used in practice, within a given >> deployment? For >> exampe, to first use VLANs for tenant networks, then switch to >> something else >> when those run out? >> >> ML2 also supports multiple mechanism drivers. When a new Port is being >> created, ML2 calls each mechanism driver to give it the chance to do >> binding >> and connectivity setup for that Port. In principle, if mechanism >> drivers are >> present, I guess each one is supposed to look at some of the available >> Port >> data - and perhaps the network Type - and thereby infer whether it >> should be >> responsible for that Port, and so do the setup for it. But I wonder if >> anyone runs a cloud where that really happens? If so, have I got it >> right? >> > > Have you consider asking these questions to your 'customers'? They are the > ones you should listen to :) > > Ultimately both choices are reasonably valid and both have pros and cons: > moving away from ML2 frees you up and let you be fully in control but > you'll lose access to compl(i|e)mentary L2 and L3 services. Do you need > those? That's up to you and/or your customers. There's no right nor wrong, > but knowing that calico has an already unique relationship with Neutron > (which you worked hard to nail down) and the ongoing effort [1], perhaps > it's safer to stay put for a cycle and see how that plays out. > > OVN went down the same decision making process, you may want to reach out > to those folks to see what their opinion was, and reconsider the urgency of > the switch. > > Should you switch, you should also take in consideration the cost of > migrating (if you have existing deployments). > > Cheers, > Armando > > [1] https://review.openstack.org/#/c/225384/ > > >> >> All in all, if hybrid ML2 networking is a really used thing, I'd like to >> make >> sure I fully understand it, and would tend to prefer networking-calico >> remaining as an ML2 mechanism driver. (Which means I also need to discuss >> further about conceptually extending 'ML2' to L3-only implementations, and >> raise another point about what happens when the service_plugin that you >> need >> for some extension - say a floating IP - depends on which mechanism >> driver was >> used to set up the relevant Port...) But if not, perhaps it would be a >> better >> choice for networking-calico to be its own core plugin. >> >> Thanks for reading! What do you think? >> >> Neil >> >> >> [1] http://docs.openstack.org/developer/networking-calico/ >> [2] https://review.openstack.org/#/c/225384/ >> >> >> __________________________________________________________________________ >> 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
