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.hirof...@lab.ntt.co.jp
<mailto:ichihara.hirof...@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-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
