Open Stack

Folks who care about placement (but especially Jay and Tetsuro)-

I was reviewing [1] and was at first very unsatisfied that we were not
returning the anchor providers in the results.  But as I started digging
into what it would take to fix it, I realized it's going to be
nontrivial.  I wanted to dump my thoughts before the weekend.

<BACKGROUND>
It should be legal to have a configuration like:

        #        CN1 (VCPU, MEMORY_MB)
        #        /      \
        #       /agg1    \agg2
        #      /          \
        #     SS1        SS2
        #      (DISK_GB)  (IPV4_ADDRESS)

And make a request for DISK_GB,IPV4_ADDRESS;
And have it return a candidate including SS1 and SS2.

The CN1 resource provider acts as an "anchor" or "relay": a provider
that doesn't provide any of the requested resource, but connects to one
or more sharing providers that do so.

This scenario doesn't work today (see bug [2]).  Tetsuro has a partial
fix [1].

However, whereas that fix will return you an allocation_request
containing SS1 and SS2, neither the allocation_request nor the
provider_summary mentions CN1.

That's bad.  Consider use cases like Nova's, where we have to land that
allocation_request on a host: we have no good way of figuring out who
that host is.
</BACKGROUND>

Starting from the API, the response payload should look like:

{
    "allocation_requests": [
        {"allocations": {
            # This is missing ==>
            CN1_UUID: {"resources": {}},
            # <==
            SS1_UUID: {"resources": {"DISK_GB": 1024}},
            SS2_UUID: {"resources": {"IPV4_ADDRESS": 1}}
        }}
    ],
    "provider_summaries": {
        # This is missing ==>
        CN1_UUID: {"resources": {
            "VCPU": {"used": 123, "capacity": 456}
        }},
        # <==
        SS1_UUID: {"resources": {
            "DISK_GB": {"used": 2048, "capacity": 1048576}
        }},
        SS2_UUID: {"resources": {
            "IPV4_ADDRESS": {"used": 4, "capacity": 32}
        }}
    },
}

Here's why it's not working currently:

=> CN1_UUID isn't in `summaries` [3]
=> because _build_provider_summaries [4] doesn't return it
=> because it's not in usages because _get_usages_by_provider_and_rc [5]
only finds providers providing resource in that RC
=> and since CN1 isn't providing resource in any requested RC, it ain't
included.

But we have the anchor provider's (internal) ID; it's the ns_rp_id we're
iterating on in this loop [6].  So let's just use that to get the
summary and add it to the mix, right?  Things that make that difficult:

=> We have no convenient helper that builds a summary object without
specifying a resource class (which is a separate problem, because it
means resources we didn't request don't show up in the provider
summaries either - they should).
=> We internally build these gizmos inside out - an AllocationRequest
contains a list of AllocationRequestResource, which contains a provider
UUID, resource class, and amount.  The latter two are required - but
would be n/a for our anchor RP.

I played around with this and came up with something that gets us most
of the way there [7].  It's quick and dirty: there are functional holes
(like returning "N/A" as a resource class; and traits are missing) and
places where things could be made more efficient.  But it's a start.

-efried

[1] https://review.openstack.org/#/c/533437/
[2] https://bugs.launchpad.net/nova/+bug/1732731
[3]
https://review.openstack.org/#/c/533437/6/nova/api/openstack/placement/objects/resource_provider.py@3308
[4]
https://review.openstack.org/#/c/533437/6/nova/api/openstack/placement/objects/resource_provider.py@3062
[5]
https://review.openstack.org/#/c/533437/6/nova/api/openstack/placement/objects/resource_provider.py@2658
[6]
https://review.openstack.org/#/c/533437/6/nova/api/openstack/placement/objects/resource_provider.py@3303
[7] https://review.openstack.org/#/c/558014/