This blueprint defines a pluggable framework for extending core resource attributes in ML2.
In the current ML2 plugin implementation, only the extensions defined in the Ml2Plugin class itself are available, and there is no way for core resources to be extended with attributes needed by specific mechanism drivers. When such extensions are needed, whether for new general purpose features that might be incorporated in future core API versions, or to better support specific networking technologies, the only current option is to implement a new monolithic plugin.
This proposal adds support to ML2 for extension drivers, which manage extended attributes on the neutron core resources implemented by the ML2 plugin: network, subnet and port.
The extension drivers are completely orthogonal to mechanism drivers. An operator configures some set of extension drivers and configures some other set of mechanism drivers. The set of extension drivers configured determines what extended attributes are present on the core resources. These extension drivers manage setting, defaulting, updating and returning persistent values for these extended attributes. The values of these extended attributes are then available to all the configured mechanism drivers and they do not vary depending on which mechanism driver is using the extended attributes. If a mechanism driver understands an extension, it can enforce its semantics. If not, it just ignores those extended attributes.
Each mechanism driver that requires a vendor-specific extension would have its own extension driver. There may also be “community” extension drivers, where several different mechanism drivers might be able to enforce the extension’s semantics.
What follows describe changes in ML2 to define extension drivers and provide support for extensions in ML2 mechanism drivers:
1. Introduce ExtensionDriver API and ExtensionManager (similar to MechanismDriver and MechanismManager).
2. Define new configuration parameter which contains list of extension drivers to load (i.e. extension_drivers).
3. ExtensionDriver - Abstract class that defines the following interfaces for ML2 extension drivers:
4. ExtensionManager - Manages loading and initializing extension drivers similarly to the existing TypeManager and MechanismManager classes. Provides methods that dispatch to the ordered list of registered extension drivers for each of the process_create_<resource>, process_update_<resource>, and extend_<resource>_dict abstract operations defined on ExtensionDriver.
5. Ml2Plugin will initialize the ExtensionManager at startup, which will load and initialize the configured ExtensionDrivers.
6. Change Ml2Plugin’s supported_extension_aliases abstract property to include the extension_alias property of each registered ExtensionDriver.
7. In resource’s create and update (i.e. network, port, subnet in Ml2Plugin) before calling the pre/post_commit, process_create/update in extension driver should be called to validate and persist any extended resource’s attributes defined by driver. Extended attribute must also be returned.
8. In each case where dictionaries are built by Ml2Plugin for network, subnet, and port resources, the ExtensionManager’s extend_<resource>_dict function will be called so that the registered ExtensionDrivers can add their extended attributes.
Link below contains discussion on this subject in icehouse summit:
Also, alternative of implementing extensions directly in mechanism drivers was considered, but was rejected for various reasons, including no way to return extended attributes from get operations
ExtensionDriver implementations will add tables to store their extended attributes, but no ExtensionDrivers are included in the BP.
Core resource extensions will now be possible with ML2, similar to what has previously been possible with monolithic plugins.
If a mechanism driver needs to add extended attribute to a resource, it needs to create an extension driver (based on ExtensionDriver API) and add the name to the setup.cfg and ml2_conf.ini. The name of extension and path to the extension should be added in the extension driver.
The regular test for plugin still applies here. But new unit tests will be added with a test ExtensionDriver that verifies that extended attributes are properly processed in create and update operations, returned from create, update, and get operations, and available from within MechanismDriver methods.
The ExtensionDriver API will include docstrings describing the new API, so generated documentation will cover it. Will need to update deployment docs for the new config variable. Will mainly be covered by vendor docs whose mechanism drivers require extension drivers.