https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework
This specification details a framework to enable Operators to configure and Users to select from different abstract representations of a service implementation in Neutron. The representation decouples the logical configuration from its instantiation allowing support of multiple possible implementations to coexist. Decoupling also enables Operators to create user options according to deployment needs. This proposal does not require any significant driver integration to implement.
The service provider framework allows services to be backed by multiple drivers; however there are several limitations with the current approach. The limitations include:
The proposed solution is to introduce two new logical entities exposed via the REST API to decouple the logical configuration from the backend implementation. The first entity is called Flavor and is an operator curated description of the backend implementation. Flavor’s attributes include id, name, extension list, service, service profiles, selection algorithm and enabled flag. The extension list is used to enable additional REST API functionality for logical configurations associated with the flavor. An example would be enabling TLS and/or L7 for load balancing. Users are allowed to query and view the public attributes of the flavor. The selection algorithm determines the service profile and the driver schedules the instance to the backend.
The second entity is Service Profile which has attributes of id, name, entry point, driver initialization metadata and enabled flag. The Service Profile enables an operator to associate the driver entrypoint with metadata necessary to initialize the driver. A benefit of metadata is that the same driver may back different flavors definitions. Multiple service profiles may be associated with the same flavor to enable multi-vendor/multi-driver environments.
This extension will introduce a new RPC method in the core server. The method will handle scheduling the logical instance onto the backend. Scheduling will involve binding the logical configuration to a backend with capacity. Once scheduled, the plugin will directly dispatch calls to the driver. The scheduling method implementation will be intentionally kept simple to enable this work to be completed within the cycle. Future work may include a more advanced scheduler by incorporating Gantt (a project to make the Nova scheduler available to other OpenStack components) and/or developing a method for backends to express load/capacity. Auto-rescheduling and instance health monitoring are outside the scope of this change and are the responsibility of the driver. Operators also retain control over cost and scheduling via their selection of the service profiles.
While flavors and service profiles could be stored in configuration files, this spec proposes to store the entities in the database. Storage in a relational database ensures atomicity and consistency across neutron servers and workers by avoiding configuration deployment races. Additionally, an operator may add/update/delete flavors without system downtime. (Note: Flavor and service profiles may not be changed or removed if in use).
Future work includes tenant specific flavors and advanced scheduling (integration into Gantt project and/or filters).
This proposal enables vendor differentiation since flavor definitions may include vendor API extensions that the operator may choose to enable.
Two new logical models will be added to the database.
The existing provider attribute will be changed to service_profile_id and used to associate the root of the service’s logical model with the profile.
The new logical models will be exposed via the API. The logical model CRUD operations will only be exposed to administrators with the exception of read operations on Flavor. All users will be able to query and get the details on a single flavor with a limited set of attributes (id, name, description, service and service extensions). Additionally, one administrative action will be added to each service: reschedule(id). This action will enable an operator to force the system to reschedule the backend for a logical service.
FLAVORS (/flavors):
Attribute Name | Type | Access | Default Value | Validation/ Conversion | Description |
---|---|---|---|---|---|
id | string (UUID) | RO, all RW, admin | generated | N/A | identity |
name | string | RO, all RW, admin | ‘’ | string | human-readable name |
description | string | RO, all RW, admin | ‘’ | string | human-readable description |
service | string | RO, all RW, admin | ‘’ | string | token mapping flavor to svc |
service_profiles | list | RO, all RW, admin | [] | json list | driver mapping with weight |
supported_extensions | string | RO, all RW, admin | ‘’ | string | available api extensions |
selection_algorithm | enum | RO, all RW, admin | random | see model | how to select profile |
enabled | bool | RO, all RW, admin | true | bool | toggle |
SERVICE_PROFILES (/service_profiles):
Attribute Name | Type | Access | Default Value | Validation/ Conversion | Description |
---|---|---|---|---|---|
id | string (UUID) | RO, all RW, admin | generated | N/A | identity |
description | string | RO, all RW, admin | ‘’ | string | human-readable description |
driver | string | RO, all RW, admin | ‘’ | string | python module path to driver |
metainfo | string | RO, all RW, admin | ‘’ | json string | meta data |
enabled | bool | RO, all RW, admin | true | bool | toggle |
The policy.json will be updated to allow all users to query the flavor listing and requst details about a specific flavor entry. All other REST points for create/update/delete operations will admin only. Additionally, the CRUD operations for Service Profiles will be restricted to administrators.
The content of current notifications will change minimally to add a new flavor attribute. This attribute will be used for applications such as billing and can be captured by Ceilometer. The provider attribute will be retained for operators that wish to track the user’s flavor and backend.
N/A
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 capacity 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.
Keep doing nothing.
Doug Wiegley (original spec and code by markmcclain and enikanorov)
No dependencies on other work. It should be noted that many other items depend on flavors.
Tempest testing including new API and scenario tests to validate new entities.
Functional testing is being excluded from this change because this API does not directly alter the data path. (Elements that alter the datapath are covered by other functional test).
The new API will be tested.
User documentation will need be included to describe to users how to use flavors when building their logical topology. Operator documentation will need to be created to detail how to manage Flavors and Service Profiles.
Additionally, documentation of the new REST endpoints will need to be included in the Networking API description.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.