Difference between revisions of "Neutron/ServiceTypeFramework"
(→Notions of Service Type Framework) |
(→Workflow for a user) |
||
| Line 39: | Line 39: | ||
In order to request specific vendor (provider), user does the following steps:<br /> | In order to request specific vendor (provider), user does the following steps:<br /> | ||
1. Chooses Service Provider Name from list of available service providers.<br /> | 1. Chooses Service Provider Name from list of available service providers.<br /> | ||
| − | + | quantum service-provider-list | |
| + | | Service Type | Name | Default | | ||
| + | --------------------------------------------------------------- | ||
| + | | LOADBALANCER | Haproxy | True | | ||
| + | | LOADBALANCER | Netscaler | False | | ||
| + | 2. Creates resource with that Provider Name (effectively, the driver). LBaaS example:<br /> | ||
| + | lb-pool-create '''--provider Netscaler''' --lb-method ROUND_ROBIN ... ...<br /> | ||
| + | After the pool has been created with Netscaler provider, all subsequent commands associating other objects to this pool will go through Haproxy plugin driver.<br /> | ||
| + | In case provider is not specified, the default one is used. There could be no default provider for certain service type. In that case exception will be raised. | ||
| + | Please note that this amendment to lbaas CLI/REST API is out of scope of service type framework patch. | ||
<br /><br /> | <br /><br /> | ||
| − | |||
| − | |||
==== '''REST call dispatching''' ==== | ==== '''REST call dispatching''' ==== | ||
Revision as of 20:54, 11 July 2013
The intent of this document is to clarify and organize notions around so-called "Service Types". It describes entities and corresponding workflow.
Service Type Framework serves two main purposes:
1. Allow tenant to specify vendor (or service provider) for the requested service
2. Allow admin to offer different kinds of service insertion models of the services
Notions of Service Type Framework
1. ServiceType
type of the service: loadbalancer, firewall, vpn, etc.
This is more or less static set of string values that are currently residing in neutron/plugins/common/constants.py
These strings are used as keys in plugins dictionary when dispatching REST API calls.
2. ServiceProvider
This is a pointer to particular driver that implements some service.
Currently it has form ServiceType:Name:Driver[:default] where Driver is class identification that are loaded by neutron.
Name is human-readable form which is used to represent provider for a user.
Name should be unique for given ServiceType, but may be not unique across all providers.
A set of service type providers should be used by service plugin to load plugin drivers.
ServiceProviders are specified in configuration file in a form of string list (multiline option).
3. ProviderResourceAssociation
Entity that connects particular resource to a provider.
Association consist of unique resource_id and provider_name.
It's assumed that resource_id (uuid type) is unique in the whole database, so additional service_type field is not needed.
For the sake of API consistency, Advanced services which will leverage this framework need to have 'provider_name' attribute for their root object.
Special handling required for the case when admin is going to remove service provider from the configuration.
In that case it should undeploy all resources which were created with that provider.
Additional API call for each kind of service is required. This is subject for additional feature.
Workflow for a user
In order to request specific vendor (provider), user does the following steps:
1. Chooses Service Provider Name from list of available service providers.
quantum service-provider-list
| Service Type | Name | Default |
| LOADBALANCER | Haproxy | True | | LOADBALANCER | Netscaler | False |
2. Creates resource with that Provider Name (effectively, the driver). LBaaS example:
lb-pool-create --provider Netscaler --lb-method ROUND_ROBIN ... ...
After the pool has been created with Netscaler provider, all subsequent commands associating other objects to this pool will go through Haproxy plugin driver.
In case provider is not specified, the default one is used. There could be no default provider for certain service type. In that case exception will be raised.
Please note that this amendment to lbaas CLI/REST API is out of scope of service type framework patch.
REST call dispatching
Currently considering model is "one service plugin - multiple drivers".
For REST call dispatching the following approach will be used:
Specify ServiceProvider name only for "create root object" (create_pool for LBaaS), that will add provider resource association.
Any CRUD call for object related to the existing root object (pool) will be dispatched to the same driver as a root object.
Therefore dispatching involves fetching root object from the DB on each operation.
Example (LBaaS):
