Open Stack

On 09/23/15 at 02:55pm, Matt Riedemann wrote:
>
>
>On 9/23/2015 2:45 PM, John Griffith wrote:
>>
>>
>>On Wed, Sep 23, 2015 at 1:34 PM, Matt Riedemann
>><mriedem at linux.vnet.ibm.com <mailto: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>
>>            <mailto: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://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://OpenStack-dev-request@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://OpenStack-dev-request@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
>>
>>
>>__________________________________________________________________________
>>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
>>
>
>Heh, so when I just asked in the cinder channel if we can just 
>deprecate nova boot from volume with source=(image|snapshot|blank) 
>(which automatically creates the volume and polls for it to be 
>available) and then add a microversion that doesn't allow it, I was 
>half joking, but I see we're on the same page.  This scenario seems 
>to introduce a lot of orchestration work that nova shouldn't 
>necessarily be in the business of handling.

I am very much in support of this.  This has been a source of 
frustration for our users because it is prone to failures we can't 
properly expose to users and timeouts.  There are much better places to 
handle the orchestration of creating a volume and then booting from it 
than Nova.

>
>-- 
>
>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