I should have been more clear in the bug report, so here's another attempt:
1. User has cinder AZ's and nova AZ of the same names
2. AZ's physical location is different, and user wants instances to have same AZ as their volumes
3. This is generally achieved by setting cross_az_attach option to False, because since https://review.openstack.org/#/c/157041/ volumes are created in the same AZ as instances.
4. However, what if user doesn't explicitly provide AZ when creating the instance (so the scheduler can distribute the load evenly and according to available resources)?
This is the situation possibly requiring a fix. In such case, nova uses the None value for availability zone at the time it calls volume_api.create. Cinder creates the volume in some AZ it has available, and when nova finishes creating the instance it creates it in some of its available AZ. There's no relation between these two, so if they end up being different, we'll hit the error " Instance %(instance)s and volume %(vol)s are not in the same availability_zone...."
- if cross_az_attach is set to false, nova should ensure cinder and nova AZ's are matching, AND it should make sure this rule is true also in the case when AZ was not specified by user. Thus I propose to look for instance's real AZ BEFORE actually trying to create the volume, and use this value also for volume.
I should have been more clear in the bug report, so here's another attempt:
1. User has cinder AZ's and nova AZ of the same names
2. AZ's physical location is different, and user wants instances to have same AZ as their volumes
3. This is generally achieved by setting cross_az_attach option to False, because since /review. openstack. org/#/c/ 157041/ volumes are created in the same AZ as instances.
https:/
4. However, what if user doesn't explicitly provide AZ when creating the instance (so the scheduler can distribute the load evenly and according to available resources)? zone... ."
This is the situation possibly requiring a fix. In such case, nova uses the None value for availability zone at the time it calls volume_api.create. Cinder creates the volume in some AZ it has available, and when nova finishes creating the instance it creates it in some of its available AZ. There's no relation between these two, so if they end up being different, we'll hit the error " Instance %(instance)s and volume %(vol)s are not in the same availability_
So, my proposal (as expressed in https:/ /review. openstack. org/225119) is that:
- if cross_az_attach is set to false, nova should ensure cinder and nova AZ's are matching, AND it should make sure this rule is true also in the case when AZ was not specified by user. Thus I propose to look for instance's real AZ BEFORE actually trying to create the volume, and use this value also for volume.