yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #68647
[Bug 1724633] [NEW] AllocationCandidates.get_by_filters hits incorrectly when traits are split across the main RP and aggregates
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