>- 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 <[email protected]> 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: *[email protected]; 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 <[email protected]> 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 : [email protected] > 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 : [email protected] > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
