Difference between revisions of "Neutron/FlavorFramework"
(→Rationale) |
(→API) |
||
(15 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=== Rationale=== | === Rationale=== | ||
− | The purpose of Flavor Framework is to provide | + | The purpose of a Flavor Framework is to provide an API that allows the user to choose the type of service by a set of advertised service capabilities rather than by a provider type or named vendor. |
+ | |||
User-facing part of Flavor is a group of service parameters. | 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) | The proposed Flavor notion is similar to what nova has with the difference that Flavor parameters are dynamic (e.g. not fixed or hardcoded) | ||
<br/> | <br/> | ||
− | From implementation point of view, the flavor is an object that is used to dispatch REST API calls after they pass persistence layer | + | 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.<br/> | |
− | Binding process is known as scheduling | + | Binding process is known as scheduling; it maps flavor chosen for particular resource (at creation) to a provider and then to a particular backend.<br/> |
=== Object model === | === Object model === | ||
Line 16: | Line 17: | ||
* Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc) | * Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc) | ||
* Name - name of the flavor | * Name - name of the flavor | ||
− | * | + | * Tags - string containing a list of (key, value) pairs (tags) that define capabilities. |
− | |||
− | + | Each driver, including the default one of each service should provide at least their default capabilities object.<br/> | |
− | |||
− | |||
− | Each driver, including the default one | ||
=== 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 | | ||
+ | | Tags | [Tags] | | ||
+ | --------------------------------------------------------- | ||
+ | <br/> | ||
+ | create/update/delete commands are available for administrator only. | ||
+ | <br/> | ||
+ | <br/> | ||
+ | Service resources that represent service instance (vpn connection, firewall, pool or vip, router) get public attribute 'flavor' that can be specified upon creation. | ||
+ | |||
+ | ===Scheduling=== | ||
+ | Scheduling is a process of choosing provider and a backend for the resource. | ||
+ | There is a few questions to discuss: | ||
+ | * Should scheduling be a single-step process? E.g. both provider and backend should be result of scheduling? | ||
+ | It seems so: if we defer binding resource to a backend, we may end up with successful scheduling to a provider, but unsuccessful scheduling to a backend, | ||
+ | so resource will be in ERROR state and will need to be rescheduled to a different flavor. <br/> | ||
+ | It's better to fail early. | ||
+ | * Should scheduling choose from a list of (provider, backend), or it is first choosing provider and then provider chooses backend? | ||
+ | It seems that the second approach is simpler because it doesn't put design restrictions on scheduling to backends.<br/> | ||
+ | For example, a backend could be agent or device, and we will not need to design data structure for them to use in a single scheduler. | ||
+ | <br/> | ||
+ | |||
=== Workflow === | === Workflow === | ||
+ | TDB<br/> | ||
+ | |||
+ | # Flavor Framework should allow simple providerless resource creation<br/> | ||
+ | In case flavor is not specified, new resource is scheduled to a default provider for certain service.<br/> | ||
+ | |||
=== Driver requirements === | === Driver requirements === | ||
=== Migration === | === Migration === | ||
+ | Migration from existing configuration is expected to be straightforward.<br/> | ||
+ | If service supports Provider Framework, it's service instance object has 'provider' attribute that helps REST API calls dispatching to a proper driver.<br/> | ||
+ | From the Flavor Framework perspective, such resources appear to be already scheduled with unknown flavor.<br/> | ||
+ | That should not affect their operability and admin status.<br/> | ||
+ | <br/> | ||
+ | From REST API Perspective 'provider' attribute becomes visible for admins only (and it can't be provided for create/update), while flavor attribute is available for create/update operations for regular user. | ||
+ | |||
=== Possible issues === | === Possible issues === |
Latest revision as of 05:19, 27 March 2014
Contents
Rationale
The purpose of a Flavor Framework is to provide an API that allows the user to choose the type of service by a set of advertised service capabilities rather than by a provider type or named 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 and then to a particular backend.
Object model
Flavor Framework defines the following objects:
Flavor
Attributes:
* Service Type - string identifier (LOADBALANCER, FWAAS, L3, VPN, etc) * Name - name of the flavor * Tags - string containing a list of (key, value) pairs (tags) that define 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 | | Tags | [Tags] | ---------------------------------------------------------
create/update/delete commands are available for administrator only.
Service resources that represent service instance (vpn connection, firewall, pool or vip, router) get public attribute 'flavor' that can be specified upon creation.
Scheduling
Scheduling is a process of choosing provider and a backend for the resource. There is a few questions to discuss:
- Should scheduling be a single-step process? E.g. both provider and backend should be result of scheduling?
It seems so: if we defer binding resource to a backend, we may end up with successful scheduling to a provider, but unsuccessful scheduling to a backend,
so resource will be in ERROR state and will need to be rescheduled to a different flavor.
It's better to fail early.
- Should scheduling choose from a list of (provider, backend), or it is first choosing provider and then provider chooses backend?
It seems that the second approach is simpler because it doesn't put design restrictions on scheduling to backends.
For example, a backend could be agent or device, and we will not need to design data structure for them to use in a single scheduler.
Workflow
TDB
- Flavor Framework should allow simple providerless resource creation
In case flavor is not specified, new resource is scheduled to a default provider for certain service.
Driver requirements
Migration
Migration from existing configuration is expected to be straightforward.
If service supports Provider Framework, it's service instance object has 'provider' attribute that helps REST API calls dispatching to a proper driver.
From the Flavor Framework perspective, such resources appear to be already scheduled with unknown flavor.
That should not affect their operability and admin status.
From REST API Perspective 'provider' attribute becomes visible for admins only (and it can't be provided for create/update), while flavor attribute is available for create/update operations for regular user.