Difference between revisions of "Neutron/ServiceTypeFramework"
(→Simplified model/framework) |
|||
| Line 43: | Line 43: | ||
==== Simplified model/framework ==== | ==== Simplified model/framework ==== | ||
| − | + | ===== Service Offerings: ===== | |
Each service-offering is a unique combination of the following: | Each service-offering is a unique combination of the following: | ||
| − | + | String: Service-name/category. E.g. LB, FW, etc. (required) | |
| − | + | String: Service Quality (required) E.g. Gold, Silver, etc. default: Default | |
| − | + | String: Insertion Model (required) E.g. L3, L2, etc. | |
| − | + | String: Vendor (optional) | |
| − | + | Srting: Version (optional) | |
| − | + | String: Service Offering Provider: ServiceType:DriverClass (required), but this may or may not be visible to the tenant | |
| − | + | Service Quality is a pre-defined list of strings | |
| − | + | Service-name/categories is a pre-defined list of strings | |
| − | + | Insertion Model is a pre-defined list of strings | |
| − | Workflow: | + | ===== Workflow: ===== |
1. User queries the list of service-offerings | 1. User queries the list of service-offerings | ||
2. User chooses one service-offering and creates a resource. The plugin/backend knows to map this to a particular provider class to realize this resource. | 2. User chooses one service-offering and creates a resource. The plugin/backend knows to map this to a particular provider class to realize this resource. | ||
Revision as of 23:34, 1 May 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
Contents
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, this 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.
Simplified model/framework
Service Offerings:
Each service-offering is a unique combination of the following: String: Service-name/category. E.g. LB, FW, etc. (required) String: Service Quality (required) E.g. Gold, Silver, etc. default: Default String: Insertion Model (required) E.g. L3, L2, etc. String: Vendor (optional) Srting: Version (optional) String: Service Offering Provider: ServiceType:DriverClass (required), but this may or may not be visible to the tenant
Service Quality is a pre-defined list of strings Service-name/categories is a pre-defined list of strings Insertion Model is a pre-defined list of strings
Workflow:
1. User queries the list of service-offerings 2. User chooses one service-offering and creates a resource. The plugin/backend knows to map this to a particular provider 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):
