- 1 Advanced Services Framework
- 1.1 Scope
- 1.2 Rationale
- 1.3 Implementation Overview
- 1.4 Data Model Changes
- 1.5 Configuration variables
- 1.6 API
- 1.7 Changes required in Quantum
- 1.8 Plugin Interface
- 1.9 Dependencies
- 1.10 CLI Requirements
Advanced Services Framework
The document describes how advanced services could be implemented within current quantum code architecture. It doesn’t define architecture of feature implementation itself.
Advanced services framework should allow implementation of additional services to be independent and decoupled from core plugins. Installing advanced services should not require core db model change or core plugin code change.
- Quantum should be able to load several Adv Svc Plugins
- Quantum should be able to load several implementations of the same Adv Svc Type
- Quantum Adv Svc Plugin and Core Plugin should be independent
- Each Adv Svc Plugin may implement different set of main features/resources but should implement single interface allowing quantum to load proper extensions and route API calls to the proper Adv Svc Plugin
- Adv Svc is uniquely defined by (type,name) which could be used in API urls as a common prefix. E.g. for loadbalancer implementation lb_impl the common prefix could look like: /v2.0/svc/loadbalancer/lb_impl/...
- Advanced Services should not depend on deployment method, routed/non-routed
- Would be good if Advanced Services are distributed as packages
Changes in configuration
- configuration should specify a list of adv services plugins to load.
Data Model Changes
Adv Svc Framework doesn’t imply change in core data model. Instead, each service implementation may have it’s own data model
quantum.conf: service_plugins=quantum.plugins.advsvc.lbaas_plugin.lbaas_plugin_class, quantum.plugins.advsvc.dummy.dummy_impl_class
Framework doesn’t specify public API, each Advanced Service may introduce it’s own API.
In case of several implementations of one service it may be needed to define one public API for the service type which are implemented differently by the plugins.
Advanced Service Plugin Interface (internal)
- get_type() - returns service type (string)
- get_name() - returns service name (string)
- supported_extension_aliases - array of strings. to be used with PluginAwareExtensionManager
- TBD: model-related interface
Changes required in Quantum
- PluginAwareExtensionManager should support not only a core plugin, but a list of adv svc plugins
- For each of loaded Adv Svc plugins PluginAwareExtensionManager should prepend corresponding extension API urls with /v2.0/service_type/service_name/ prefix.
- Extension framework may need to process same extension more than once to be able to route the same extension call to different Adv Svc plugin.
- No new requirements for the core plugin interfaces.
- No specific requirements for Adv Svc plugin: it should match corresponding extension API.
Each Adv Svc plugin may have it’s own dependencies.
CLI client may need to support additional command set for each of specific Advanced Service via plugins of some kind (?)