17563a802e
Neutron Manager is loaded at the very startup of the neutron server process and with it plugins are loaded and stored for lookup purposes as their references are widely used across the entire neutron codebase. Rather than holding these references directly in NeutronManager this patch refactors the code so that these references are held by a plugin directory. This allows subprojects and other parts of the Neutron codebase to use the directory in lieu of the manager. The result is a leaner, cleaner, and more decoupled code. Usage pattern [1,2] can be translated to [3,4] respectively. [1] manager.NeutronManager.get_service_plugins()[FOO] [2] manager.NeutronManager.get_plugin() [3] directory.get_plugin(FOO) [4] directory.get_plugin() The more entangled part is in the neutron unit tests, where the use of the manager can be simplified as mocking is typically replaced by a call to the directory add_plugin() method. This is safe as each test case gets its own copy of the plugin directory. That said, unit tests that look more like API tests and that rely on the entire plugin machinery, need some tweaking to avoid stumbling into plugin loading failures. Due to the massive use of the manager, deprecation warnings are considered impractical as they cause logs to bloat out of proportion. Follow-up patches that show how to adopt the directory in neutron subprojects are tagged with topic:plugin-directory. NeutronLibImpact Partially-implements: blueprint neutron-lib Change-Id: I7331e914234c5f0b7abe836604fdd7e4067551cf
3.5 KiB
Service Extensions
Historically, Neutron supported the following advanced services:
- FWaaS (Firewall-as-a-Service): runs as part of the L3 agent.
- LBaaS (Load-Balancer-as-a-Service): implemented purely inside neutron-server, does not interact directly with agents.
- VPNaaS (VPN-as-a-Service): derives from L3 agent to add VPNaaS functionality.
Starting with the Kilo release, these services are split into separate repositories, and more extensions are being developed as well. Service plugins are a clean way of adding functionality in a cohesive manner and yet, keeping them decoupled from the guts of the framework. The aforementioned features are developed as extensions (also known as service plugins), and more capabilities are being added to Neutron following the same pattern. For those that are deemed 'orthogonal' to any network service (e.g. tags, timestamps, auto_allocate, etc), there is an informal mechanism to have these loaded automatically at server startup. If you consider adding an entry to the dictionary, please be kind and reach out to your PTL or a member of the drivers team for approval.
- http://git.openstack.org/cgit/openstack/neutron-fwaas/
- http://git.openstack.org/cgit/openstack/neutron-lbaas/
- http://git.openstack.org/cgit/openstack/neutron-vpnaas/
Calling the Core Plugin from Services
There are many cases where a service may want to create a resource managed by the core plugin (e.g. ports, networks, subnets). This can be achieved by importing the plugins directory and getting a direct reference to the core plugin:
from neutron_lib.plugins import directory
plugin = directory.get_plugin()
plugin.create_port(context, port_dict)However, there is an important caveat. Calls to the core plugin in almost every case should not be made inside of an ongoing transaction. This is because many plugins (including ML2), can be configured to make calls to a backend after creating or modifying an object. If the call is made inside of a transaction and the transaction is rolled back after the core plugin call, the backend will not be notified that the change was undone. This will lead to consistency errors between the core plugin and its configured backend(s).
ML2 has a guard against certain methods being called with an active DB transaction to help prevent developers from accidentally making this mistake. It will raise an error that says explicitly that the method should not be called within a transaction.