Difference between revisions of "Neutron/ServiceTypeFramework"

Revision as of 19:21, 10 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.

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

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