And reading the help on that, it sounds like we maybe regressed some functionality / contract in Pike, see:
"None, which means that the instance can move from one availability zone to another during its lifetime if it is moved from one compute node to another."
So I think that means before Pike, I could create an instance without a specific AZ and then the operator could live migrate it to any other compute node regardless of AZ, but after Pike the operator can only live migrate the instance to a compute node in the same AZ, which is a regression. It should be fairly easy to reproduce this with an in-tree functional test that has 2 compute nodes in separate AZs, create an instance w/o a specific AZ, and then try to live migrate the instance - if that works in Ocata but not after Ocata, it's a regression.
So before that change in Pike, the instance. availability_ zone was set to CONF.default_ availability_ zone which defaults to None:
https:/ /docs.openstack .org/nova/ pike/configurat ion/config. html#DEFAULT. default_ schedule_ zone
And reading the help on that, it sounds like we maybe regressed some functionality / contract in Pike, see:
"None, which means that the instance can move from one availability zone to another during its lifetime if it is moved from one compute node to another."
So I think that means before Pike, I could create an instance without a specific AZ and then the operator could live migrate it to any other compute node regardless of AZ, but after Pike the operator can only live migrate the instance to a compute node in the same AZ, which is a regression. It should be fairly easy to reproduce this with an in-tree functional test that has 2 compute nodes in separate AZs, create an instance w/o a specific AZ, and then try to live migrate the instance - if that works in Ocata but not after Ocata, it's a regression.