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?
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
