<div dir="ltr">I agree with Armando that at the end of the day user requirements should drive these decisions.<div>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.<br></div><div><br></div><div>The most important point you made, in my opinion, concerns the ability of supporting multiple backends.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 January 2016 at 23:45, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 22 January 2016 at 10:35, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">networking-calico [1] is currently implemented as an ML2 mechanism<br>
driver, but<br>
I'm wondering if it might be better as its own core plugin, and I'm<br>
looking for<br>
input about the implications of that, or for experience with that kind of<br>
change; and also for experience and understanding of hybrid ML2<br>
networking.<br>
<br>
Here the considerations that I'm aware of:<br>
<br>
* Why change from ML2 to core plugin?<br>
<br>
- It could be seen as resolving a conceptual mismatch.<br>
networking-calico uses<br>
IP routing to provide L3 connectivity between VMs, whereas ML2 is<br>
ostensibly<br>
all about layer 2 mechanisms. Arguably it's the Wrong Thing for a<br>
L3-based<br>
network to be implemented as an ML2 driver, and changing to a core plugin<br>
would fix that.<br>
<br>
On the other hand, the current ML2 implementation seems to work fine,<br>
and I<br>
think that the L2 focus of ML2 may be seen as traditional assumption just<br>
like the previously assumed L2 semantics of neutron Networks; and it<br>
may be<br>
that the scope of 'ML2' could and should be expanded to both L2- and<br>
L3-based<br>
implementations, just as [2] is proposing to expand the scope of the<br>
neutron<br>
Network object to encompass L3-only behaviour as well as L2/L3.<br>
<br>
- Some simplification of the required config. A single 'core_plugin =<br>
calico'<br>
setting could replace 'core_plugin = ml2' plus a handful of ML2 settings.<br>
<br>
- Code-wise, it's a much smaller change than you might imagine, because<br>
the new<br>
core plugin can still derive from ML2, and so internally retain the ML2<br>
coding architecture.<br>
<br>
* Why stay as an ML2 driver?<br>
<br>
- Perhaps because of ML2's support for multiple networking<br>
implementations in<br>
the same cluster. To the extent that it makes sense, I'd like<br>
networking-calico networks to coexist with other networking<br>
implementations<br>
in the same data center.<br>
<br>
But I'm not sure to what extent such hybrid networking is a real<br>
thing, and<br>
this is the main point on which I'd appreciate input. In principle ML2<br>
supports multiple network Types and multiple network Mechanisms, but I<br>
wonder<br>
how far that really works - or is useful - in practice.<br>
<br>
Let's look at Types first. ML2 supports multiple provider network types,<br>
with the Type for each network being specified explicitly by the<br>
provider API<br>
extension (provider:network_type), or else defaulting to the<br>
'external_network_type' ML2 config setting. However, would a cloud<br>
operator<br>
ever actually use more than one provider Type? My understanding is that<br>
provider networks are designed to map closely onto the real network, and I<br>
guess that an operator would also favour a uniform design there, hence<br>
just<br>
using a single provider network Type.<br>
<br>
For tenant networks ML2 allows multiple network Types to be configured<br>
in the<br>
'tenant_network_types' setting. However, if my reading of the code is<br>
correct, only the first of these Types will ever be used for a tenant<br>
network<br>
- unless the system runs out of the 'resources' needed for that Type, for<br>
example if the first Type is 'vlan' but there are no VLAN IDs left to use.<br>
Is that a feature that is used in practice, within a given<br>
deployment? For<br>
exampe, to first use VLANs for tenant networks, then switch to<br>
something else<br>
when those run out?<br>
<br>
ML2 also supports multiple mechanism drivers. When a new Port is being<br>
created, ML2 calls each mechanism driver to give it the chance to do<br>
binding<br>
and connectivity setup for that Port. In principle, if mechanism<br>
drivers are<br>
present, I guess each one is supposed to look at some of the available<br>
Port<br>
data - and perhaps the network Type - and thereby infer whether it<br>
should be<br>
responsible for that Port, and so do the setup for it. But I wonder if<br>
anyone runs a cloud where that really happens? If so, have I got it<br>
right?<br></blockquote><div><br></div></div></div><div>Have you consider asking these questions to your 'customers'? They are the ones you should listen to :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Should you switch, you should also take in consideration the cost of migrating (if you have existing deployments).</div><div> </div><div>Cheers,</div><div>Armando</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/225384/" target="_blank">https://review.openstack.org/#/c/225384/</a></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
All in all, if hybrid ML2 networking is a really used thing, I'd like to<br>
make<br>
sure I fully understand it, and would tend to prefer networking-calico<br>
remaining as an ML2 mechanism driver. (Which means I also need to discuss<br>
further about conceptually extending 'ML2' to L3-only implementations, and<br>
raise another point about what happens when the service_plugin that you need<br>
for some extension - say a floating IP - depends on which mechanism<br>
driver was<br>
used to set up the relevant Port...) But if not, perhaps it would be a<br>
better<br>
choice for networking-calico to be its own core plugin.<br>
<br>
Thanks for reading! What do you think?<br>
<br>
Neil<br>
<br>
<br>
[1] <a href="http://docs.openstack.org/developer/networking-calico/" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/networking-calico/</a><br>
[2] <a href="https://review.openstack.org/#/c/225384/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/225384/</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>