Public bug reported:

When requesting multiple resources with multiple traits, placement
doesn't know that a particular trait needs to be associated with a
particular resource.  As currently conceived, it will return allocation
candidates from the main RP plus shared RPs such that all traits are
satisfied  This is bad, particularly when the main RP and shared RPs
provide inventory from the same resource class.

For example, consider a compute node that has local SSD storage, which
is associated with a shared storage RP with a RAID5 array:

 cnrp { VCPU: 24,
        MEMORY_MB: 2048,
        DISK_GB: 16,
        traits: [HW_CPU_X86_SSE,
                 STORAGE_DISK_SSD] }
 ssrp { DISK_GB: 32,
        traits: [STORAGE_DISK_RAID5] }

A request for SSD + RAID5 disk should *not* return any results from the
above setup, because there's not actually any disk with both of those
characteristics.

 AllocationCandidates.get_by_filters(
     resources={ VCPU: 1,
                 MEMORY_MB: 512,
                 DISK_GB: 2 },
     traits= [HW_CPU_X86_SSE,
              STORAGE_DISK_SSD,
              STORAGE_DISK_RAID5])

Expected:

 allocation_requests: []

Actual:

 allocation_requests: [
     { cnrp: { VCPU: 1,
               MEMORY_MB: 512 }
       ssrp: { DISK_GB: 2 } },
 ]

I will post a review shortly with a test case that demonstrates this.
Note, however, that the test will spuriously pass until
https://bugs.launchpad.net/nova/+bug/1724613 is fixed.

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: placement

-- 
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/1724633

Title:
  AllocationCandidates.get_by_filters hits incorrectly when traits are
  split across the main RP and aggregates

Status in OpenStack Compute (nova):
  New

Bug description:
  When requesting multiple resources with multiple traits, placement
  doesn't know that a particular trait needs to be associated with a
  particular resource.  As currently conceived, it will return
  allocation candidates from the main RP plus shared RPs such that all
  traits are satisfied  This is bad, particularly when the main RP and
  shared RPs provide inventory from the same resource class.

  For example, consider a compute node that has local SSD storage, which
  is associated with a shared storage RP with a RAID5 array:

   cnrp { VCPU: 24,
          MEMORY_MB: 2048,
          DISK_GB: 16,
          traits: [HW_CPU_X86_SSE,
                   STORAGE_DISK_SSD] }
   ssrp { DISK_GB: 32,
          traits: [STORAGE_DISK_RAID5] }

  A request for SSD + RAID5 disk should *not* return any results from
  the above setup, because there's not actually any disk with both of
  those characteristics.

   AllocationCandidates.get_by_filters(
       resources={ VCPU: 1,
                   MEMORY_MB: 512,
                   DISK_GB: 2 },
       traits= [HW_CPU_X86_SSE,
                STORAGE_DISK_SSD,
                STORAGE_DISK_RAID5])

  Expected:

   allocation_requests: []

  Actual:

   allocation_requests: [
       { cnrp: { VCPU: 1,
                 MEMORY_MB: 512 }
         ssrp: { DISK_GB: 2 } },
   ]

  I will post a review shortly with a test case that demonstrates this.
  Note, however, that the test will spuriously pass until
  https://bugs.launchpad.net/nova/+bug/1724613 is fixed.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to