Open Stack

 >      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.
> 
> [1] https://etherpad.openstack.org/p/placement-ptg-train
> 

-- 
Tetsuro Nakamura <tetsuro.nakamura.bc at 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