Open Stack

On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> 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
>>> <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/
>>
>>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
​To be honest this is probably my fault, AZ's were pulled in as part of the
nova-volume migration to Cinder and just sort of died.  Quite frankly I
wasn't sure "what" to do with them but brought over the concept and the
zones that existing in Nova-Volume.  It's been an issue since day 1 of
Cinder, and as you note there are little hacks here and there over the
years to do different things.

I think your question about whether they should be there at all or not is a
good one.  We have had some interest from folks lately that want to couple
Nova and Cinder AZ's (I'm really not sure of any details or use-cases here).

My opinion would be until somebody proposes a clear use case and need that
actually works that we consider deprecating it.

While we're on the subject (kinda) I've never been a very fond of having
Nova create the volume during boot process either; there's a number of
things that go wrong here (timeouts almost guaranteed for a "real" image)
and some things that are missing last I looked like type selection etc.

We do have a proposal to talk about this at the Summit, so maybe we'll have
a descent primer before we get there :)

Thanks,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150923/8f12cafc/attachment.html>