Advanced Services Framework

Scope

The document describes how advanced services could be implemented within current quantum code architecture. It doesn’t define architecture of feature implementation itself.

Rationale

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.

Implementation Overview

General Considerations

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.

Schematic representation

{{http://wiki.openstack.org/Quantum/ServiceIntegration?action=AttachFile&do=get&target=qschema.jpg}}

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

Configuration variables

quantum.conf: service_plugins=quantum.plugins.advsvc.lbaas_plugin.lbaas_plugin_class, quantum.plugins.advsvc.dummy.dummy_impl_class

API

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.

Plugin Interface

No new requirements for the core plugin interfaces.
No specific requirements for Adv Svc plugin: it should match corresponding extension API.

Dependencies

Each Adv Svc plugin may have it’s own dependencies.

CLI Requirements

CLI client may need to support additional command set for each of specific Advanced Service via plugins of some kind (?)

Neutron/ServiceIntegration

Contents