Open Stack

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
> <mriedem at linux.vnet.ibm.com <mailto:mriedem at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at 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/

-- 

Thanks,

Matt Riedemann