[RFE][ML2] Enforce extension semantics

The ML2 core plugin implements certain API extensions through mix-in classes, and allows additional API extensions to be implemented using extension drivers. All of these extensions are then considered to be "supported" by the plugin. But supporting an extension's API does not, in itself, guarantee that the semantics a user requests using that API will be supported and enforced by the applicable mechanism drivers.

One potential solution might be to require all mechanism drivers to provide a property listing the extension aliases they support, and then for the plugin to only claim to support those extensions supported by all configured mechanism drivers. But this solution does not address important use cases involving multiple mechanism drivers. For example, an SR-IOV mechanism driver may not be able to enforce security groups itself, so shouldn't claim to support that extension. But then security groups wouldn't be available for non-SR-IOV ports either. This might be resolved by the SR-IOV mechanism driver claiming to support security groups, and refusing to bind when the list of security groups on the port is not empty. But then what if a ToR switch mechanism driver could support security groups? The SR-IOV mechanism driver should not have know whether a specific ToR mechanism driver is part of the binding and what its capabilities are. Furthermore, the ToR mechanism driver might only be able to enforce certain kinds of security groups, so whether an SR-IOV binding is valid might depend on the specific security group rules applied to the port. And, unlike security groups or other mixed-in extensions, those supported via configured extension drivers might not even be meaningful to some of the configured mechanism drivers. Requiring all mechanism drivers to understand and support all extensions is clearly not a viable solution.

We therefore propose a more dynamic solution to ensure that the semantics requested via extension APIs are enforced. This solution prevents port bindings from being created unless the semantics expressed through all configured extension APIs can be provided by that port binding. This will result in invalid port bindings being passed over until a valid one is found, or potentially in a failure to bind. It will not address the harder problem of making Nova's scheduling of instances take extension semantics into account, but will work in conjunction with using Nova host aggregates to influence scheduling.

The proposed solution adds a method each to the ML2 ExtensionDriver and MechanismDriver APIs. It does not require any change in Neutron APIs, existing extension APIs, or any database schema. The driver base classes will implement default versions of these methods, so existing drivers will not be broken. After a potential port binding has been determined, within the transaction that will commit the result, ML2 will perform a new extension semantics validation phase.

For each registered extension driver, the ExtensionDriver.validation_mode method will first be called, which will return a "none", "one", or "all" value indicating what type of mechanism driver validation is needed for that extension. This method can examine the attribute values if needed to determine the mode. In the example above, a security group extension driver would examine the port's security_groups value and return "none" if there are no security groups on the port, and "one" otherwise.

ML2's extension semantics validation then proceeds based on the validation mode determined for that extension. If the validation mode is "none", no further validation is needed for that extension. Otherwise, the potential binding is validated by calling the MechanismDriver.validate_extension method on the mechanism drivers making up the potential binding. For an enforcement mode of "one", validation proceeds from the bottom to top mechanism drivers until one indicates it can enforce that extension's semantics by returning True. For "all", each mechanism driver in the potential binding must indicate it can it can enforce the semantics. In the example above, the openvswitch or linuxbridge mechanism driver would always return True to indicate it can enforce any security group semantics, an SR-IOV mechanism driver would always return False to indicate it cannot enforce any security group semantics, and a ToR switch mechanism driver might have to examine the security group rules to determine whether it can enforce them for that port.

If validation succeeds, the binding is committed. If not, the next potential binding is tried. Note that when a mechanism driver claims it can enforce the semantics for an extension based on the attribute values, and then the binding is committed, that driver takes responsibility to reject future updates that change those attributes to values that it could no longer enforce.

Followup RFEs will be needed to implement enforcement of specific extensions, such as security groups and QoS. These may require adding extension drivers for extensions that are currently mixed-into the ML2 core plugin.