<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><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">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 class=""><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 class=""><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 class="">
      <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 class="gmail_signature"><div>Kevin Benton</div></div>
</div>