[openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

Matt Riedemann mriedem at linux.vnet.ibm.com
Wed Sep 23 18:00:53 UTC 2015


I came across bug 1496235 [1] today.  In this case the user is booting 
an instance from a volume using source=image, so nova actually does the 
volume create call to the volume API.  They are booting the instance 
into a valid nova availability zone, but that same AZ isn't defined in 
Cinder, so the volume create request fails (since nova passes the 
instance AZ to cinder [2]).

I marked this as invalid given how the code works.

I'm posting here since I'm wondering if there are alternatives worth 
pursuing.  For example, nova could get the list of AZs from the volume 
API and if the nova AZ isn't in that list, don't provide it on the 
volume create request.  That's essentially the same as first creating 
the volume outside of nova and not specifying an AZ, then when doing the 
boot from volume, provide the volume_id as the source.

The question is, is it worth doing that?  I'm not familiar enough with 
how availability zones are meant to work between nova and cinder so it's 
hard for me to have much of an opinion here.

[1] https://bugs.launchpad.net/nova/+bug/1496235
[2] 
https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list