From df0a99a29adcd58c3c026f1ca1d0aa305d8809c4 Mon Sep 17 00:00:00 2001 From: Sean Mooney Date: Mon, 2 Oct 2023 22:20:01 +0100 Subject: [PATCH] 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 --- api-guide/source/general_info.rst | 2 +- api-guide/source/microversions.rst | 24 +++++++++++----------- api-guide/source/paginated_collections.rst | 2 +- api-guide/source/polling_changes.rst | 4 ++-- api-guide/source/server_concepts.rst | 4 ++-- api-guide/source/versions.rst | 6 +++--- 6 files changed, 21 insertions(+), 21 deletions(-) diff --git a/api-guide/source/general_info.rst b/api-guide/source/general_info.rst index b0e8574960..769023ee17 100644 --- a/api-guide/source/general_info.rst +++ b/api-guide/source/general_info.rst @@ -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. diff --git a/api-guide/source/microversions.rst b/api-guide/source/microversions.rst index b1590123cb..5a2045ce14 100644 --- a/api-guide/source/microversions.rst +++ b/api-guide/source/microversions.rst @@ -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 diff --git a/api-guide/source/paginated_collections.rst b/api-guide/source/paginated_collections.rst index e817642bf2..912cd771f7 100644 --- a/api-guide/source/paginated_collections.rst +++ b/api-guide/source/paginated_collections.rst @@ -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 diff --git a/api-guide/source/polling_changes.rst b/api-guide/source/polling_changes.rst index 671ad89434..eac8e17df5 100644 --- a/api-guide/source/polling_changes.rst +++ b/api-guide/source/polling_changes.rst @@ -10,10 +10,10 @@ for changes within a specified time. The ``changes-since`` time or ``changes-before`` time is specified as an `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: diff --git a/api-guide/source/server_concepts.rst b/api-guide/source/server_concepts.rst index 9341965140..b434353513 100644 --- a/api-guide/source/server_concepts.rst +++ b/api-guide/source/server_concepts.rst @@ -95,8 +95,8 @@ are exposed to administrators: Refer to :nova-doc:`VM States `. - 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 diff --git a/api-guide/source/versions.rst b/api-guide/source/versions.rst index 4019899e81..d7bfd8d226 100644 --- a/api-guide/source/versions.rst +++ b/api-guide/source/versions.rst @@ -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