womax/nova
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix sphinx-lint issues in api guide

Browse Source 
as with the previous commit this change is simply correcting the
usage of backticks for inline literals

Change-Id: Icbfd168266dc1348ee15f7347ed673d220989ceb
This commit is contained in:
Sean Mooney
2023-10-02 22:20:01 +01:00
parent 0829c1b995
commit df0a99a29a
6 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
api-guide/source/microversions.rst
+12 -12
View File
@@ -32,7 +32,7 @@ There are multiple cases which you can resolve with microversions:
compatible with the old API. This prevents the old client from breaking with
backwards incompatible API changes.
Currently the minimum version of microversions is `2.1`, which is a
Currently the minimum version of microversions is ``2.1``, which is a
microversion compatible with the legacy v2 API. That means the legacy v2 API
user doesn't need to worry that their older client software will be broken
when their cloud is upgraded with new versions. And the cloud operator
@@ -52,7 +52,7 @@ Version Discovery
The Version API will return the minimum and maximum microversions. These values
are used by the client to discover the API's supported microversion(s).
Requests to `/` will get version info for all endpoints. A response would look
Requests to ``/`` will get version info for all endpoints. A response would look
as follows::
{
@@ -89,14 +89,14 @@ as follows::
``version`` is the maximum microversion, ``min_version`` is the minimum
microversion. If the value is the empty string, it means this endpoint doesn't
support microversions; it is a legacy v2 API endpoint -- for example, the
endpoint `http://openstack.example.com/v2/` in the above sample. The endpoint
`http://openstack.example.com/v2.1/` supports microversions; the maximum
microversion is `2.14`, and the minimum microversion is `2.1`. The client
endpoint ``http://openstack.example.com/v2/`` in the above sample. The endpoint
``http://openstack.example.com/v2.1/`` supports microversions; the maximum
microversion is ``2.14``, and the minimum microversion is ``2.1``. The client
should specify a microversion between (and including) the minimum and maximum
microversion to access the endpoint.
You can also obtain specific endpoint version information by performing a GET
on the base version URL (e.g., `http://openstack.example.com/v2.1/`). You can
on the base version URL (e.g., ``http://openstack.example.com/v2.1/``). You can
get more information about the version API at :doc:`versions`.
Client Interaction
@@ -107,7 +107,7 @@ HTTP header::
X-OpenStack-Nova-API-Version: 2.4
Starting with microversion `2.27` it is also correct to use the
Starting with microversion ``2.27`` it is also correct to use the
following header to specify the microversion::
OpenStack-API-Version: compute 2.27
@@ -118,7 +118,7 @@ following header to specify the microversion::
This acts conceptually like the "Accept" header. Semantically this means:
* If neither ``X-OpenStack-Nova-API-Version`` nor ``OpenStack-API-Version``
(specifying `compute`) is provided, act as if the minimum supported
(specifying ``compute``) is provided, act as if the minimum supported
microversion was specified.
* If both headers are provided, ``OpenStack-API-Version`` will be preferred.
@@ -128,9 +128,9 @@ This acts conceptually like the "Accept" header. Semantically this means:
of microversions supported, return 406 Not Acceptable.
* If ``X-OpenStack-Nova-API-Version`` or ``OpenStack-API-Version`` has a value
of `latest` (special keyword), act as if maximum was specified.
of ``latest`` (special keyword), act as if maximum was specified.
.. warning:: The `latest` value is mostly meant for integration testing and
.. warning:: The ``latest`` value is mostly meant for integration testing and
would be dangerous to rely on in client code since microversions are not
following semver and therefore backward compatibility is not guaranteed.
Clients should always require a specific microversion but limit what is
@@ -140,7 +140,7 @@ This means that out of the box, an old client without any knowledge of
microversions can work with an OpenStack installation with microversions
support.
In microversions prior to `2.27` two extra headers are always returned in
In microversions prior to ``2.27`` two extra headers are always returned in
the response::
X-OpenStack-Nova-API-Version: microversion_number
@@ -153,7 +153,7 @@ The ``Vary`` header is used as a hint to caching proxies that the response
is also dependent on the microversion and not just the body and query
parameters. See :rfc:`2616` section 14.44 for details.
From microversion `2.27` two additional headers are added to the
From microversion ``2.27`` two additional headers are added to the
response::
OpenStack-API-Version: compute microversion_number