Support for Extensions in ML2¶
https://blueprints.launchpad.net/neutron/+spec/extensions-in-ml2
This blueprint defines a pluggable framework for extending core resource attributes in ML2.
Problem description¶
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.
Proposed change¶
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:
initialize: Abstract method - Perform extension driver initialization
extension_alias: Abstract property - Return supported extension aliases
process_create_network: Process extended attribute for create network
process_create_subnet: Process extended attribute for create subnet
process_create_port: Process extended attribute for create port
process_update_network: Process extended attribute for update network
process_update_subnet: Process extended attribute for update subnet
process_update_port: Process extended attribute for update port
extend_network_dict: Add extended attributes to network dictionary
extend_subnet_dict: Add extended attributes to subnet dictionary
extend_port_dict: Add extended attributes to port dictionary
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.
Alternatives¶
Link below contains discussion on this subject in icehouse summit:
https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension
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
Data model impact¶
ExtensionDriver implementations will add tables to store their extended attributes, but no ExtensionDrivers are included in the BP.
REST API impact¶
Core resource extensions will now be possible with ML2, similar to what has previously been possible with monolithic plugins.
Security impact¶
None
Notifications impact¶
None
Other end user impact¶
None
Performance Impact¶
None
Other deployer impact¶
None
Developer impact¶
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.
Implementation¶
Assignee(s)¶
- Primary assignee:
Nader Lahouti (nlahouti)
- Other contributors:
None
Work Items¶
ExtensionManager - new implementation
ExtensionDriver - new implementation
Add new method in Ml2Plugin class for adding supported extensions in mechanism driver to supported extension in the class.
Invoke extension driver’s method (e.g. process_create resource) in create/update/delete_<resource’s name> to add/update/delete attribute in persistent table.
Dependencies¶
None
Testing¶
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.
Documentation Impact¶
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.
References¶
None
