openstack/nova - nova - OpenDev: Free Software Needs Free Tools

This microversion adds attachment_id and bdm_uuid as stored in the
underlying bdm record while also removing the duplicate id field from
the responses of ``GET /servers/{server_id}/os-volume_attachments`` and
``GET /servers/{server_id}/os-volume_attachments/{volume_id}``.
To accomidate this within the _translate_attachment_summary_view helper
is folded into _translate_attachment_detail_view with the remaining
caller in the now deprecated os-volumes API now replaced with a static
dictionary.
Blueprint: add-attachmentid-to-responses-of-the-os-volume-attachments-api
Change-Id: I977c3fd9bbb1e1d42e6979222137e7366d2815e8

This change adds some basic notes in the api-ref for a wrinkle in the
current os-volume_attachments API in that both attach and detach actions
are async, returning to the caller *before* the underlying action is
complete. As such callers need to make seperate calls to ensure these
actions complete successfully.
There are also currently two different ways of polling for completion
when attaching and detaching.
- When attaching callers should use the volume status and list of
 attachments as reported by the volume API.
- When detaching callers should instead use the list of volume attachments
 reported by the os-volume_attachments API.
This is due to the way in which Nova currently completes the attachment
via c-api last during attachment and deletes the bdm record last during
detachment.
It would be useful to one day centralise on just using the
os-volume_attachments API to poll both actions but to do that we would
need to start tracking our own state within the BDMs.
Change-Id: Id367ee53ef1458b6a90fc107ab14f5b3cbba7a86

Allow PUT /servers/{server_id}/os-volume_attachments/{volume_id}``
to support specifying ``delete_on_termination`` field in the request
body. This allows updating the attached volume's flag that controls
whether or not it is automatically deleted when the instance is deleted.
When we request 'volumeId' and 'delete_on_termination' in the requst
body to swap volume, since the new microversion it will be support
updating the swapping volume's delete flag.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Blueprint: destroy-instance-with-datavolume
Change-Id: I6ccac4e17f56b40e67c79d40f32558ef414685ea

Some comment mainly from gmann and takashin in [1] PS15.
Add some tests in test_volumes.py, and fix some docs error.
[1]https://review.opendev.org/#/c/673133/15/nova/tests/unit/api/openstack/compute/test_volumes.py@1902
Depends-On: https://review.opendev.org/#/c/673133/
Part of blueprint support-delete-on-termination-in-server-attach-volume
Change-Id: I8dfa61f03ce927a1e86d42f8fb03bf4cb3e48160

The 'device' response parameter is not included in
GET /servers/{server_id}/os-volume_attachments or
GET /servers/{server_id}/os-volume_attachments/{volume_id}
when the BDM doesn't have a device_name set, which can be the
case with a volume attached to a shelved offloaded server.
Also, see the logic in _translate_attachment_detail_view
and _translate_attachment_summary_view. This simply marks
the response parameter as optional in those APIs. Since
the parameter is optional, it is sorted to after the required
parameters but before the parameters added in new microversions.
Change-Id: Ifda2f7983f349d51d97e5621cac6c5ad9cb0295f
Closes-Bug: #1818345 

Add the 'delete_on_termination' field to the volume attach API to support
configuring whether to delete the data volume when the instance is destroyed.
To avoid upgrade impact issues with older computes, the
'delete_on_termination' field is set in the API rather than when the BDM
is created in the compute service.
Implements: blueprint support-delete-on-termination-in-server-attach-volume
Change-Id: I55731b1822a4e32909665a2872d80895cb5b12f7

If we're swapping from a multiattach volume that has more than one
read/write attachment, another server on the secondary attachment could
be writing to the volume which is not getting copied into the volume to
which we're swapping, so we could have data loss during the swap.
This change does volume read/write attachment counting for the volume
we're swapping from and if there is more than one read/write attachment
on the volume, the swap volume operation fails with a 400 BadRequest
error.
Depends-On: https://review.openstack.org/573025/
Closes-Bug: #1775418
Change-Id: Icd7fcb87a09c35a13e4e14235feb30a289d22778

This change adds a new microversion to expose virtual
device tags for volumes and ports attached to a server.
Implements blueprint expose-virtual-device-tags-in-rest-api
Change-Id: I09420ff7134874dfe4dc399931c7740e81ecc2d0

Per the ML thread on this [1] we should have a warning in
the API discouraging people from swapping volumes directly
in nova.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-August/133527.html
Change-Id: If095e1d9bae8be7a23212684ed9d2e043c0cbf59

Since change Iac03258735f3d856a474ab96fe9b0a087e32906f the
PUT /servers/{server_id}/os-volume_attachments/{volume_id}
(swap volume) API is admin-only by default. This fixes the
documentation in the API reference.
Change-Id: I9e7fe40536cf5f03d97eb80fd4459b5a74e92f76
Related-Bug: #1522705 

When we update a volume attachment in nova api, we use volume_id instead
of attachment_id in params in latest api.
Change-Id: I5fc4d0ba3bb1c49dfaba2b2eed056441509cb9da

In the following APIs, the 'volume_id' parameters are
'path' parameters. So fix them.
- GET /servers/{server_id}/os-volume_attachments/{volume_id}
- DELETE /servers/{server_id}/os-volume_attachments/{volume_id}
In addition, the descriptions of the parameters are amended.
Change-Id: Iab93acde31639b1471c83b06fb1a77474bb52c48
Closes-Bug: #1770560 

