Extensible port attribute for plugin to provide details to VIF driver

Currently, the binding:vif_type and binding:capabilities attributes carry information from the neutron core plugin (the bound MechanismDriver in the case of ML2) to nova's VIF driver (or potentially to interface drivers for agents or appliances). The fix proposed for bug 1112912 replaces binding:capabilities with binding:vif_security, which is a dictionary containing several security-specific key/value pairs to be interpreted by nova's GenericVIFDriver. Support for SR-IOV PCI passthrough requires a similar flow of information from the plugin/MechanismDriver to the VIF driver, and future features may require passing other information to the VIF driver as well. To address all these requirements without a proliferation of new attributes, a single new binding:vif_details port attribute will be added to the portbindings extension that can carry an extensible set of key/value pairs from the plugin/MechanismDriver to the VIF driver or interface driver. The set of key/value pairs in binding:vif_details that are meaningful to nova's GenericVIFDriver will depend on the value of binding:vif_type.

The fix for bug 1112912 should be able to use this binding:vif_details attribute for its key/value pairs rather than introduce a new similar binding:vif_security attribute. That fix can remove support for the binding:capabilities attribute as is currently proposed.

The binding:vif_details attribute will be read-only from the REST API. Core plugins that support it will include the value in the dictionaries returned from create port, update port, and get port(s) operations, subject to access control. The default access control policy will be admin_only, as for binding:vif_type and binding:capabilities.

The implementation of binding:vif_details in the ML2 plugin will return a value obtained from the bound MechanismDriver when the port is bound, and will return a value of None when there is no binding. The current value of the binding:vif_details attribute will be available to all MechanismDriver port methods via PortContext.current.

Two approaches are being considered for handling vif_details in the ML2 MechanismDriver API. One approach is for the MechanismDriver that binds the port to pass it as a parameter to PortContext.set_binding() and for the ML2 plugin to persist it in its ml2_port_bindings DB table as is currently done for binding:vif_type and binding:capabilities. The other approach is for the plugin to call a new extend_bound_port() operation on the bound MechanismDriver each time a port dictionary is being built, and for extend_bound_port() to add the vif_security attribute to PortContext.current. The approach will be chosen during implementation, and if the latter approach is chosen, it will be applied to the binding:vif_type (and binding:capabilities if it remains) attributes as well.

Note that this blueprint can either be implemented independently or as part of the fix for bug 1112912. If binding:vif_details is implemented independently, initially for the ML2 plugin, then the bug fix will cover replacing binding:capabilities with binding:vif_details in the other plugins and removing support for binding:capabilities from ML2.

It may also be worth considering simply keeping the existing binding:capabilities attribute, which is already defined as a dictionary, and clarifying that the set of key/value pairs it can contain is extensible. In that case, this blueprint would cover changing ML2's handling of binding:capabilities so that the bound MechanismDriver can supply arbitrary key/value pairs, and the fix for bug 1112912 would cover replacing the current 'port_filter' key/value pair with those needed to fix VIF security.