<div dir="ltr">What will the availability zones API tell the user about the zones? Are they just opaque strings that the user doesn't really understand? <div><br></div><div>What I'm a little worried about is that it seems like we are having the user doing the work of the scheduler.</div><div><br></div><div>Is this is for getting affinity or anti-affinity with resources for another network? If so, why not just have the user explicitly say in the API request 'anti-affinity=network_id' or 'affinity=network_id'. Then the scheduler would use the zones info to either place resources on a different zone or the same zone, depending on which was requested.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 11:25 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 15:58, Kevin Benton
wrote:<br>
</div>
<blockquote type="cite">
<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>
</blockquote></span>
I expected that user gets AZ1 and AZ2 (and AZ3) via GET Availability
zones API first. There is a gap between the time user threw and the
time his resource is scheduled. After user threw API request with
AZ1 and AZ2, if all agents of AZ2 are dead before scheduling, the
resource is scheduled in AZ1 only.<div><div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<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"></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"><span> <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><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>
<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>