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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev