yahoo-eng-team team mailing list archive

[OpenStack Infra <1772243@xxxxxxxxxxxxxxxxxx>]

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

commit 1f37b16e7bfc3ccf76d7f13c595068e2c2ffcc87
Author: Tetsuro Nakamura <nakamura.tetsuro@xxxxxxxxxxxxx>
Date:   Mon May 21 04:19:12 2018 +0900

    Use list instead of set for duplicate check
    
    There can be legitimately distinct allocation requests with the same
    combination of providers. For example, in a case where where both
    SHR1 and SHR2 have both CUSTOM_RC1 and CUSTOM_RC2, the following two
    allocation requests are different:
    
     AllocationRequest(anchor=CN, resource_requests=[
         AllocationRequestResource(rp=CN, resources=[VCPU: 1]),
         AllocationRequestResource(rp=SHR1, resources=[CUSTOM_RC1: 1]),
         AllocationRequestResource(rp=SHR2, resources=[CUSTOM_RC2: 1]),
     ])
    
     AllocationRequest(anchor=CN, resource_requests=[
         AllocationRequestResource(rp=CN, resources=[VCPU: 1]),
         AllocationRequestResource(rp=SHR2, resources=[CUSTOM_RC1: 1]),
         AllocationRequestResource(rp=SHR1, resources=[CUSTOM_RC2: 1]),
     ])
    
    But getting allocation candidates, placement had been filtering out
    one of the two assuming them as the same allocation requests because
    the combination of the providers in play was the same.
    
    This was because placement filtered duplicate candidates using a set
    of provider ids in play while we can't consider resource information
    with the set. This patch fixes the bug by using the list instead of
    the set. This is because we can put resource information in the order
    of that list. Namely, in the example above, we can't detect
    "set([CN, SHR1, SHR2])" is different as "set([CN, SHR2, SHR1])", but
    we can detect [CN, SHR1, SHR2] is different from [CN, SHR2, SHR1].
    
    Change-Id: I90627dfe85661118c4ec2571fc32ffca99dd73d2
    Blueprint: nested-resource-providers-allocation-candidates
    Closes-Bug: #1772243


** 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/1772243

Title:
  Some candidates are missing when multiple sharing provider have
  multiple shared resources

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Some candidates are missing when multiple sharing provider have
  multiple shared resources

  Description
  ===========

  There can be legitimately distinct allocation requests with the same combination of providers.
  But placement filter out them if the combination of the providers in play is the same combination with that we already have tin he allocation requests 

  Example
  =========

  CN(compute node):  
      - VCPU: 16

  SHR1: a sharing provider in the same aggregate with CN)
      - CUSTOM_RC1: 4
      - CUSTOM_RC2: 8

  SHR2(sharing provider2):
      - CUSTOM_RC1: 6
      - CUSTOM_RC2: 3

  We ask for VCPU:1,CUSTOM_RC1:1,CUSTOM_RC2:1.

  Expected: we should get the following two allocation requests:

  [(rp=CN, resources=[VCPU: 1]),
   (rp=SHR1, resources=[CUSTOM_RC1: 1]),
   (rp=SHR2, resources=[CUSTOM_RC2: 1])]

  [(rp=CN, resources=[VCPU: 1]),
   (rp=SHR1, resources=[CUSTOM_RC2: 1]),
   (rp=SHR2, resources=[CUSTOM_RC1: 1]),]

  Actual: We get only one of those candidates, because the combination
  of the rps is the same: CN1, SHR1, and SHR2.

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