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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
