<div dir="ltr">What decision would lead the user to request AZ1 and AZ2 in the first place? Especially since when it fails to get AZ2, they just request again with AZ1 and AZ3 instead.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 10:31 PM, Hirofumi Ichihara <span dir="ltr"><<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <div>On 2015/12/14 14:52, Kevin Benton
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">I see, so regular users are supposed to use this
        information as well. But how are they supposed to use it? For
        example, if they see that their network has availability zones 1
        and 4, but their instance is hosted in zone 3, what are they
        supposed to do?</div>
    </blockquote></span>
    I don't think that there is what they should do in the case because
    Neutron AZ is different from Nova AZ. For example, there may be a
    case like the following.<br>
    <br>
    1. User throws POST Network API and Subnet API with
    availability_zone_hints [AZ1, AZ2]<br>
    2. Neutron server tries to schedule the resource on both AZ1 and AZ2
    but the resource are scheduled on AZ1 only by some reasons<br>
    3. User confirms via GET Network API where his resource is hosted
    and he knows it's AZ1 only<br>
    4. User also can know AZ is ready via GET Availability zones API:
    AZ1, AZ3<br>
    5. User deletes previous resource and he recreates his resource with
    availability_zone_hints [AZ1, AZ3]<div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sun, Dec 13, 2015 at 8:57 PM,
          Hirofumi Ichihara <span dir="ltr"><<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank"></a><a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.jp</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> Hi Kevin,<span><br>
                <br>
                <div>On 2015/12/14 11:10, Kevin Benton wrote:<br>
                </div>
                <blockquote type="cite">
                  <div dir="ltr">Hi all,
                    <div><br>
                    </div>
                    <div>The availability zone code added a new field to
                      the network API that shows the availability zones
                      of a network. This caused a pretty big performance
                      impact to get_networks calls because it resulted
                      in a database lookup for every network.[1]</div>
                    <div><br>
                    </div>
                    <div>I already put a patch up to join the
                      information ahead of time in the network model.[2]</div>
                  </div>
                </blockquote>
              </span> I agree with your suggestion. I believe that the
              patch can solve the performance issue.<span><br>
                <br>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div> However, before we go forward with that, I
                      think we should consider the removal of that field
                      from the API. </div>
                    <div><br>
                    </div>
                    <div>Having to always join to the DHCP agents table
                      to lookup which zones a network has DHCP agents on
                      is expensive and is duplicating information
                      available with other API calls. <br>
                    </div>
                    <div><br>
                    </div>
                    <div>Additionally, the field is just called
                      'availability_zones' but it's being derived solely
                      from AZ definitions in DHCP agent bindings for
                      that network. To me that doesn't represent where
                      the network is available, it just says which zones
                      its scheduled DHCP instances live in. If that's
                      the purpose, then we should just be using the DHCP
                      agent API for this info and not impact the network
                      API. <br>
                    </div>
                  </div>
                </blockquote>
              </span> I don't think so. I have three points.<br>
              <br>
              1. Availability zone is implemented in just a case with
              Agent now, but it's reference implementation. For example,
              we should expect that availability zone will be used by
              plugin without agent.<br>
              <br>
              2. In users view, availability zone is related to network
              resource. On the other hand, users doesn't need to
              consider Agent or operators doesn't like to enable users
              to do in the first place. So I don't agree with using
              Agent API.<br>
              <br>
              3. We should consider whether users want to know the
              field. Originally, the field doesn't exist in Spec[3] but
              I added it according with reviewer's opinion(maybe
              Akihiro?). This is about discussion of use case. After
              users create resources via API with
              availability_zone_hints so that they achieve HA for their
              service, they want to know which zones are their resources
              hosted on because their resources might not be distributed
              on multiple availability zones by any reasons. In the
              case, they need to know "availability_zones" for the
              resources via Network API.<br>
              <br>
              Thanks,<br>
              Hirofumi<br>
              <br>
              [3]: <a href="https://review.openstack.org/#/c/169612/31" target="_blank">https://review.openstack.org/#/c/169612/31</a><br>
              <br>
              <blockquote type="cite"><span>
                  <div dir="ltr">
                    <div><br>
                    </div>
                    <div>Thoughts?</div>
                    <div><br>
                    </div>
                    <div>1. <a href="https://bugs.launchpad.net/neutron/+bug/1525740" target="_blank">https://bugs.launchpad.net/neutron/+bug/1525740</a></div>
                    <div>2. <a href="https://review.openstack.org/#/c/257086/" target="_blank">https://review.openstack.org/#/c/257086/</a><br clear="all">
                      <div><br>
                      </div>
                      -- <br>
                      <div>
                        <div>Kevin Benton</div>
                      </div>
                    </div>
                  </div>
                  <br>
                  <fieldset></fieldset>
                  <br>
                </span>
                <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
              </blockquote>
              <br>
            </div>
            <br>
__________________________________________________________________________<br>
            OpenStack Development Mailing List (not for usage questions)<br>
            Unsubscribe: <a 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 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>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div>
          <div>Kevin Benton</div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>