<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">Le 23/09/2015 21:45, John Griffith a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAPWkaSWUues-yeOkr7bVX75F=AL_5j6eJMA9+qQcZLQ8nD2_yg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_default"
          style="font-family:monospace,monospace"><br>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Sep 23, 2015 at 1:34 PM, Matt
            Riedemann <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="HOEnZb">
                <div class="h5"><br>
                  <br>
                  On 9/23/2015 2:15 PM, Matt Riedemann wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <br>
                    <br>
                    On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      Hi Matt,<br>
                      <br>
                      In Liberty, we introduced
                      allow_availability_zone_fallback [1] option in<br>
                      Cinder config as fix for bug [2]. If you set this
                      option, Cinder will<br>
                      create volume in a default AZ instead of set
                      volume into the error state<br>
                      <br>
                      [1]<br>
                      <a moz-do-not-send="true"
href="https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31"
                        rel="noreferrer" target="_blank">https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31</a><br>
                      <br>
                      [2] <a moz-do-not-send="true"
                        href="https://bugs.launchpad.net/cinder/+bug/1489575"
                        rel="noreferrer" target="_blank">https://bugs.launchpad.net/cinder/+bug/1489575</a><br>
                      <br>
                      Regards,<br>
                      Ivan Kolodyazhny<br>
                      <br>
                      On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann<br>
                      <<a moz-do-not-send="true"
                        href="mailto:mriedem@linux.vnet.ibm.com"
                        target="_blank">mriedem@linux.vnet.ibm.com</a>
                      <mailto:<a moz-do-not-send="true"
                        href="mailto:mriedem@linux.vnet.ibm.com"
                        target="_blank">mriedem@linux.vnet.ibm.com</a>>>
                      wrote:<br>
                      <br>
                          I came across bug 1496235 [1] today.  In this
                      case the user is<br>
                          booting an instance from a volume using
                      source=image, so nova<br>
                          actually does the volume create call to the
                      volume API.  They are<br>
                          booting the instance into a valid nova
                      availability zone, but that<br>
                          same AZ isn't defined in Cinder, so the volume
                      create request fails<br>
                          (since nova passes the instance AZ to cinder
                      [2]).<br>
                      <br>
                          I marked this as invalid given how the code
                      works.<br>
                      <br>
                          I'm posting here since I'm wondering if there
                      are alternatives worth<br>
                          pursuing.  For example, nova could get the
                      list of AZs from the<br>
                          volume API and if the nova AZ isn't in that
                      list, don't provide it<br>
                          on the volume create request.  That's
                      essentially the same as first<br>
                          creating the volume outside of nova and not
                      specifying an AZ, then<br>
                          when doing the boot from volume, provide the
                      volume_id as the source.<br>
                      <br>
                          The question is, is it worth doing that?  I'm
                      not familiar enough<br>
                          with how availability zones are meant to work
                      between nova and<br>
                          cinder so it's hard for me to have much of an
                      opinion here.<br>
                      <br>
                          [1] <a moz-do-not-send="true"
                        href="https://bugs.launchpad.net/nova/+bug/1496235"
                        rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1496235</a><br>
                          [2]<br>
                      <br>
                      <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383"
                        rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383</a><br>
                      <br>
                      <br>
                          --<br>
                      <br>
                          Thanks,<br>
                      <br>
                          Matt Riedemann<br>
                      <br>
                      <br>
                      <br>
__________________________________________________________________________<br>
                      <br>
                          OpenStack Development Mailing List (not for
                      usage questions)<br>
                          Unsubscribe:<br>
                          <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                        rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                      <br>
                      <<a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                        rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
                          <a moz-do-not-send="true"
                        href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                        rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                      <br>
                      <br>
                      <br>
                      <br>
__________________________________________________________________________<br>
                      <br>
                      OpenStack Development Mailing List (not for usage
                      questions)<br>
                      Unsubscribe:<br>
                      <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                        rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                      <a moz-do-not-send="true"
                        href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                        rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                      <br>
                    </blockquote>
                    <br>
                    Sorry but that seems like a hack.<br>
                    <br>
                    I'm trying to figure out the relationship between
                    AZs in nova and cinder<br>
                    and so far no one seems to really know.  In the
                    cinder IRC channel I was<br>
                    told there isn't one, which would mean we shouldn't
                    even try creating<br>
                    the volume using the server instance AZ.<br>
                    <br>
                    Also, if there is no relationship, I was trying to
                    figure out why there<br>
                    is the cinder.cross_az_attach config option.  That
                    was added in grizzly<br>
                    [1].  I was thinking maybe it was a legacy artifact
                    from nova-volume,<br>
                    but that was dropped in grizzly.<br>
                    <br>
                    So is cinder.cross_az_attach even useful?<br>
                    <br>
                    [1] <a moz-do-not-send="true"
                      href="https://review.openstack.org/#/c/21672/"
                      rel="noreferrer" target="_blank">https://review.openstack.org/#/c/21672/</a><br>
                    <br>
                  </blockquote>
                  <br>
                </div>
              </div>
              The plot thickens.<br>
              <br>
              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.<br>
              <br>
              So I guess we can't just stop passing the instance az to
              the volume create call.<br>
              <br>
              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?<br>
              <br>
              [1] <a moz-do-not-send="true"
                href="https://review.openstack.org/#/c/157041/"
                rel="noreferrer" target="_blank">https://review.openstack.org/#/c/157041/</a>
              <div class="HOEnZb">
                <div class="h5"><br>
                  <br>
                  -- <br>
                  <br>
                  Thanks,<br>
                  <br>
                  Matt Riedemann<br>
                  <br>
                  <br>
__________________________________________________________________________<br>
                  OpenStack Development Mailing List (not for usage
                  questions)<br>
                  Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                    rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                  <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">​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.</div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">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).</div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">My opinion would be
            until somebody proposes a clear use case and need that
            actually works that we consider deprecating it. </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Given what are currently AZs in Nova (explicit user-visible
    aggregates of compute nodes, see [1]), I tend to say that there is
    no reason to provide the AZ information to Cinder because AZs are
    not failure domains, just very specific placement information used
    for scheduling instances.<br>
    <br>
    Based on some conversation we had on IRC, MHO is that we should at
    least deprecate the config flag that Matt discussed above and we
    should also plan to remove the AZ information from the Cinder call
    we do in Nova when creating a volume.<br>
    <br>
    I leave Cinder community to discuss the plans about having AZs or
    not, but I also think that any reboot of the idea could necessarly
    need a renaming and no longer use the "availability zone" wording.<br>
    <br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs">http://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs</a><br>
    <br>
    <blockquote
cite="mid:CAPWkaSWUues-yeOkr7bVX75F=AL_5j6eJMA9+qQcZLQ8nD2_yg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_default"
            style="font-family:monospace,monospace">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.</div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">We do have a
            proposal to talk about this at the Summit, so maybe we'll
            have a descent primer before we get there :)</div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">Thanks,</div>
          <div class="gmail_default"
            style="font-family:monospace,monospace"><br>
          </div>
          <div class="gmail_default"
            style="font-family:monospace,monospace">John</div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>