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

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 quantum.
Name is human-readable form which is used to represent provider for a user.
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.

Speciall treatmean needed 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.

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.
2. Creates resource with that Provider Name(effectively, the driver)

Simplified model/framework

Service Providers:

Each service-type is a unique combination of the following:

String: Uuid (generated)

String: Service type E.g. LB, FW, etc. (required)

String: Driver: Driver identification (class path or other) (required), this may or may not be visible to the tenant

String: default: default or emtpy - whether given provider is default for certain service type

Service types is a pre-defined list of strings

Service Offerings:

A Service offering is an ordered list of one or more service-providers. This accounts for the use cases for discrete services and also multi-service appliances.

String: Uuid (generated)

String: Service-offering-name (required)

List: service-providers (required)

E.g. [LB-service-type-uuid]

This is a service offering where a user can choose the specific Loadbalancer service. The plugin and driver for this Loadbalancer service are captured in the service-type identified by LB-service-type-uuid.

E.g. [LB-service-type-uuid, FW-service-type-uuid]

This is a service offering where the provider offers services which can be potentially realized on a multi-service appliance. As before, the plugin and driver each of the services are captured in their respective service-type definitions.

Resources' relationship:

1 Service-type --> [1..many] Service-offerings

1 Service-offering --> [1..many] Service-providers

Workflow:

1. User queries the list of service-offerings
2. User chooses one service-offering. The plugin/backend knows to map this to a particular provider driver class to realize this resource.

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):