Public bug reported: 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. ** 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/1730730 Title: AllocationCandidates.get_by_filters returns garbage with only sharing providers Status in OpenStack Compute (nova): New 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 -- 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