yahoo-eng-team team mailing list archive

[OpenStack Infra <1730730@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/516782
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ea63b3b40f0abddce22a02f79ff9275d55d37407
Submitter: Zuul
Branch:    master

commit ea63b3b40f0abddce22a02f79ff9275d55d37407
Author: Jay Pipes <jaypipes@xxxxxxxxx>
Date:   Tue Oct 31 16:03:33 2017 -0400

    finish refactor AllocCandidates._get_by_filters()
    
    This patch completes the refactoring of the
    AllocationCandidates._get_by_filters() mega-method by splitting out the
    remaining pieces of code that handle the construction of the
    part-shared, part-non-shared allocation requests for when there are
    sharing providers in a deployment.
    
    The split-out _alloc_candidates_with_shared() is still a long, complex
    method and I'll continue trying to reduce the complexity there and break
    functions out of it further. I did uncomplicate a part of the function
    with use of the itertools.product() function to replace a faulty use of
    zip() against a list of allocation request resource lists.
    
    Closes-Bug: #1730730
    Change-Id: Ibcfd1a28f36d3c7ccd26fcc6386207e4a25300d4


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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1730730

Title:
  AllocationCandidates.get_by_filters returns garbage with only sharing
  providers

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  If my placement database is set up with only sharing providers (no
  "compute nodes"), the results are broken.

  Steps to reproduce
  ==================
  Here's one example:

  SS1 has inventory in IPV4_ADDRESS, SRIOV_NET_VF, and DISK_GB.
  SS2 has inventory in just DISK_GB.

  Both are associated with the same aggregate; both have the
  MISC_SHARES_VIA_AGGREGATE trait.

  I make a request for resources in all three classes (in amounts that
  can be satisfied by those inventories).

  Expected result
  ===============
  It is unclear what the expected result is.  There is a school of thought that we are only dealing with compute hosts right now, so we should never get back a candidate that doesn't include a compute host.  In that case, this scenario should yield *zero* candidates.

  On the other hand, in the long-term vision of placement, there should
  be no reason not to support scenarios where allocations are made
  *only* against sharing providers (as long as they're in the same
  aggregate for a given candidate).  In that case, this scenario should
  yield two candidates:

  One that gets all its resources from SS1;
  One that gets DISK_GB from SS2, and IPV4_ADDRESS and SRIOV_NET_VF from SS1.

  Actual result
  =============
  The actual result is three candidates:

  One that gets all its resources from SS1 (cool);
  One that gets DISK_GB from SS2 and IPV4_ADDRESS from SS1 (not cool - SRIOV_NET_VF isn't in here!)
  One that gets DISK_GB from SS2 and SRIOV_NET_VF from SS1 (not cool - IPV4_ADDRESS isn't in here!)

  I will post a functional test to demonstrate this.

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