commit 07a24dcef7ce6767b4b5bab0c8d3166cbe5b39c0
Author: Matt Riedemann <email address hidden>
Date: Tue Oct 8 18:01:44 2019 -0400
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.
Reviewed: https:/ /review. opendev. org/469675 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=07a24dcef7c e6767b4b5bab0c8 d3166cbe5b39c0
Committed: https:/
Submitter: Zuul
Branch: master
commit 07a24dcef7ce676 7b4b5bab0c8d316 6cbe5b39c0
Author: Matt Riedemann <email address hidden>
Date: Tue Oct 8 18:01:44 2019 -0400
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 attach= False,
created in a requested availability zone, and cross_az_
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 attach= False, we validate the volume zone(s) against /default_ schedule_ zone (for instances) is /default_ availability_ zone then we put the volume AZ in the request
do it before calling _validate_bdm so we get the pre-existing volumes
early and if cross_az_
the instance AZ. If the [DEFAULT]
not set and the volume AZ does not match the
[DEFAULT]
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: Ib31ba2cbff0ebb 22503172d8801b6 e0c3d2aa68a