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 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 quantum/plugins/common/constants.py
These strings are used as keys in plugins dictionary when dispatching REST API calls.

2. ServiceTypeProvider
This is a pointer to particular driver that implements some service.
Currently it has form ServiceType:PluginClass:DriverClass, where PluginClass and DriverClass are class paths that are loaded by quantum.
A set of service type providers should be used by service plugin to load drivers. TODO: if the model is single plugin per service type (like it is now), then it should be simplified to ServiceType:DriverClass
TODO: decide, if the set of ServiceTypeProviders needs to be dynamically configured.
Looks like there's no need for that, so it could be provided in configuration file in a form of string list.

3. ServiceGroup
Main intent of this entity is to express specific type of insertion for the group of ServiceTypeProviders.
In other word ServiceGroup is a list of ServicesTypeProviders that could be inserted in a certain way.
ServiceTypeProvider could be included in several ServiceGroups. In DB terms in means M:N relationship.

4. Insertion model
Just like ServiceType is should be a static set of string values: L2, L3, etc

Workflow for a user

In order to request specific vendor and insertion model, user does the following steps:
1. Chooses ServiceGroup from list of available groups.
2. Chooses ServiceTypeProvider from the list of chosen ServiceGroup.
3. Creates resource with that TypeProvider (effectively, the driver)

In other words, user chooses how service will be inserted and then chooses vendor that supports such insertion model.

REST API / DB changes

In order to accommodate changes in the workflow the following changes must be done to REST API and DB:
ServiceTypeProvider field should be added to the root object of corresponding resource model.
Example: in LBaaS the root object is a pool, so its model gets ServiceTypeProvider field.
REST API call that creates a pool thus gets additional parameter ServiceTypeProvider.

REST call dispatching

Currently I'm considering the model "one service plugin - multiple drivers".
There are two major options of how requests could be dispatched to corresponding driver:
1) Specify ServiceTypeProvider in each request. Cons: unnecessary parameter for the most of the calls, requires additional validation via existing DB objects
(you can't link objects with one ServiceTypeProvider with objects of another ServiceTypeProvider) Pros: ?

2) Specify ServiceTypeProvider only for "create root object" (create_pool for LBaaS),
Any CRUD call for object related to the existing root object will be dispatched to the same driver as a root object. Therefore dispatching involves fetching root object from the DB.

Pros: logical consistency, clear REST calls
Cons: db query done just for dispatching. (I doubt we can do better)

Example (LBaaS):