Can't create a vlan transparent network in mixed driver environment

[Ihar Hrachyshka]

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.)

[Ihar Hrachyshka (ihar-hrachyshka)]

This is arguably a proposal to change behavior somewhat, so I marked it with 'rfe' tag for drivers team to chime in before we recommend someone to pursue it.

[YAMAMOTO Takashi (yamamoto)]

this sounds like a variation of the old topic.
that is, how to handle the different set of features among ml2 drivers. (sg, qos, ...)
unfortunately we don't have a clear answer yet as far as i know.
port-binding time failure might not be very user-friendly. i don't think of any better alternative though.

[Miguel Lavalle (minsel)]

Approved. There was some discussion in the drivers meeting about improving the error reporting to the users when drivers fail the binding, but it was considered tangential to the RFE. Worth exploring anyhow