Open Stack

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).

On Sun, Dec 13, 2015 at 9:53 PM, Hong Hui Xiao <xiaohhui at cn.ibm.com> wrote:

> Hi,
>
> Can we just add "availability_zones" 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.
>
>
>
> [image: Inactive hide details for Hirofumi Ichihara ---12/14/2015
> 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin Benton wrote:]Hirofumi
> Ichihara ---12/14/2015 13:33:41---Hi Kevin, On 2015/12/14 11:10, Kevin
> Benton wrote:
>
> From: Hirofumi Ichihara <ichihara.hirofumi at lab.ntt.co.jp>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: 12/14/2015 13:33
> Subject: Re: [openstack-dev] [neutron] - availability zone performance
> regression and discussion about added network field
> ------------------------------
>
>
>
> Hi Kevin,
>
> On 2015/12/14 11:10, Kevin Benton wrote:
>
>    Hi all,
>
>       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]
>
>       I already put a patch up to join the information ahead of time in
>       the network model.[2]
>
> I agree with your suggestion. I believe that the patch can solve the
> performance issue.
>
>    However, before we go forward with that, I think we should consider
>       the removal of that field from the API.
>
>       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.
>
>       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.
>
> I don't think so. I have three points.
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> Hirofumi
>
> [3]: *https://review.openstack.org/#/c/169612/31*
> <https://review.openstack.org/#/c/169612/31>
>
>
>       Thoughts?
>
>       1. *https://bugs.launchpad.net/neutron/+bug/1525740*
>       <https://bugs.launchpad.net/neutron/+bug/1525740>
>       2. *https://review.openstack.org/#/c/257086/*
>       <https://review.openstack.org/#/c/257086/>
>
>       --
>       Kevin Benton
>
>
>
>       __________________________________________________________________________
>       OpenStack Development Mailing List (not for usage questions)
>       Unsubscribe:
>       *OpenStack-dev-request at lists.openstack.org?subject:unsubscribe*
>       <OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>       *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
>       <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151213/06f16460/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151213/06f16460/attachment.gif>