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> 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:unsubscribehttp://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://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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev