Comment 5 for bug 1724613

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to nova (master)

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

commit d4398f715f098b9edbc0be8612b6c079a8e607af
Author: Eric Fried <email address hidden>
Date: Tue Nov 7 09:30:21 2017 -0600

    Test alloc candidates with same RC in cn & shared

    This change set adds a couple of failing test cases that demonstrate
    holes in the design of GET /allocation_candidates when inventory from
    the same resource class is present on both the compute node (the "main"
    resource provider) and a shared resource provider.

    The example being used is where the compute node has some local disk,
    and is also associated with a shared storage pool. Both the compute
    node RP and the shared storage RP will provide inventory of DISK_GB.

    Test case test_common_rc demonstrates bug #1724613: when I ask for
    DISK_GB in this setup, the shared storage pool is ignored. I expect to
    get two candidates back: one with the storage from the compute node; the
    other with the storage from the shared storage pool. But I actually
    only get the former candidate back.

    Test case test_common_rc_traits_split shows bug #1724633: that placement
    can't tell which traits are supposed to apply to which resources. In
    the above scenario, if the local storage is SSD and the shared storage
    is RAID, and I ask for SSD + RAID, I "expect" to get back no hits. But
    I would in fact get back a candidate with the storage from the shared
    storage pool, because the cumulative set of traits would satisfy my
    requested SSD + RAID.

    Note that the two tests are functionally identical (traits are ignored
    entirely) until https://review.openstack.org/#/c/479766/ lands. At that
    point, depending on how we decide to implement the code that would deal
    with this scenario, the test may fail *differently* until bug #1724613
    is fixed.

    Related-Bug: #1724613
    Related-Bug: #1724633

    Change-Id: I42edf102379cf329aa2252ab779a9f945f5fc155