On 9/23/2015 2:15 PM, Matt Riedemann wrote:
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:
Hi Matt,
In Liberty, we introduced allow_availability_zone_fallback [1] option in
Cinder config as fix for bug [2]. If you set this option, Cinder will
create volume in a default AZ instead of set volume into the error state
[1]
https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31
[2] https://bugs.launchpad.net/cinder/+bug/1489575
Regards,
Ivan Kolodyazhny
On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann
<mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote:
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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
Sorry but that seems like a hack.
I'm trying to figure out the relationship between AZs in nova and cinder
and so far no one seems to really know. In the cinder IRC channel I was
told there isn't one, which would mean we shouldn't even try creating
the volume using the server instance AZ.
Also, if there is no relationship, I was trying to figure out why there
is the cinder.cross_az_attach config option. That was added in grizzly
[1]. I was thinking maybe it was a legacy artifact from nova-volume,
but that was dropped in grizzly.
So is cinder.cross_az_attach even useful?
[1] https://review.openstack.org/#/c/21672/
The plot thickens.
I was checking to see what change was made to start passing the server
instance az on the volume create call during boot from volume, and that
was [1] which was added in kilo to fix a bug where boot from volume into
a nova az will fail if cinder.cross_az_attach=False and
storage_availability_zone is set in cinder.conf.
So I guess we can't just stop passing the instance az to the volume
create call.
But what I'd really like to know is how this is all used between cinder
and nova, or was this all some work done as part of a larger effort that
was never completed? Basically, can we deprecate the
cinder.cross_az_attach config option in nova and start decoupling this code?
[1] https://review.openstack.org/#/c/157041/
--
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
