Open Stack

>- If you configure multiple type drivers, the first one will always be
used, subject to resource availability. E.g. with 'vlan,vxlan', you would
only start using VXLAN if all 4094 VLANs were already in us.

Not quite. It will only use a type driver automatically if it's in
'tenant_network_types'. You can have all the type drivers you want
configured in 'type_drivers' and they will only be available to admins who
manually specify the type in a network creation request.

So if you wanted to allow the creation of new networks and set them to a
specific type while leaving the old networks untouched, you would just
remove 'flat' from the 'tenant_network_types' option.


>- One issue that I suspect to be lurking is: what if the L3 plugin/agent
that you need for a port - e.g. to map a floating IP onto it - depends on
the mechanism driver that is used to bind that port?

The reference L3 plugin doesn't have a problem with this because it's not
the L3 agent's responsibility to do L2 wiring for its ports. It just
creates the ports and lets the L2 agent (or other mech driver) deal with
wiring the VIFs.


It's not clear in the original email, but if the original flat networks are
not available to the new compute nodes, you will encounter issues if you
try to boot a VM onto one of the flat networks and it gets scheduled to a
new compute node. It will result in a binding failure (assuming the vendor
ML2 driver was written correctly).

Currently, Nova scheduling doesn't account for networks that aren't
available to every compute node in the datacenter. So if the intention is
to have the flat network available to the old compute nodes, and then a
different network available to the new compute nodes, it's not really going
to work.

On Tue, Nov 1, 2016 at 5:35 AM, Neil Jerram <neil at tigera.io> wrote:

> In principle... In the fully general case I think there are issues
> lurking, so it would indeed be interesting to hear about real experience
> from people who have done this.
>
> FWIW here's what I think I understand about mixed ML2 configurations:
>
> - We're talking about 'type' drivers and 'mechanism' drivers. Type drivers
> are about how instance data is transported between compute hosts. Mechanism
> drivers are about what happens on each compute host to connect instance
> data into that ('type') system.
>
> - If you configure multiple type drivers, the first one will always be
> used, subject to resource availability. E.g. with 'vlan,vxlan', you would
> only start using VXLAN if all 4094 VLANs were already in us.
>
> - OTOH if you configure multiple mechanism drivers, they will be asked in
> turn if they want to handle connecting up (aka binding) each new Neutron
> port. So different mechanism drivers can in principle handle different
> kinds of port.
>
> - One issue that I suspect to be lurking is: what if the L3 plugin/agent
> that you need for a port - e.g. to map a floating IP onto it - depends on
> the mechanism driver that is used to bind that port?
>
> I hope those points are useful to start discussing this interesting topic
> further.
>
>     Neil
>
>
> *From: *Remo Mattei
> *Sent: *Tuesday, 1 November 2016 06:09
> *To: *Chris
> *Cc: *openstack at lists.openstack.org; Soputhi Sea
> *Subject: *Re: [Openstack] Mixed ml2 drivers in single Openstack setup
>
> You can with ml2 mix plugins. You will have to look at the options but it
> is designed for that.
>
> Sent from my iPad
>
> On Oct 31, 2016, at 9:08 PM, Chris <contact at progbau.de> wrote:
>
> Hello,
>
>
>
> We currently use the flat ml2 driver in our Openstack setup (around 500
> nodes).
>
> We now want to change to a network vendor specific ml2 driver. So the
> legacy compute nodes will use the flat network and compute nodes added in
> the future will use the network based on the new ml2 vendor plugin.
>
>
>
> Question is it possible to mix two network setups like described above? We
> don’t use regions could this be a possible solution?
>
>
>
> Any help and answer appreciated.
>
>
>
> Cheers
>
> Chris
> !DSPAM:1,581818fd210478584850555!
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
> !DSPAM:1,581818fd210478584850555!
>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20161101/cd73587d/attachment.html>