This patch adds some missing params in volume types
and volume type access APIs. Also trivial fix for
the order of the params in the URL.
Change-Id: I767f68b4252a3b70755494cf82ca3b284112be75
In the attachment API, the response parameters, such as ``detached_at``,
``attached_at``, ``attach_mode``, ``instance`` are optional, however these
should be required, this is to fix these.
Change-Id: I2748e971655c3f5715585409e5c021f0d91690e4
"backup_gigabytes" and "per_volume_gigabytes" parameters
are supported in api v2, they aren't mentioned in api v2
document[1]. On the other hand both of them are mentioned
in api v3 document[2].
[1] https://developer.openstack.org/api-ref/block-storage/
v2/index.html#update-quotas
[2] https://developer.openstack.org/api-ref/block-storage/
v3/index.html?highlight=backup_gigabytes#update-quotas
-for-a-project
Change-Id: I135efd5c2b4735f5821922643926390976453bf5
Closes-bug: #1727631
Show v3 API version details should not return informations about v2,
meanwhile location is not in Response Parameters.
Change-Id: Ida12222b3bdac10d030d56b9724f09ee097c0b3c
A bunch of volume APIs are missing in current documentation, such
as os-reserve/os-unreserve/os-begin_detaching/os-roll_detaching
os-initialize_connection/os-terminate_connection, this patch is aim to
add the missing APIs.
Change-Id: If0732aa94db4e8cdef30a2be0c53314b507ee002
Closes-bug: #1761049
The value of host in sample request and sample response is not correct,
this change is to update this.
Change-Id: If8524a08795c222e67ca2c85243a42fb27e43bdb
Close-bug: #1758955
The api-ref stated new volumes created from a source volume or
snapshot would have the same size as the original, but that is
not the case if a larger size is requested.
Change-Id: Id2e0d53b56d5879026c182521a512dc2cfcd28f7
'os-volume-replication:extended_status' and
'os-volume-replication:driver_date' are unavailable
since the merge of patch [1] during Liberty, remove these
from API document.
[1]: https://review.openstack.org/#/c/275797/
Change-Id: Ib319702f085930a6bf528ef95fb17a7da8451e96
This is not part of the API contract. It should
be documented elsewhere as a limitation of the
volume driver.
Change-Id: I3586853ce7e11150d54cc552863bd3d4f6db197b
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
The default attach_mode for volume attachments is "rw", as can
be seen from looking at the VolumeAttachment.finish_attach method
and VolumeManager.attachment_update method. The REST API itself
does not set or return a default attach_mode, it's all set in the
data model when the attachment is 'completed' by assigning a host
connector.
Change-Id: I1e41e93bd534d830311a653eb16fef89a2d8431a
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
Add API document for 'list_volume' in Group
show&list APIs.
Code patch: https://review.openstack.org/#/c/409694
Change-Id: Ib328b62c61ec8b8afed3de07020c7ae2bfb163be
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
