Comment 5 for bug 1518087

I just looked at the drivers meeting log, and feel this decision has been made based on an incomplete understanding of ML2. I think its useful to consider 3 different use cases for ML2 deployment:

1) The simplest use case involves just one mechanism driver, as with the typical OVS or LB reference implementations. In this case, the single configured MD is responsible for enforcing/providing SGs, QoS, and any other extensions that apply. If the single MD can't enforce some extension, it can be looked at as a mis-configuration that never should have occurred.

2) A slightly more complex use case adds another MD for a ToR switch. Here, the combination of two (or possibly more) MDs is responsible for enforcing/providing all needed extensions. The ToR MD might simply enable VLANs for switch ports, or might dynamically allocate VLANs (or some other type of segments) using HPB. But typically extensions would be enforced/provided by the host-level MD. Again, if the (uniform) combination of MDs can't provide the right semantics, its a mis-configuration.

3) Where it gets interesting is when the deployment is no longer uniform, and different MDs or combinations of MDs might be involved in binding different ports. This could be a multi-vendor deployment with different types of ToR switches. Or it might involve a mix of different types of compute nodes (different hypervisors, vSwitches, baremetal, containers, ...). In these cases, how or whether each extension can be enforced/provided might vary drastically among different possible port bindings. For example, normal nova nodes with OVS or LB would be able to enforce SGs using iptables, while baremetal nodes in the same deployment might not be able to enforce SGs at all. Or maybe a ToR switch to which a baremetal node is connected is able to enforce the SGs (or at least a subset of SG rules).

I can see how an SG-specific (or more general) mechanism for ensuring that at least one MD is responsible for enforcing/providing each applicable extension in each port binding seems like overkill for cases 1 and 2. But to properly support case 3, something like this seems essential.

Its not simply a matter of returning an error to the user when the applicable extensions for a port cannot be enforced/provided, but also of letting ML2's port binding reject the inappropriate potential bindings (combinations of MDs) and move on to find another binding that will work.

I can understand if this needs more discussion before deciding to implement it (especially a general mechanism) in mitaka, but I don't think it should be summarily dismissed by setting to "won't fix".