This change introduces a new microversion which must be used
to create a server from a multiattach volume or attach a multiattach
volume to an existing server instance.
Attaching a multiattach volume to a shelved offloaded instance is not
supported since an instance in that state does not have a compute host
so we can't tell if the compute would support the multiattach volume
or not. This is consistent with the tagged attach validation with 2.49.
When creating a server from a multiattach volume, we'll check to see
if all computes in all cells are upgraded to the point of even supporting
the compute side changes, otherwise the server create request fails with
a 409. We do this because we don't know which compute node the scheduler
will pick and we don't have any compute capability filtering in the
scheduler for multiattach volumes (that may be a future improvement).
Similarly, when attaching a multiattach volume to an existing instance,
if the compute isn't new enough to support multiattach or the virt
driver simply doesn't support the capability, a 409 response is returned.
Presumably, operators will use AZs/aggregates to organize which hosts
support multiattach if they have a mixed hypervisor deployment, or will
simply disable multiattach support via Cinder policy.
The unit tests are covering error conditions with the new flow. A new
functional scenario test is added for happy path testing of the new boot
from multiattach volume flow and attaching a multiattach volume to more
than one instance.
Tempest integration testing for multiattach is added in change
I80c20914c03d7371e798ca3567c37307a0d54aaa.
Devstack support for multiattach is added in change
I46b7eabf6a28f230666f6933a087f73cb4408348.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Implements: blueprint multi-attach-volume
Change-Id: I02120ef8767c3f9c9497bff67101e57e204ed6f4

A swap on a stopped or suspended instance will fail silently. Remove
these allowed instance states on swap_volume:
suspended, stopped, soft_deleted
Change-Id: Iff17f7cee7a56037b35d1a361a0b3279d0a885d6
Closes-Bug: #1673090 

Now the code implementation for the api show and delete for
os-volume_attachments and the description of the document
does not match.
Change-Id: Ib15532d628713d771a835e9825a1c699a7ea4fcb

This patch adds microversion 2.49, which supports tagged attachment
of network interfaces and block devices.
Change-Id: I8d3bbe7e9a21d2694d10ee89628deb333e6b0487
Implements: blueprint virt-device-tagged-attach-detach

some api-ref have sentence like '..for a server instance'
which is inconsistent and confusing as we use server for VM terminology.
I think here 'instance' word is being considered object of server which
is wrong.
We should always mention server only.
part of bp:api-ref-in-rst-pike
Change-Id: I32afe56cfc66b34b76d1f7e1b507d3d5e722e6a1

The description of the volumeAttachment request parameter was actually
the description of the response parameter, which included more fields
than we allow on the POST and PUT requests for os-volume_attachments.
This fixes the descriptions for both POST and PUT and also includes a
tiny fix for the wording on the existing volumeAttachment parameter.
Change-Id: I4ccd4ac12e24b232925875fdb5fb568c2bfaf417
Closes-Bug: #1675536 

A number of endpoints enable pagination via 'limit' & 'offset' query
parameters, but don't document or test this functionality.
 - os-cells
 - os-security-groups
 - os-server-groups
 - os-snapshots
 - os-virtual-interfaces
 - os-volume-attachments
 - os-volumes
Change-Id: I5b0ad25f7282f4a13bbb6f21b76e986e1008936a

At first, the 'attachment_id_resp' in parameters.yaml was defined
as 'required' in I3789a4ad36e30728024f2aa122403b0e53b1e741
for os-volume_attachments.inc.
Then it was changed to 'optional' in
I0c1d183c5aaf6fb796be30fa5627bd5644ea689f
for os-volumes.inc.
So currently 'id' (attachment_id) parameters in
os-volume_attachments.inc are wrong.
They should be 'required'. So fix them.
Change-Id: I403a9eb1b08a840cbb2b82cb37f1b49c6edb87c9
Closes-Bug: #1608842 

This patch verifies that the title and introductory description 
that precedes each rest method clearly reflects the context of the 
respective rest method. Thus no changes are necessary - the
'body verification' tag is removed for this commit.
part of bp:api-ref-in-rst
Change-Id: I61cfdb5a0b8f8e1d8d60bd306c4952f2bc9ec537

v2.20 allows shelved and shelve_offload instance to attach and
detach volume, add descriptions for that
Implements: blueprint api-ref-in-rst-ocata
Change-Id: Ib1349c2ef9d69cfc74212fd48ff10f913a5ce134

As discussed at summit, the version part of the URL is not really
relevant, or a thing a user should be filling out themselves, this
should instead be set by the service catalog and extracted from the
token.
This removes it's reference in all documented REST urls, and adds a
new section describing how one gets the base URL for all calls.
Change-Id: I4306b8c3de0225e54f3909dd8a1fb293c4e5944c

Change-Id: I1f5ba0453b0dc964f48471e4aecaaaa800699da1
Implements: blueprint api-ref-in-rst

Change-Id: I3789a4ad36e30728024f2aa122403b0e53b1e741
Implements: blueprint api-ref-in-rst

Change-Id: I560908b28c1193622ee6e042322024fc6d0df5d6
Implements: blueprint api-ref-in-rst

This adds a set of tags in comments to the beginning of files so that
we can process them according to the documentation here:
https://wiki.openstack.org/wiki/NovaAPIRef
Part of bp:api-ref-in-rst
Change-Id: I17cf584dafb5bd969c12f51b7e7185d92365bf93

This is the results of the RST conversion from WADL. It creates a
single index plus a bunch of included files which represent sections
of the API document. This is the starting point for fixing the
documentation.
Change-Id: I7d561c2ecdcd864172dedb54a551f17ad3bdfe26