Open Stack

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.





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


      Thoughts?

      1. https://bugs.launchpad.net/neutron/+bug/1525740
      2. 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
      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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151214/42742c68/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/20151214/42742c68/attachment.gif>