So what's probably happening is since this is a single-compute environment, we have a test running concurrently that creates an AZ for the single compute in test A and when test_list_migrations_in_flavor_resize_situation runs, the instance from test_list_migrations_in_flavor_resize_situation lands on the single compute which is in the AZ from test A. When test A cleans up, it removes the AZ. When the instance from test_list_migrations_in_flavor_resize_situation is moved, it has the now deleted AZ associated with it and the scheduler fails to find another compute in the same AZ (because that AZ is now gone).
The current thinking is that https:/ /github. com/openstack/ nova/commit/ 03b4c67b22f49d3 25386bc3ebd2ade 79b44fa699 might be contributing because an AZ is set on the instance from the compute it lands on whether or not the user asked for an AZ.
So what's probably happening is since this is a single-compute environment, we have a test running concurrently that creates an AZ for the single compute in test A and when test_list_ migrations_ in_flavor_ resize_ situation runs, the instance from test_list_ migrations_ in_flavor_ resize_ situation lands on the single compute which is in the AZ from test A. When test A cleans up, it removes the AZ. When the instance from test_list_ migrations_ in_flavor_ resize_ situation is moved, it has the now deleted AZ associated with it and the scheduler fails to find another compute in the same AZ (because that AZ is now gone).