Nova Stable REST API¶

Nova v2 API + Extensions¶

Nova use to have v2 API. In v2 API, there was a concept called 'extension'. An operator can use it to enable/disable part of Nova REST API based on requirements. An end user may query the '/extensions' API to discover what API functionality is supported by the Nova deployment.

Unfortunately, because v2 API extensions could be enabled or disabled from one deployment to another -- as well as custom API extensions added to one deployment and not another -- it was impossible for an end user to know what the OpenStack Compute API actually included. No two OpenStack deployments were consistent, which made cloud interoperability impossible.

In Newton release, extensions magic was deprecated and marked for removal.

In Newton release, v2 API code base has been removed and /v2 endpoints were directed to v2.1 code base.

v2 API compatibility mode based on v2.1 API¶

v2.1 API is exactly same as v2 API except strong input validation with no additional request parameter allowed and Microversion feature. Since Newton, '/v2' endpoint also started using v2.1 API implementation. But to keep the backward compatibility of v2 API, '/v2' endpoint should not return error on additional request parameter or any new headers for Microversion. v2 API must be same as it has been since starting.

To achieve that behavior legacy v2 compatibility mode has been introduced. v2 compatibility mode is based on v2.1 implementation with below difference:

• Skip additionalProperties checks in request body
• Ignore Microversion headers in request
• No Microversion headers in response

Nova v2.1 API + Microversion¶

In Kilo release, nova v2.1 API has been released. v2.1 API is supposed to be backward compatible with v2 API with strong input validation using JSON Schema.

v2.1 API comes up with microversion concept which is a way to version the API changes. Each new feature or modification in API has to done via microversion bump.

API extensions concept was deprecated from the v2.1 API, are no longer needed to evolve the REST API, and no new API functionality should use the API extension classes to implement new functionality. Instead, new API functionality should be added via microversion concept and use the microversioning decorators to add or change the REST API.

v2.1 API had plugin framework which was using stevedore to load Nova REST API extensions instead of old V2 handcrafted extension load mechanism. There was an argument that the plugin framework supported extensibility in the Nova API to allow deployers to publish custom API resources.

In Newton release, config options of blacklist and whitelist extensions and stevedore things were deprecated and marked for removal.

In Pike, stevedore based plugin framekwork has been removed and url mapping is done with plain router list. No more dynamic magic of detecting API implementation for url.

The '/extensions' API exposed the list of enabled API functions to users by GET method. However as the above, new API extensions should not be added to the list of this API. The '/extensions' API is frozen in Nova V2.1 API and is deprecated.

Things which are History now¶

Till Pike release, many deprecated things have been removed and became history in Nova API world:

• v2 legacy framework.
• API extensions concept.
• Stevedore magic to load the extension/plugin dynamically.
• Configurable way to enable/disable APIs extensions.