[RFE] ml2 supported extensions list is inaccurate

Perhaps we need to change ML2 so that each mech driver exposes extensions, and ML2 exposes the sum of said extensions, instead of exposing a hard coded list that is oblivious to the mech drivers currently loaded.

Since ML2 supports heterogeneous deployments, my view is that the supported extension list should reflect the extensions supported by the API, and that ML2s port binding process needs to take into account the semantics expressed through those extension APIs in deciding what combinations of mechanism drivers are allowed to bind a particular port. If the semantics requested through the API extensions cannot be provided for a port, it should fail to bind, hopefully with enough useful error information so that the user can understand how to resolve/avoid the issue.

An example would be the security groups extension, in a deployment that included a mix of KVM compute nodes with the regular OVS L2 agent, KVM compute nodes with SR-IOV capabilities, and bare metal compute nodes. All expressible SG semantics can be enforced by the OVS L2 agent, but in the other cases, SGs either cannot be enforced at all, or the ToR switch mechanism driver may be capable of enforcing a subset of the SG semantics via switch ACLs. In this scenario, port binding should fail if the port is being bound for SR-IOV or for bare metal, and the ToR mechanism driver cannot enforce the current SG rule sets applied to the port. Furthermore, changing the SGs associated with an already bound port should fail if the port is successfully bound for SR-IOV or bare metal and the new SG rule sets could not be enforced by the ToR mechanism driver. Other extensions such as QoS would have similar port binding requirements to ensure their semantics are enforced.

Accomplishing this will require interaction between the ML2 extension drivers and the set of mechanism drivers in a potential binding to decide if the required extension semantics can or cannot be enforced/provided by that binding. It will also require ML2 mechanism drivers involved in a binding to be able to reject changes made via the extension APIs.

But no single MD should determine whether or not any particular extension should be included in the ML2 plugin's supported extensions list.

Orthogonally to the enforcement of extension value semantics described in my comment above, there is something we can do to give the admin more control over what extensions ML2 advertises as supported. The idea would be to package more of the extensions that are currently mixed-into the ML2 plugin class as extension drivers instead. That way, a deployment could leave out extensions that are not applicable, and they would not appear in the extension list.

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

it's still valid.

It is indeed, thanks for putting it back to the confirmed list. Are we ever gonna fix it? :)

bumping to RFE to see if a discussion amongst drivers is gonna make a difference.

We are planning to pick this Wishlist Bug for our analysis and contribution.
This is to intimate our participation on this Bugs analysis and Contributions.

Let me know if there are any duplication of work items for this particular wishlist bug.

Bug 1583096 is somewhat related.

I think armax meant https://bugs.launchpad.net/neutron/+bug/1673142

Would like to see 1673142 solve the issues here. Address scopes might need to be moved to the l3 plugin entirely.

https://review.openstack.org/#/c/253853 may be of relevance here.