fix sphinx-lint issues in api guide
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:
parent
0829c1b995
commit
df0a99a29a
@ -250,7 +250,7 @@ on compute hosts rather than servers.
|
||||
A hypervisor, or virtual machine monitor (VMM), is a piece of computer
|
||||
software, firmware or hardware that creates and runs virtual machines.
|
||||
|
||||
In nova, each Host (see `Hosts`) runs a hypervisor. Administrators are able
|
||||
In nova, each Host (see ``Hosts``) runs a hypervisor. Administrators are able
|
||||
to query the hypervisor for information, such as all the virtual servers
|
||||
currently running, as well as detailed info about the hypervisor, such as
|
||||
CPU, memory, or disk related configuration.
|
||||
|
@ -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
|
||||
|
@ -25,7 +25,7 @@ implementation does not contain ``previous`` links. The last
|
||||
page in the list does not contain a link to "next" page. The following examples
|
||||
illustrate three pages in a collection of servers. The first page was
|
||||
retrieved through a **GET** to
|
||||
`http://servers.api.openstack.org/v2.1/servers?limit=1`. In these
|
||||
``http://servers.api.openstack.org/v2.1/servers?limit=1``. In these
|
||||
examples, the *``limit``* parameter sets the page size to a single item.
|
||||
Subsequent links honor the initial page size. Thus, a client can follow
|
||||
links to traverse a paginated collection without having to input the
|
||||
|
@ -10,10 +10,10 @@ for changes within a specified time.
|
||||
|
||||
The ``changes-since`` time or ``changes-before`` time is specified as
|
||||
an `ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601>`__ dateTime
|
||||
(`2011-01-24T17:08Z`). The form for the timestamp is **CCYY-MM-DDThh:mm:ss**.
|
||||
(``2011-01-24T17:08Z``). The form for the timestamp is **CCYY-MM-DDThh:mm:ss**.
|
||||
An optional time zone may be written in by appending the form ±hh:mm
|
||||
which describes the timezone as an offset from UTC. When the timezone is
|
||||
not specified (`2011-01-24T17:08`), the UTC timezone is assumed.
|
||||
not specified (``2011-01-24T17:08``), the UTC timezone is assumed.
|
||||
|
||||
The following situations need to be considered:
|
||||
|
||||
|
@ -95,8 +95,8 @@ are exposed to administrators:
|
||||
Refer to :nova-doc:`VM States <reference/vm-states.html>`.
|
||||
|
||||
- task_state represents what is happening to the instance at the
|
||||
current moment. These tasks can be generic, such as `spawning`, or specific,
|
||||
such as `block_device_mapping`. These task states allow for a better view into
|
||||
current moment. These tasks can be generic, such as ``spawning``, or specific,
|
||||
such as ``block_device_mapping``. These task states allow for a better view into
|
||||
what a server is doing.
|
||||
|
||||
Server creation
|
||||
|
@ -37,7 +37,7 @@ Permanent Links
|
||||
|
||||
The MIME type versioning approach allows for creating of permanent
|
||||
links, because the version scheme is not specified in the URI path:
|
||||
`https://api.servers.openstack.org/224532/servers/123`.
|
||||
``https://api.servers.openstack.org/224532/servers/123``.
|
||||
|
||||
If a request is made without a version specified in the URI or via HTTP
|
||||
headers, then a multiple-choices response (300) follows that provides
|
||||
@ -99,8 +99,8 @@ everything following that truncated) returned from the authentication system.
|
||||
|
||||
You can also obtain additional information about a specific version by
|
||||
performing a **GET** on the base version URL (such as,
|
||||
`https://servers.api.openstack.org/v2.1/`). Version request URLs must
|
||||
always end with a trailing slash (`/`). If you omit the slash, the
|
||||
``https://servers.api.openstack.org/v2.1/``). Version request URLs must
|
||||
always end with a trailing slash (``/``). If you omit the slash, the
|
||||
server might respond with a 302 redirection request.
|
||||
|
||||
For examples of the list versions and get version details requests and
|
||||
|
Loading…
x
Reference in New Issue
Block a user