Extensions are always interpreted in relation to a version of the core API. In other words, from a client's perspective, an extension modifies a particular version of the core API in some way. In reality, an extension may be applicable to several versions of an API at once. For example, a particular extension may continue to be available as a core API moves from one version to another. In fact, different implementations may decide to include support for an extension at different versions. As explained in , when an extension is defined, the minimal version of the core API that is required to run the extension is specified; implementers are free to support the extension in that version or in a later version of the core. Note, however, that because the extension mechanism allows for promotion, an extension in one version of a core API may become a standard feature in a later version.
![]() | Note |
---|---|
As always, implementers are not required to support an extension unless it is promoted to the core. |
Because several versions of the core API may be supported simultaneously, and
because each version may offer support for a different set of extensions, clients
must be able to detect what versions and extensions are available in a particular
deployment. Thus, both extensions and versions are queryable. Issuing a GET on the
base URL (/
) of the API endpoint returns information about what
versions are available. Similarly, issuing a GET on the API's extensions resource
(/v1.1/extensions
) returns information about what extensions are
available. (See
for details of such requests.) Note that,
since extensions modify a particular version of the API, the extensions
resource itself is always accessed at a particular version.
Backward-compatible changes in an API usually require a minor version bump. In an extensible API, however, these changes can be brought in as extensions. The net effect is that versions change infrequently and thus provide a stable platform on which to develop. The Policy Review Board (PRB), with the help of project team leaders, is responsible for ensuring that this stability is maintained by closely guarding core API versions. Extensions, however, can be developed without the consent or approval of the PRB. They can be developed in a completely decentralized manner both by individual OpenStack developers and by commercial vendors. Because extensions can be promoted to standard features, the development of new versions can be influenced significantly by individual developers and the OpenStack client community and is therefore not strictly defined by the PRB. In other words, new features of a core API may be developed in a bottom-up fashion.
That said, not all extensions are destined to be promoted to the next API version. Core APIs always deals with core functionality — functionality that is supported by all implementations and is applicable in common cases. Extensions that deal with niche functionality should always remain extensions.
The table below summarizes the differences between versions and extensions.
Table 2.1. Versions versus Extensions
Versions | Extensions |
---|---|
Rare. Versions provide a stable platform on which to develop. |
Frequent. Extensions bring new features to the market quickly and in a compatible manner. |
Centralized. Versions are maintained by the entity that controls the API Spec: the OpenStack Policy Review Board. Only the PRB can create a new version; only the PRB defines what "OpenStack Compute 1.1" means. |
Decentralized. Extensions are maintained by third parties, including individual OpenStack developers and software vendors. Anyone can create an extension. |
Core. Versions support core functionality. |
Niche. Extensions provide specialized functionality. |
Queryable.
Issuing a GET on the base
URL ( |
Queryable.
Issuing a GET on the API's
extensions resource
( |