<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2015/12/16 17:16, Kevin Benton
wrote:<br>
</div>
<blockquote
cite="mid:CAO_F6JPrU0eZxJ4rJpbDZLxjMmE+=30mMK5XNUiMg3856SZf2Q@mail.gmail.com"
type="cite">
<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? <br>
</div>
</blockquote>
They shows available zones in the time.<br>
<br>
<blockquote
cite="mid:CAO_F6JPrU0eZxJ4rJpbDZLxjMmE+=30mMK5XNUiMg3856SZf2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
I understand your worry. However, I think that AZ feature includes a
use case that users can specify zone which their resource is
scheduled. <br>
<br>
<blockquote
cite="mid:CAO_F6JPrU0eZxJ4rJpbDZLxjMmE+=30mMK5XNUiMg3856SZf2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
I like it. But we may have other issues, for example, <br>
<br>
1. We have NW1(with anti-affinity=NW2) and NW2(with
anti-affinity=NW1)<br>
2. We delete NW1 and then create NW3(with anti-affinity=NW2) instead
of NW1<br>
3. NW2(with anti-affinity=NW1) is rescheduled because of some
reasons<br>
4. Neutron cannot find NW1 in anti-affinit of NW2. How does neutron
also schedule NW2 to a zone which doesn't have NW3?<br>
<br>
Of course, we can find a way of solving this issue itself. But the
similar issue may happen.<br>
<br>
I think that we must remove the filed if it always happens
performance issue.<br>
However, we should find out another solution for the issue as long
as there are use cases that are needed by operators and users.<br>
<br>
<blockquote
cite="mid:CAO_F6JPrU0eZxJ4rJpbDZLxjMmE+=30mMK5XNUiMg3856SZf2Q@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Sun, Dec 13, 2015 at 11:25 PM,
Hirofumi Ichihara <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ichihara.hirofumi@lab.ntt.co.jp"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</a></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
moz-do-not-send="true"
href="mailto:ichihara.hirofumi@lab.ntt.co.jp"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</a></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
moz-do-not-send="true"
href="mailto:ichihara.hirofumi@lab.ntt.co.jp"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</a></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
moz-do-not-send="true"
href="https://review.openstack.org/#/c/169612/31"
target="_blank"><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/169612/31">https://review.openstack.org/#/c/169612/31</a></a><br>
<br>
<blockquote type="cite"><span>
<div dir="ltr">
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>1. <a
moz-do-not-send="true"
href="https://bugs.launchpad.net/neutron/+bug/1525740" target="_blank"><a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/neutron/+bug/1525740">https://bugs.launchpad.net/neutron/+bug/1525740</a></a></div>
<div>2. <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/257086/" target="_blank"><a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/257086/">https://review.openstack.org/#/c/257086/</a></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 moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" 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
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank"><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><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>
</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 moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" 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 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>
</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 moz-do-not-send="true" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" 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 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>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div>Kevin Benton</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>