Open Stack

On 22 January 2016 at 10:35, Neil Jerram <Neil.Jerram at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160124/558387e0/attachment.html>