Using the wrong character resulted in the wrong title level
being used for the response codes, which in turn caused the
"detail" show/hide toggle to not be able to hide all of the
per-endpoint details. This corrects these to be at the correct
level.
Also ran into issues after changing them where sphinx was not
happy with the random title levels. This appears to be due to
the order processed and whether not earlier included files had
all subsequent levels. Adding an additional title in our first
included file resolved that problem.
Change-Id: I19405778980310f2d6d06eb7b23102f74a3d6e03
Closes-bug: #1755566
Rather than our freeform way of listing response codes in our
api-ref, we should be using the os-api-ref extension option to
get nicely formatted response code listings.
https://docs.openstack.org/os-api-ref/latest/usage.html#rest-status-code
Change-Id: Iee21f54fe7cf0ea28258966e2d0f8fa2849c83f2
the status of volume must be available.
the size of the volume must be equal to or greater than
the backup size.
Change-Id: I89bb72741aec5e73789a5a5cec1bc363f79c766c
We currently limit backups to the same AZ of the volume while allowing
volume restoration to any AZ.
When having multiple AZs it is ideal to store your backups in a
different AZ than the one where the source volumes are stored.
This patch adds microversion 3.51 where we allow requesting the AZ where
we want to store backups which will allow us to have as many backup AZs
as volume AZs and do cross AZ backups for increased security, this
feature also supports having an additional AZ just for backups or the
less desirable solution where you store all your backups in a single AZ
shared with some of the volumes.
Change-Id: I595932276088d25abd464025c99dce33a2cc502b
Cinder REST API allows one to use a special query parameter
named "all_tenants" to list resources from all projects (tenants)
through the REST API:
`/v3/{project_id}/volumes/detail?all_tenants=1`
However, this option is hardly documented anywhere besides
`/v3/{project_id}/volumes/summary`. So add them.
Change-Id: Ia9cc9e20c3b333a054c90f07e952b61dfad8529e
Closes-Bug: #1743800
In v3 api-ref for restoring backup, the request contents are wrongly
described, it is mandatory to specify either the UUID or name of the
volume, Actually it's OK if you specify nothing.
The name parameter will work only if a new volume is created for restore.
Closes-Bug:#1732664
Change-Id: Ia6a9b99df0c7b83999a2e5ac9c945c91b284f807
Signed-off-by: Xiaojun Liao <xiaojunliao85@gmail.com>
This patch adds support for display count info
in volume, backup and snapshot's list&detail APIs
since microversion 3.45, for instance:
1. /v3/{project_id}/volumes?with_count=True
2. /v3/{project_id}/volumes/detail?with_count=True
Depends-On: 1c8fe0ade43da925c5b810ef0cd27817f1c11c7b
Change-Id: I2e92b27c36357120fcf0ec5917c6484441c946a8
Implements: bp add-amount-info-in-list-api
We had a mix of formatting for our API response codes. This
makes it so all have a leading space, no trailing comma, and
no empty Error response labels.
This also addresses a formatting issue with due to the spacing
between the Normal and Error lines that was causing the two to
run together in the formatted HTML, making it harder to read.
Change-Id: Ic411ee9f671c48ce60bda21984dafe55135685ba
Some request details provided information about the other
JSON value while others didn't. To make things consistent
and to make sure API consumers understand how the requests
need to be structured, this adds missing instances. It also
reorders some parameter lists to be a little more logical,
so even though we can't show the nested nature of some of
these, it at least doesn't show inner values before outer
ones.
This also corrects many errors seen while going through
the API ref. This is by no means exhaustive, and is already
somewhat out of the scope for this patch, so it is expected
that there are some (many) cases that are not addressed by
this patch. Those will be fixed with ongoing effort in
future patches.
Partial-bug: #1713517
Change-Id: I30964ba8d829778fd01174d639d44ba07e4b77a6
During the migration to in-tree api-ref docs we somehow lost the details
for backup export_record and import_record. Adding back in.
Also fixing up a few records that referred to the wrong parameter record
names, resulting in their descriptions referring to volume transfer for
backup operations.
Change-Id: I6fc555729c1b8404887d41424831fc48934f1491
Closes-bug: #1628812
Closes-bug: #1712923
Support metadata for backup resource was introduced in cinder [1]
but it's not documented in the API docs anywhere, This change is
to add them in the api docs.
[1] https://review.openstack.org/#/c/471541/
Change-Id: I0b444b9c48f156786433b7f622bae5dd6f274c59
Closes-bug: #1709254
Now cinder has supported to query project id of a given backup since
V3.18 after the patch [1].
This patch added the related api-ref.
[1] I6fde17baffe88ab4d4e69dcc2fefdbcb8d7a4dc5
Change-Id: Ie581b33964bf24689cf0ab099b8c7341af4aeb4b
In the api-ref/source/v2 and api-ref/source/v3, Add response
example for some of volumes, backups, consistencygroups doc.
Change-Id: I2d89df3cf6f691d6cde2429b1b33b5b16af3269c
Cinder added updating backup support in V3.9.
This patch added related api-ref.
Change-Id: I537cb609240e3bcfa130a116e1912d1b660a21f8
Closes-bug: #1607388
Add "snapshot_id" and "data_timestamp" and "volume_name" to
the response parameters and error response code in the api-ref of
ext-backups.inc.
Change-Id: I2e3a6c737a74816e5e56b5a435a73e0bf501bec8
Closes-bug: #1676693
Now cinder will raise 400 if invalid filter
keys are specified, Update the corresponding
list APIs.
DocImpact
Depends-On: ff3d41b15abb2915de87830980147be51e5da971
Change-Id: I8419b374d7f743e7e9fc88e31c8c4f7d9470059b
We have introduced a filter, sorter and pagination
in listing APIs. Adding the missing parameters
in api-ref.
Change-Id: Id32fb09ba659e2ba83910d37018de9e18302d5b6
Modifies heading levels in .inc files to allow nested display in
table of contents. Table of contents depth has been changed to allow
this.
Change-Id: I3d8c9cf38a12272f0d32d3aa183d741277767535
Keystone API v2 was deprecated in Mitaka and uses "project"
instead of "tenant" in V3 now.
This patch change the "tenant" to "project" in Cinder API v3 doc.
Change-Id: I06d400f3e38d78014e9eae89b29b075adaecffe4
In the api ref most of our references to the status parameter are wrong,
since they are all referencing `status`, which in most cases is:
status:
description: |
The ``status`` of the consistency group snapshot.
This patch fixes this by referencing the right status parameter.
TrivialFix
Change-Id: I3f76ad10bacd8c75f742efc3ff3395a7effc31b5
Current doc states "Error repsonse codes:204". This should actually
by "Normal response code" and be 202 (Accepted) vs 204 (No Content).
Change-Id: I6e3855b2d1280de3e0fe6b5638feb54e9dfa4c10
Closes-bug: #1598237
The Cinder v3 API was marked CURRENT in Mitaka, but there no API ref
was ever created. This is problematic for end users and would hinder
the v3 API from being included in DefCore Interoperability Guidelines
somewhere down the line (since one of DefCore's Criteria[1] is that a
Capability be well documented). This patch creates an API ref for v3.
It also adds a header to the v2 index to show that it is SUPPORTED,
whereas v3 is CURRENT.
[1]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n77
Change-Id: Ia3a8050cd04ad3a487a79d80acf9691feee6182e
Closes-Bug: #1616072
