Open Stack

On 04/09/2019 08:36 AM, Chris Dent wrote:
> Spec: https://review.openstack.org/650476
> 
>  From the commit message:
> 
>      To support NUMA and similar concepts, this proposes the ability
>      to request resources from different providers nested under a
>      common subtree (below the root provider).
> 
> There's much in the feature described by the spec and the surrounding
> context that is frequently a source of contention in the placement
> group, so working through this spec is probably going to require
> some robust discussion. Doing most of that before the PTG will help
> make sure we're not going in circles in person.k
> 
> Some of the areas of potential contention:
> 
> * Adequate for limited but maybe not all use case solutions
> * Strict trait constructionism
> * Evolving the complexity of placement solely for the satisfaction
>    of hardware representation in Nova
> * Inventory-less resource providers
> * Developing new features in placement before existing features are
>    fully used in client services
> * Others?
> 
> I list this not because they are deal breakers or the only thing
> that matters, but because they have presented stumbling blocks in
> the past and we may as well work to address them (or make an
> agreement to punt them until later) otherwise there will be
> lingering dread.
> 
> And, beyond all that squishy stuff, there is the necessary
> discussion over the solution described in the spec. There are
> several alternatives listed in the spec, and a few more in the
> comments. We'd like to figure out the best solution that can
> actually be done in a reasonable amount of time, not the best
> solution in the absolute.

How about making the API something like this?

  GET /allocation_candidates?resources1=PCPU:2,MEMORY_MB:2048\
    &resources2=SRIOV_NET_VF:1\
    &group_resources=2:1

the &group_resources query parameter would indicate the request group 
identifiers to group resources with. For example, group_resources=2:1 
means "the providers of resources in request group '2' should be in the 
same tree as providers of resources in request group '1'"

No traits needed at all and the API call has more imperative clarity, 
since the caller is saying exactly how they expect the placement service 
to group related resources.

For "anti-affinity", just add a ! before the group identifier. For example:

  GET /allocation_candidates?resources1=PCPU:2,MEMORY_MB:2048\
    &resources2=SRIOV_NET_VF:1\
    &group_resources=2:!1

Would mean "the providers of resources in request group '2' should NOT 
be in the same tree as providers of resources in request group '1'"

Best,
-jay

[0] Also, there's a single regex that currently mandates that a request 
group identifier needs to be a number:

https://github.com/openstack/placement/blob/master/placement/lib.py#L30-L32

We could easily change that and allow named identifiers instead of 
numbers so that we could do, for example:

  GET /allocation_candidates?resources_compute=PCPU:2,MEMORY_MB:2048\
    &resources_network=SRIOV_NET_VF:1\
    &group_resources=_compute:_network