Bug 1059966

Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile.

Description:

The binding:profile port attribute defined in the portbindings API extension will be implemented in the ML2 plugin. This attribute is a dictionary that can be used (with admin credentials) to supply information influencing the binding of the port. This functionality is needed for SR-IOV PCI passthrough, and may also be needed as other monolithic plugins that use binding:profile are reimplemented as ML2 MechanismDrivers. The binding:profile attribute will be used for input to the plugin (and its drivers) only, not for output of information originating from within the plugin. A separate portbindings extension dictionary attribute will be proposed for outputting binding-specific information.

The ML2 plugin will store the binding:profile attribute in its ml2_port_bindings DB table. Values can be passed in via create and update port operations, subject to access control. Values will be returned in output dictionaries from create, update, and get port(s) operations, also subject to access control. In updates, the new value will completely replace the previous value, with no attempt to merge new and existing dictionary items.

Since the ML2 plugin can support a variety of MechanismDrivers with varying needs for content in the binding:profile attribute, the plugin will accept, store, and return arbitrary key/value pairs within the dictionary. This is unlike other plugins that only handle values for specific keys. No validation of items within binding:profile by drivers is planned, but could be added if needed. Drivers are expected to ignore binding:profile items they do not recognize.

The current value of the binding:profile attribute will be available to all MechanismDriver port methods via PortContext.current. In update methods, the previous value will also be available via PortContext.original.

Because the contents of binding:profile are expected to influence the outcome of ML2's port binding process (assuming MechanismDrivers that use it are configured), the semantics of updating binding:profile while the port has an existing binding need to be addressed. One possibility is to reject updates to a bound port. Another is to unbind and attempt to rebind the port. A third possibility is to ask the bound MechanismDriver whether the change invalidates the binding. This will be resolved during implementation.

Specification URL (additional information):

None