[openstack-dev] [nova] Find out the instance availability zone before creating volume.

Jiri Suchomel jsuchome at suse.cz
Fri May 20 06:49:00 UTC 2016


Hi all,

it's a long time since I have opened proposal to fix bug
https://bugs.launchpad.net/nova/+bug/1497253 "different availability
zone for nova and cinder when AZ is not explicitly given". I know the
solution is controversial, but could anyone interested give a look?

To summarize what's the situation and proposed solution about:

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...."

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.


Jiri
-- 
Jiri Suchomel

SUSE LINUX, s.r.o.
Lihovarská 1060/12
tel: +420 284 028 960
190 00 Praha 9, Czech Republic                http://www.suse.cz



More information about the OpenStack-dev mailing list