The api documentation is now published on docs.openstack.org instead of developer.openstack.org. Update all links that are changed to the new location. Note that redirects will be set up as well but let's point now to the new location. For details, see: http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007828.html Change-Id: I9f617159eddc8af532403e47c325048d92cc9ade
14 KiB
Provider Flavor Framework
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.
Problem description
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:
- Providing parameterized metainfo templates for provider profiles.
- Providing meta data for specific LBaaS object as part of its creation.
Proposed change
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:
- Adding new flavors API to Octavia API
- Adding flavors models to Octavia
- Adding flavors db tables to Octavia database
- Adding DB migration for new DB objects
- Ensuring backwards compatibility for loadbalancer objects which were created before flavors support. This is for both cases, when loadbalancer was created before multi providers support and when loadbalancer was created with certain provider.
- Adding default entries to DB tables representing the default Octavia flavor and default Octavia provider profile.
- Adding "default" flavor to devstack plugin.
A sample use case of the operator flavor workflow would be the following:
- The operator queries the provider capabilities
- The operator create flavor profile
- The flavor profile is validated with provider driver
- The flavor profile is stored in octavia db
- The end user creates lb with the flavor
- The profile is validated against driver once again, upon every lb-create
Alternatives
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.
Data model impact
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
REST API impact
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 |
Security impact
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.
Notifications impact
N/A
Other end user impact
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.
Performance Impact
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.
IPv6 impact
None
Other deployer impact
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.
Developer impact
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.
Community impact
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.
Provider driver impact
The provider driver should have the following abilities:
- Provide an interface to describe the available supported metadata options
- Provide an interface to validate the flavor metadata
- Be able to accept the flavor metadata parameters
- Exception handling for non-supported metadata
Implementation
Assignee(s)
- Evgeny Fedoruk (evgenyf)
- Carlos Puga (cpuga)
Work Items
- Implement the new models
- Implement the REST API Extension (including tests)
- Implementation migration script for existing deployments.
- Add client API support
- Add policies to the Octavia RBAC system
Dependencies
Depends on provider support and provider drivers that support the validation interface and accept the flavor profile metadata.
Testing
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.
Documentation Impact
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.
References
[1] https://docs.openstack.org/api-ref/load-balancer/v2/index.html