nova/releasenotes/notes/bug-1694844-cross-az-attach-ab1f05e8693f6902.yaml
Matt Riedemann 07a24dcef7 Default AZ for instance if cross_az_attach=False and checking from API
If we're booting from an existing volume but the instance is not being
created in a requested availability zone, and cross_az_attach=False,
we'll fail with a 400 since by default the volume is in the 'nova'
AZ and the instance does not have an AZ set - because one wasn't requested
and because it's not in a host aggregate yet.

This refactors that AZ validation during server create in the API to
do it before calling _validate_bdm so we get the pre-existing volumes
early and if cross_az_attach=False, we validate the volume zone(s) against
the instance AZ. If the [DEFAULT]/default_schedule_zone (for instances) is
not set and the volume AZ does not match the
[DEFAULT]/default_availability_zone then we put the volume AZ in the request
spec as if the user requested that AZ when creating the server.

Since this is a change in how cross_az_attach is used and how the instance
default AZ works when using BDMs for pre-existing volumes, the docs are
updated and a release note is added.

Note that not all of the API code paths are unit tested because the
functional test coverage does most of the heavy lifting for coverage.
Given the amount of unit tests that are impacted by this change, it is
pretty obvious that (1) many unit tests are mocking at too low a level and
(2) functional tests are better for validating these flows.

Closes-Bug: #1694844

Change-Id: Ib31ba2cbff0ebb22503172d8801b6e0c3d2aa68a
2019-10-31 10:08:46 -04:00

19 lines
791 B
YAML

---
fixes:
- |
Long standing `bug 1694844`_ is now fixed where the following conditions
would lead to a 400 error response during server create:
* ``[cinder]/cross_az_attach=False``
* ``[DEFAULT]/default_schedule_zone=None``
* A server is created without an availability zone specified but with
pre-existing volume block device mappings
Before the bug was fixed, users would have to specify an availability zone
that matches the zone that the volume(s) were in. With the fix, the compute
API will implicitly create the server in the zone that the volume(s) are
in as long as the volume zone is not the same as the
``[DEFAULT]/default_availability_zone`` value (defaults to ``nova``).
.. _bug 1694844: https://launchpad.net/bugs/1694844