/me responds to self Good progress has been made here.
Tetsuro solved the piece where provider summaries were only showing resources that had been requested - with [8] they show usage information for *all* their resources. In order to make use of both [1] and [8], I had to shuffle them into the same series - I put [8] first - and then balance my (heretofore) WIP [7] on the top. So we now have a lovely 5-part series starting at [9]. Regarding the (heretofore) WIP [7], I cleaned it up and made it ready. QUESTION: Do we need a microversions for [8] and/or [1] and/or [7]? Each changes the response payload content of GET /allocation_candidates, so yes; but that content was arguably broken before, so no. Please comment on the patches accordingly. -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/ [8] https://review.openstack.org/#/c/558045/ [9] https://review.openstack.org/#/c/558044/ On 03/30/2018 07:34 PM, Eric Fried wrote: > 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 > __________________________________________________________________________ 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
