7e6ae9afd9
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
33 lines
1.6 KiB
YAML
33 lines
1.6 KiB
YAML
---
|
|
features:
|
|
- |
|
|
This release adds support to attach a volume to multiple
|
|
server instances. The feature can only be used in Nova if the
|
|
volume is created in Cinder with the **multiattach** flag set
|
|
to True. It is the responsibility of the user to use a
|
|
proper filesystem in the guest that supports shared read/write access.
|
|
|
|
This feature is currently only supported by the libvirt compute driver
|
|
and only then if qemu<2.10 or libvirt>3.10 on the compute host.
|
|
|
|
API restrictions:
|
|
|
|
* Compute API microversion 2.60 must be used to create a server from
|
|
a multiattach volume or to attach a multiattach volume to an existing
|
|
server instance.
|
|
* When creating a server using a multiattach volume, the API will check
|
|
if the compute services have all been upgraded to a minimum level of
|
|
support and will fail with a 409 HTTPConflict response if the computes
|
|
are not yet upgraded.
|
|
* Attaching a multiattach volume to a shelved offloaded instance is not
|
|
supported and will result in a 400 HTTPBadRequest response.
|
|
* Attaching a multiattach volume to an existing server instance will check
|
|
that the compute hosting that instance is new enough to support it and
|
|
has the capability to support it. If the compute cannot support the
|
|
multiattach volume, a 409 HTTPConflict response is returned.
|
|
|
|
See the `Cinder enable multiattach`_ spec for details on configuring
|
|
Cinder for multiattach support.
|
|
|
|
.. _Cinder enable multiattach: https://specs.openstack.org/openstack/cinder-specs/specs/queens/enable-multiattach.html
|