https://blueprints.launchpad.net/octavia/+spec/octavia-lbaas-flavors
A Provider Flavor framework provides a mechanism for providers to specify capabilities that are not currently handled via the octavia api. It allows the operators to enable capabilities that may possibly be unique to a particular provider or simply just not available at the moment within octavia. If it is a common feature it is highly encouraged to have the non-existing features implemented via the standard Octavia api. In addition operators can configure different flavors from a maintained list of provider capabilities. This framework enables providers to supply new features with speed to market and provides operators with an ease of use experience.
Flavors are used in various services for specifying service capabilities and other parameters. Having the ability to create loadbalancers with various capabilities (such as HA, throughput or ddos protection) gives users a way to better plan their LB services and get a benefit of LBaaS functions which are not a part of Octavia API. Since Octavia will become the new OpenStack LBaaS API, a new flavors API should be developed inside Octavia.
As for now, Octavia does not support multi providers. The ability to define different LBaaS providers is a mandatory feature for Octavia to be Openstack LbaaS API. Therefore, this spec depends on adding multi providers support to Octavia. Service providers will be configured via Octavia configuration file.
Its important to mention that adding flavors capability to Octavia is not actually dependent on the work for LBaaS API spinout, from Neutron to Octavia, to be completed. This capability can be added to Octavia but not actually used until the API spinout is complete and Octavia becomes the official OpenStack LBaaS API.
This spec is based on two existing specs from neutron:
Service Flavor Framework Flavor framework - Templates and meta-data
However, this is a spec for the first and basic flavors support. Following capabilities are not part of this spec:
The Provider Flavor framework enables the ability to create distinct provider flavor profiles of supported parameters. Operators will have the ability to query the provider driver interface for a list of supported parameters. Operators can view the said list by provider and create flavors by selecting one or many parameters from the list. The parameters that will be used to enable specific functionality will be json type in transit and at rest. This json payload is assigned to a provider and a flavor name. Users then have the option of selecting from any of the existing flavors and submitting the selected flavor upon the creation of the load balancer. The following flavor name examples can be, but not limited to dev, stage, prod or bronze, silver, gold. A provider can have many flavor names and a flavor name can be used by only one provider. Each provider/flavor pair is assigned a group of meta-parameters and forms a flavor profile. The flavor name or id is submitted when creating a load balancer.
The proposal is to add LBaaS service flavoring to Octavia. This will include following aspects:
A sample use case of the operator flavor workflow would be the following:
An alternative is patchset-5 within this very same spec. While the concept is the same, the design is different. Differences with patchset-5 to note is primarily with the data schemas. With patchset-5 the metadata that is passed to the load balancer has a one to one relationship with the provider. Also key/values pairs are stored in json as opposed to in normalized tables. And a list of provider supported capabilities is not maintained. That said this alternative design is an option.
DB table ‘flavor_profile’ introduced to represent the profile that is created when combining a provider with a flavor.
Field Type Null Key Default id varchar(36) NO PK generated provider_name varchar(255) NO metadata varchar(4096) NO
Note
The provider_name is the name the driver is advertised as via setuptools entry points. This will be validated when the operator uploads the flavor profile and the metadata is validated.
DB table ‘flavor’ introduced to represent flavors.
Field Type Null Key Default id varchar(36) NO PK generated name varchar(255) NO UK description varchar(255) YES NULL enabled tinyint(1) NO True flavor_profile_id varchar(36) NO FK
DB table attribute ‘load_balancer.flavor_id’ introduced to link a flavor to a load_balancer.
Field Type Null Key Default flavor_id varchar(36) YES FK1 NULL
FLAVOR(/flavors)
Attribute Name | Type | Access | Default Value | Validation/ Conversion | Description |
---|---|---|---|---|---|
id | string (UUID) | RO, admin | generated | N/A | identity |
name | string | RO, admin | ‘’ | string | human-readable name |
description | string | RO, admin | ‘’ | string | human-readable description |
enabled | bool | RO, admin | true | bool | toggle |
flavor_profile_id | string | RO, admin | string | human-readable flavor_profile_id |
FLAVOR PROFILE(/flavorprofiles)
Attribute Name | Type | Access | Default Value | Validation/ Conversion | Description |
---|---|---|---|---|---|
id | string (UUID) | admin | generated | N/A | identity |
name | string | admin | ‘’ | string | human-readable name |
provider-id | string | admin | ‘’ | string | human-readable provider-id |
metadata | string | admin | {} | json | flavor meta parameters |
The policy.json will be updated to allow all users to query the flavor listing and request details about a specific flavor entry, with the exception of flavor metadata. All other REST points for create/update/delete operations will be admin only. Additionally, the CRUD operations for Provider Profiles will be restricted to administrators.
N/A
An existing LB cannot be updated with a different flavor profile. A flavor profile can only be applied upon the creation of the LB. The flavor profile will be immutable.
There will be a minimal overhead incurred when the logical representation is scheduled onto the actual backend. Once the backend is selected, direct communications will occur via driver calls.
None
The deployer will need to craft flavor configurations that they wish to expose to their users. During migration the existing provider configurations will be converted into basic flavor types. Once migrated, the deployer will have the opportunity to modify the flavor definitions.
The expected developer impact should be minimal as the framework only impacts the initial scheduling of the logical service onto a backend. The driver implementations should remain unchanged except for the addition of the metainfo call.
This proposal allows operators to offer services beyond those directly implemented, and to do so in a way that does not increase community maintenance or burden.
The provider driver should have the following abilities:
Depends on provider support and provider drivers that support the validation interface and accept the flavor profile metadata.
Tempest Tests
Tempest testing including new API and scenario tests to validate new entities.
Functional Tests
Functional tests will need to be created to cover the API and database changes.
API Tests
The new API extensions will be tested using functional tests.
User Documentation
User documentation will need be included to describe to users how to use flavors when building their logical topology.
Operator Documentation
Operator documentation will need to be created to detail how to manage Flavors, Providers and their respective Profiles.
Developer Documentation
Provider driver implementation documentation will need to be updated to cover the new interfaces expected of provider drivers and the structure of the metadata provided to the driver.
API Reference
The API reference documentation will need to be updated for the new API extensions.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.