Neutron/ServiceTypeFramework

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 the main purpose:
Allow tenant to specify vendor (or service provider) for the requested service
Service Provider is main entity of Service Type Framework.
As an addition, another benefits are possible to add on top of service providers like service offerings, insertion modes, etc.

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.

Integration with services

In order to decouple service provider configuration from logical resource configuration the ProviderResourceAssociation is used.

Special handling required for the case when admin is going to remove service provider from the configuration or a tenant decides to change provider for existing resource. In that cases lbaas should undeploy the resource using one provider and deploy it using the other, or just undeploy all resource in case provider is going to be removed.
Additional API call for each kind of service is required. This is subject for additional service-specific feature.

Workflow for an admin

Admin usually would add service providers to the quantum.conf file.
That should make service plugins to load specified drivers and allow tenants to list service providers.
Those provider options should be specified in multiline form, one per provider in format:

<service_type>:<name>:<driver>[:default] 

Where: - service_type is a string identifying a service, one of allowed services. In Havana the next list of services will be allowed: LOADBALANCER, FIREWALL, VPN, ROUTER.
- name - user-facing representation of the provider
- driver - driver identification. That could be a classpath, or some other identification (stevedore usage is considered)
- default option. If specified, the provider becomes default for given service type.

There could be only one default provider for a given service type, driver identification should be unique across all providers.
Name and service type must also be unique.

Example of quantum.conf section:

[service_providers] 
service_provider=LOADBALANCER:reference:quantum.services.loadbalancer.plugin_drivers.haproxy.HaproxyOnHost:default
service_provider=LOADBALANCER:net_scaler:quantum.services.loadbalancer.plugin_drivers.netscaler.NetScDriver
service_provider=VPN:strong_swan:quantum.services.vpn.drivers.StrongSwan

In order to remove provider from configuration, admin should either delete all resources created with that provider, or perform a special step to undeploy all resources associated with a provider being removed. That needs to be done before neutron server is restarted.

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.

neutron 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 Netscaler plugin driver.
In case provider is not specified, the default one is used for that service type, in given example - Haproxy plugin driver. (only single default could be specified for given service type).
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):