Open Stack

On 04/09/2019 09:00 AM, 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.

We have a similar issue with traits.

I actually think there should be a single "apply membership or traits 
using self-and-children" policy. I've been unable to think of any use 
case that would *not* be serviced by this policy.

Providers that are matched for a particular request group's resources 
should THEN have any member_of constraints applied to them and their 
children. Same for traits, IMHO.

In other words, the algorithm for matching allocation candidates should 
do the following in order for each request group:

1) Find the provider IDs having capacity for the resources contained in 
the request group
2) If there is a member_of constraint in this request group, reduce the 
matched set to only those providers that are associated (or have any 
children associated) with the aggregates listed in the member_of constraint
3) If there is a required trait constraint in this request group, reduce 
the matched set to only those providers that have the required trait(s) 
or where their children have the required traits
4) If there is a forbidden trait constraint in this request group, 
remove from the matched set any providers that have the forbidden 
trait(s) or where their children have the forbidden traits

Repeat for each request group, applying whatever group_policy=isolate 
constraint when >1 granular request group.

Best,
-jay