<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 December 2015 at 23:01, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, as I'm starting to understand the use case, I think it would actually make more sense to add an AZ-network mapping table. Then whatever implementation can populate them based on the criteria it is using (reference would just do it on agent updates).</div></blockquote><div><br></div><div>I guess this would be leading to have AZ being first class (ie. being in a table of its own) and associate it 1-N to agents and N-M to networks. It might not be worth going down this path for killing the performance penalty introduced by this feature, though it might be worth considering the model change to accommodate other features where we could extend the grouping to other resources like L2.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 9:53 PM, Hong Hui Xiao <span dir="ltr"><<a href="mailto:xiaohhui@cn.ibm.com" target="_blank">xiaohhui@cn.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 bgcolor="#FFFFFF"><p>Hi,<br><br> Can we just add "<font size="4">availability_zones</font>" as one Column in Network? And update it when "NetworkDhcpAgentBinding" updates. The code will be a bit more complex, but it can save the time when retrieving Network resource.<br><font size="4"> </font><br><br><br><img width="16" height="16" src="cid:1__=8FBBF588DF8C38198f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Hirofumi Ichihara ---12/14/2015 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin Benton wrote:"><font color="#424282">Hirofumi Ichihara ---12/14/2015 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin Benton wrote:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Hirofumi Ichihara <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp" target="_blank">ichihara.hirofumi@lab.ntt.co.jp</a>></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">12/14/2015 13:33</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [neutron] - availability zone performance regression and discussion about added network field</font><br></p><hr width="100%" size="2" align="left" noshade style="color:#8091a5"><div><div><br><br><br><font size="4">Hi Kevin,<br></font><br><font size="4">On 2015/12/14 11:10, Kevin Benton wrote:</font><ul><ul><font size="4">Hi all, </font><br><br><font size="4">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]</font><br><br><font size="4">I already put a patch up to join the information ahead of time in the network model.[2]</font></ul></ul><font size="4">I agree with your suggestion. I believe that the patch can solve the performance issue.<br></font><ul><ul><font size="4">However, before we go forward with that, I think we should consider the removal of that field from the API. </font><br><br><font size="4">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. </font><br><br><font size="4">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. </font></ul></ul><font size="4">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]: </font><a href="https://review.openstack.org/#/c/169612/31" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/169612/31</font></u></a><font size="4"><br></font><ul><ul><br><font size="4">Thoughts?</font><br><br><font size="4">1. </font><a href="https://bugs.launchpad.net/neutron/+bug/1525740" target="_blank"><u><font size="4" color="#0000FF">https://bugs.launchpad.net/neutron/+bug/1525740</font></u></a><br><font size="4">2. </font><a href="https://review.openstack.org/#/c/257086/" target="_blank"><u><font size="4" color="#0000FF">https://review.openstack.org/#/c/257086/</font></u></a><br><br><font size="4">-- </font><br><font size="4">Kevin Benton</font><br><font size="4"><br></font><br><tt><font size="4">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font></tt><a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><tt><u><font size="4" color="#0000FF">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></u></tt></a><tt><font size="4"><br></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><u><font size="4" color="#0000FF">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></tt></a><tt><font size="4"><br></font></tt></ul></ul><tt>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></tt><tt><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></tt><tt><br></tt><br><br>
</div></div><p></p></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></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></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></div></div>