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 <[email protected]> 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 <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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: > *[email protected]?subject:unsubscribe* > <[email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
