Jump to: navigation, search

Difference between revisions of "Neutron/FlavorFramework"

(Rationale)
(API)
Line 25: Line 25:
  
 
=== API ===
 
=== API ===
 +
Public API consist of flavors resource, which user can list or show: <br/>
 +
neutron flavor-list
 +
--------------------------------------------------------------------------------
 +
|    ID    |  Service Type              |    Name            | Description  |
 +
--------------------------------------------------------------------------------
 +
|  UUID | LOADBALANCER        |    Reference    |  Basic LB    |
 +
|  UUID | LOADBALANCER        |    Hi-perf          | expensive    |
 +
--------------------------------------------------------------------------------
 +
 +
neutron flavor-show UUID
 +
--------------------------------------------------------
 +
|  ID                        |    UUID                        |
 +
| Service Type      |      VPN                        |
 +
| Name                  |    ipsec                        |
 +
| Description          |      reference                |
 +
| Parameters          |    <Parameters>          |
 +
--------------------------------------------------------
 +
 
=== Workflow ===
 
=== Workflow ===
 
=== Driver requirements ===
 
=== Driver requirements ===
 
=== Migration ===
 
=== Migration ===
 
=== Possible issues ===
 
=== Possible issues ===

Revision as of 13:14, 26 February 2014

Rationale

The purpose of Flavor Framework is to provide more abstract API that allows user to chose service by it's capabilities rather then by provider/vendor.
User-facing part of Flavor is a group of service parameters. The proposed Flavor notion is similar to what nova has with the difference that Flavor parameters are dynamic (e.g. not fixed or hardcoded)


From implementation point of view, the flavor is an object that is used to bind logical service instance (for whatever service) to a concrete provider that is later to be used to dispatch REST API calls after they pass persistence layer.
Binding process is known as scheduling; it maps flavor chosen for particular resource (at creation) to a provider.

Object model

Flavor Framework defines the following objects:

Flavor

Attributes:

* Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc)
* Name - name of the flavor
* Parameters - list of (key, value) pairs that define capabilities. Value can be range or integer, or string, or json.
* FlavorType - public or internal

The last attribute - FlavorType defines whether the flavor is publicly available or is internal.
Internal flavors are provided by vendor drivers configured for corresponding services.
Internal flavors are similar to 'provider' notion, plus may have additional parameters that describe service capabilities.
Each driver, including the default one of each service should provide at least their default capabilities object.

API

Public API consist of flavors resource, which user can list or show:

neutron flavor-list
--------------------------------------------------------------------------------
|    ID    |   Service Type              |    Name            | Description  |
--------------------------------------------------------------------------------
|  UUID | LOADBALANCER         |    Reference    |  Basic LB     |
|  UUID | LOADBALANCER         |    Hi-perf          | expensive    |
--------------------------------------------------------------------------------

neutron flavor-show UUID


| ID | UUID | | Service Type | VPN | | Name | ipsec | | Description | reference | | Parameters | <Parameters> |


Workflow

Driver requirements

Migration

Possible issues