Merge "Update stable API doc to indicate code removal"

This commit is contained in:
Jenkins 2016-06-21 20:51:49 +00:00 committed by Gerrit Code Review
commit e97ff80042

View File

@ -19,20 +19,21 @@ Nova Stable REST API
====================
This document describes both the current state of the Nova REST API -- as
of the Kilo release -- and also attempts to describe how the Nova team intends
of the Newton release -- and also attempts to describe how the Nova team intends
to evolve the REST API's implementation over time and remove some of the
cruft that has crept in over the years.
Background
----------
Nova currently includes two distinct frameworks for exposing REST API
functionality. Older code is called the "V2 API" and exists in the
/nova/api/openstack/compute/contrib/ directory. Newer code is called the
"v2.1 API" and exists in the /nova/api/openstack/compute/plugins directory.
Nova used to include two distinct frameworks for exposing REST API
functionality. Older code is called the "V2 API" and existed in the
/nova/api/openstack/compute/legacy_v2/ directory. This code tree was totally
removed during Netwon release time frame (14.0.0 and later).
Newer code is called the "v2.1 API" and exists in the
/nova/api/openstack/compute directory.
The V2 API is the old Nova REST API. It will be replaced by V2.1 API totally.
The code tree of V2 API will be removed in the future also.
The V2 API is the old Nova REST API. It is mostly replaced by V2.1 API.
The V2.1 API is the new Nova REST API with a set of improvements which
includes Microversion and standardized validation of inputs using JSON-Schema.
@ -53,7 +54,7 @@ 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.
API extensions, while not (yet) removed from the V2.1 API, are no longer
API extensions, being removed 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 use the microversioning decorators to add or change
@ -63,9 +64,6 @@ The extension is considered as two things in the Nova V2.1 API:
* The '/extensions' API
In the V2 API the user can query it to determine what APIs are supported by
the current Nova deployment.
In V2.1 API, microversions enable us to add new features in backwards-
compatible ways. And microversions not only enable us to add new futures by
backwards-compatible method, also can be added by appropriate backwards-
@ -83,10 +81,6 @@ The extension is considered as two things in the Nova V2.1 API:
There was an argument that the plugin framework supported extensibility in
the Nova API to allow deployers to publish custom API resources.
We will keep the existing plugin mechanisms in place within Nova but only
to enable modularity in the codebase, not to allow extending of the Nova
REST API.
As the extension will be removed from Nove V2.1 REST API. So the concept of
core API and extension API is eliminated also. There is no difference between
Nova V2.1 REST API, all of them are part of Nova stable REST API.
From Nove V2.1 REST API, the concept of core API and extension API is
eliminated also. There is no difference between Nova V2.1 REST API,
all of them are part of Nova stable REST API.