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

Bug #1745192 reported by Ihar Hrachyshka
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Pawel Rusak

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

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

Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

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.

Changed in neutron:
importance: Undecided → Wishlist
status: New → Confirmed
tags: added: low-hanging-fruit
tags: added: linuxbridge sriov-pci-pt
tags: added: rfe
tags: added: rfe-confirmed
Miguel Lavalle (minsel)
tags: added: rfe-triaged
removed: rfe-confirmed
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

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.

Revision history for this message
Miguel Lavalle (minsel) wrote :

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

tags: added: rfe-approved
removed: rfe-triaged
Pawel Rusak (rusakp)
Changed in neutron:
assignee: nobody → Pawel Rusak (rusakp)
tags: removed: low-hanging-fruit
tags: removed: rfe
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers