yahoo-eng-team team mailing list archive

[OpenStack Infra <1649317@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/408143
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3ffe006743b33f48bca6fce541e0a8f64f844fb7
Submitter: Jenkins
Branch:    master

commit 3ffe006743b33f48bca6fce541e0a8f64f844fb7
Author: Kevin Benton <kevin@xxxxxxxxxx>
Date:   Mon Jan 9 05:02:42 2017 -0800

    Switch to 'subquery' for 1-M relationships
    
    This switches to the use of subqueries for 1-m relationships
    which will result in a higher constant query factor but will
    eliminate the potential for cross-product explosions.
    
    Closes-Bug: #1649317
    Change-Id: I6952c48236153a8e2f2f155375b70573ddc2cf0f


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1649317

Title:
  Combinatorial blow-up with the Alchemy strategy lazy='joined'

Status in neutron:
  Fix Released

Bug description:
  A regular tenant can create objects that will require a lot of time to
  enumerate because of the strategy used by the ORM to build back the
  objects from the different tables in the database.

  The script attached can be used to reproduce the problem. It creates a
  network with several subnetworks (with several routes and DNS
  servers), several tags, several RBAC policies but it does not exceed
  any typical quota. Because the network is retrieved at each stage it
  is modified, it is hard to run this script until its end in a typical
  setup.

  Using the strategy lazy='joined' means that a single request is
  performed to retrieve an object and all its parts that may be
  expressed in several tables. For example when one asks for the network
  list, a complex query will be issued that also retrieves subnets,
  subnetpools, dns agents, etc. The exact query is visible at
  http://paste.openstack.org/show/592120/

  Unfortunately using the strategy lazy=joined has another impact when
  the relation between the parent object and the sub-object has a ?-n
  arity. Rather than giving back exactly the row needed, the single
  query builds a kind of cross-product of the answers sharing the join
  keys. For example if we have a network with 4 tags and 4 subnetworks,
  we will have at least 16 rows for each combination of tags and
  subnetworks. Other fields like rbac rules, special routes, dns servers
  can amplify the problem.

  It is not clear if the heavy usage of the database server and neutron
  server could lead to a real denial of service for other users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1649317/+subscriptions