Open Stack

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?

On Sun, Dec 13, 2015 at 8:57 PM, Hirofumi Ichihara <
ichihara.hirofumi at lab.ntt.co.jp> wrote:

> 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:unsubscribehttp://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/b3785bba/attachment.html>