A) Aggregate on root spans whole tree for ``members_of=`` requests in 'GET /allocation_candidates' B) This spanning policy doesn't apply to granular requests ``members_of<N>=`` or to requests in 'GET /resource_providers' C) This change is a bug fix without microversion
For example, let's say two non-root NUMA RPs have the resources. In this case, if the root compute node RP is in aggA, aggA applies to the NUMA nodes *IF* a user requests only 1 NUMA node via the non-granular request while aggA does *NOT* apply to NUMA nodes when a user wants for example two separate NUMA nodes using only granular requests. Setup ----- * Add compute1 in aggA by putting aggA on the root RP of compute1 * compute A has two NUMA nodes and each NUMA RP has 4 VCPUs Actual ------ * GET /allocation_candidates?resources=VCPU:2&member_of=<aggA> -> returns 2 allocation requests of each numa node of the compute1 since placement thinks that the NUMA nodes are in aggA * GET /allocation_candidates?resources1=VCPU:1&member_of1=<aggA>&resources2=VCPU:1&member_of2=<aggA> -> returns nothing since it is granular request so placement thinks that the NUMA nodes are not in aggA Expected -------- The latter should return 1 allocation request on compute1 which contains one allocation to one NUMA node and the other allocation to the other NUMA node. In other words, whether an RP is in the aggregate or not must NOT rely on how user searches it, IMO. The aggregate is not dynamic thing. We'd like to be able to answer to the question "Is it in agg A?" simply without any request info. "Is it in aggA?" "Well, that depends on how you ask that. non-granularly speaking, it is in aggA, but granularly speaking, it is not in aggA" ...would be too difficult. Resource provider is not a Schrödinger's cat. On 2019/04/09 22:00, Chris Dent wrote:
From the etherpad [1]:
* Last PTG for Stein, we decided the following policies and have done so in Stein
A) Aggregate on root spans whole tree for ``members_of=`` requests in 'GET /allocation_candidates' B) This spanning policy doesn't apply to granular requests ``members_of<N>=`` or to requests in 'GET /resource_providers' C) This change is a bug fix without microversion
However, I now feel the policy B is weird. Consider a case where only granular requests are used in the request. If operator puts aggA on root, aggA applies the child or not depends on cases how you created the request. That's very difficult for operators to debug...
This is from Tetsuro, so perhaps he can add some additional info, but basically I think what's being requested here is some discussion on whether changing B is warranted.
-- Tetsuro Nakamura <tetsuro.nakamura.bc@hco.ntt.co.jp> NTT Network Service Systems Laboratories TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan