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 <jaypi...@gmail.com> 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 -- 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