Public bug reported: If I use several ml2 drivers, f.e. openvswitch and cisco, one that supports vlan-transparent extension and another that doesn't, then I can't create a vlan-transparent network at all, because of check_vlan_transparency ml2 driver manager behavior.
What we should do instead of requiring that all drivers support the feature is: 1. always allow to create such networks; 2. fail on port binding attempt for a driver that doesn't support the feature; neutron-server will then try the next driver in line, and hopefully will succeed. There may also be some work on nova scheduler side to make sure that a transparent port lands on an appropriate node, but that's a separate issue to follow up. Note: once the bug is fixed, we should be able to safely revert https://review.openstack.org/#/c/359919/ that arguably was a mistake, since SR-IOV driver doesn't support the feature, and would require additional configuration on libvirt side, as described in https://serverfault.com/questions/805992/is-vlan-tagging-on-guest- allowed-in-sr-iov-on-kvm Another candidate to revert check_vlan_transparency from True to False is linuxbridge driver, that I believe also doesn't support the feature (but someone with more knowledge about the driver should check it first.) ** Affects: neutron Importance: Wishlist Status: Confirmed ** Tags: linuxbridge low-hanging-fruit rfe sriov-pci-pt ** Changed in: neutron Importance: Undecided => Wishlist ** Changed in: neutron Status: New => Confirmed ** Tags added: low-hanging-fruit ** Tags added: linuxbridge sriov-pci-pt ** Tags added: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1745192 Title: Can't create a vlan transparent network in mixed driver environment Status in neutron: Confirmed Bug description: If I use several ml2 drivers, f.e. openvswitch and cisco, one that supports vlan-transparent extension and another that doesn't, then I can't create a vlan-transparent network at all, because of check_vlan_transparency ml2 driver manager behavior. What we should do instead of requiring that all drivers support the feature is: 1. always allow to create such networks; 2. fail on port binding attempt for a driver that doesn't support the feature; neutron-server will then try the next driver in line, and hopefully will succeed. There may also be some work on nova scheduler side to make sure that a transparent port lands on an appropriate node, but that's a separate issue to follow up. Note: once the bug is fixed, we should be able to safely revert https://review.openstack.org/#/c/359919/ that arguably was a mistake, since SR-IOV driver doesn't support the feature, and would require additional configuration on libvirt side, as described in https://serverfault.com/questions/805992/is-vlan-tagging-on-guest- allowed-in-sr-iov-on-kvm Another candidate to revert check_vlan_transparency from True to False is linuxbridge driver, that I believe also doesn't support the feature (but someone with more knowledge about the driver should check it first.) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1745192/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
