The initial cinder design[1][2][3] allowed users to create mutliattach
volumes by spcifying the ``multiattach`` parameter in the request
body of volume create operation (``--allow-multiattach`` option in
cinderclient).
This functionality changed in Queens with the introduction of
microversion 3.50[4] where we used volume types to store
the multiattach capabilities. Any volume created with a multiattach
volume type will be a multiattach volume[5].
While implementing the new functionality, we had to keep backward
compatibility with the *old way* of creating multiattach volumes.
We deprecated the ``multiattach`` (``--allow-multiattach`` on cinderclient
side) parameter in the queens release[6][7].
We also removed the support of the ``--allow-multiattach`` optional
parameter from cinderclient in the train release[8] but the API
side never removed the compatibility code to disallow functionality
of creating multiattach volumes by using the ``multiattach``
parameter (instead of a multiattach volume type).
This patch removes the support of providing the ``multiattach``
parameter in the request body of a volume create operation and will
fail with a BadRequest exception stating the reason of failure
and how it can be fixed.
[1] https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume
[2] https://review.opendev.org/c/openstack/cinder/+/85847/
[3] https://review.opendev.org/c/openstack/python-cinderclient/+/85856
[4] f1bfd9790d
[5] https://docs.openstack.org/cinder/latest/admin/volume-multiattach.html#how-to-create-a-multiattach-volume
[6] 94dbf5cce2
[7] adb141a262
[8] 3c1b417959
Depends-On: https://review.opendev.org/c/openstack/tempest/+/875372
Closes-Bug: 2008259
Change-Id: I0ece6e279048abcc04b3674108290a80eca6bd62
As shown in https://zuul.opendev.org/t/openstack/build/e39652d2dc8f4cb394933da8f9a9bb59/log/job-output.txt,
host name may contain '@', but not necessary to contain '@',
like:
Request (VolumeHostsV3RbacTest:test_show_host):
200 GET https://10.208.227.163/volume/v3/67d6a092ee7d4cd4a6b3ae37812bec50/os-hosts/ubuntu-bionic-rax-dfw-0010673901
Response Body: {"host":
[{"resource":
{"volume_count": "2", "total_volume_gb": "2",
"total_snapshot_gb": "1", "project": "(total)",
"host": "ubuntu-bionic-rax-dfw-0010673901",
"snapshot_count": "1"}},
{"resource":
{"volume_count": "1", "total_volume_gb": "1",
"total_snapshot_gb": "0",
"project": "2aba5d9825ac47a7b8c3ea805af34a75",
"host": "ubuntu-bionic-rax-dfw-0010673901",
"snapshot_count": "0"}}}
Besides, the format 'host@backend' should be that of host_name_backend,
not host.
Change-Id: Id2c0be1e4d0471686674ef781b722087638c4c50
In "List all hosts for a project", service-status should take
the values of ['available', 'unavailable'], (service-state takes
the value of ['enabled', 'disabled']), and because os-services API
uses service_status which requires returning `enabled` and `disabled`,
we need add a new parameter host_service_status for os-hosts API.
https://docs.openstack.org/api-ref/block-storage/v3/index.html#list-all-hosts-for-a-project
partially-implements: blueprint volume-response-schema-validation
Change-Id: Idde4a63f00862599a13bcfcdadc1d4459f27d3a4
Everything that goes through the volumes view builder
detail() method has a strict is_admin check on returning
the migration_status parameter [1]. This means the
migration_status parameter in the API reference should
be optional since it's admin-only and not always shown.
This fixes the v2 and v3 API references for showing,
creating, updating, resetting the status of, and creating
from a managed volume. As a result, the parameter for a
required migration_status parameter is unused and removed.
Note that there is no strict policy check on the
migration_status request parameter when resetting a volume's
status, but the action itself is admin-only by default
using the volume_extension:volume_admin_actions:reset_status
policy rule.
[1] https://opendev.org/openstack/cinder/src/tag/14.0.0/cinder/api/v2/views/volumes.py#L94
Change-Id: I82308dc1a6aaf039b675a17e19747f11be574209
Closes-Bug: #1828113
This admin API is only called externally by Nova at present when
finishing the migration or retype of an attached volume. However for
future reference it would be really useful to have this listed in the
official API reference guide.
Change-Id: I5fad6eb4903784870aa26fa0996a391bbbbb9276
This cleans up the cases where we had D001 violations so we can stop
skipping that check in doc8 runs.
Change-Id: Ie52f6ecac1a645fcbcc643b9ca63e033b622d830
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
https://developer.openstack.org/api-ref/block-storage/v3/index.html#list-snapshots-and-details
1. updated_at is missing in the response fields of show-snapshot
and list-snapshots
2. id's description is "The UUID of the volume transfer.", which
is incorrect.
3. volume_id's description is "The UUID of the volume.", which is
not very accurate.
4. os-extended-snapshot-attributes:progress is something like '100%',
so it should be string, not integer
5. response fields of show-snapshot-metadata is incorrect.
6. metadata is missing in the response example of update-snapshot
7. snapshots_links is missing in the response of list-snapshot
Change-Id: I0f6994c2d2dc27d3d594acdd460e27c338f86a2c
Some drivers will report total_capacity and free_capacity
as float, so this is to change the data type description to
include floating point.
Change-Id: Icd206ba3733adf9543a9e1384ef7245e287ee858
With the addition of schema validation and the release of cinderclient
4.0.0 we no longer accept source_replica as a volume creation parameter.
This was part of the short lived replication v1 functionality that was
removed several releases ago and never had support beyond one backend
type for one or two releases and has had no affect for quite a while
now.
Change-Id: Idd848628759884c1e637ca17dc292f776e4adf47
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The volume_type parameter to the volume create API can be
either the volume type name or ID, the cinder-api will look
it up either way. This wasn't obvious from the API reference
and required digging into the code to figure it out. This change
simply clarifies the usage in the API reference.
Change-Id: Iae8c43374dee9767e17252279822ccd2121d8246
The "name" parameter to the volume create API is optional,
this makes the docs reflect that. While in here, I've
renamed volume_name_1 to volume_name_optional so the variable
name is descriptive and dropped the redundant name_8 variable.
Change-Id: Ice42f06112a268b229f770f34096de19eb3447b2
Closes-Bug: #1794115
Adds the v2 and v3 API reference documentation for the
admin-only (by default) os-migrate_volume volume action
API. The only major difference with the v3 API is the
cluster parameter introduced in the 3.16 microversion.
Change-Id: I70f6b2cc4d25ea155ce09ddeec26b995890a2db3
Partial-Bug: #1607539
"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
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
Nova has historically not supported swap volume operations (via
cinder volume retype / volume migration) for an in-use encrypted
volume.
That was recently addressed via nova bug 1739593.
However, as of change Ibfa64f18bbd2fb70db7791330ed1a64fe61c1355
in nova, depending on the version of libvirt/qemu on the compute host,
a luks-encrypted volume will use native qemu luks decryption. That
does not yet support blockRebase operations which are used during
swap volume due to https://bugzilla.redhat.com/show_bug.cgi?id=760547.
So it's safe to say that for now, a retype which involves a volume
migration is not supported for an in-use encrypted volume.
Change-Id: I7ce992f51d50d00950d3fc4ebb44b69a31a94787
Related-Bug: #1739593
1 The 'volume_type' shoud be required in the rest_method of request.
So fix the request paremeter about volume_type
2 Fix the parameters of 'volume_type' in the volumes-v3-volumes.inc
Change-Id: I585db62579ac134885a49dc020508a9f0fba3c78
The multiattach parameter is optional when creating
a volume but is required to be in the response when
showing a volume.
This fixes the parameter usage, renames the parameters
so they are more clear (multiattach_1 was for the response
but was never used), and also adds a note to the multiattach
request parameter about how support is dependent on the volume
type being used to create the volume.
Change-Id: Ifaa29140a8e8a9b8090f33fb83e4bb5c98ee847f
The detailed information for a volume can include "volume_image_metadata"
in the case where the volume was created from an image, or in the case
where the volume was created from a snapshot of such a volume.
Update the API ref to include the field so we accurately represent
the code.
Change-Id: If5fcdefaa10bfb00e60aa4559d3282d3c6a53752
Closes-Bug: #1732763
During the initial migration of the api-ref docs, there were
several parameter definitions pulled over that are not actually
used anywhere in the docs.
It may be that some of these _should_ be referenced, but at
least as of right now they are not. Rather than carrying them
around on the chance that they could be used down the road, we
should just clean them out for now.
Change-Id: Ic9018608b00705c80df05243647f5c81124610df
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
whoami-rajat