Open Stack

> On Apr 15, 2019, at 03:14, Balázs Gibizer <balazs.gibizer at ericsson.com> wrote:
> 
> 
> 
> On Thu, Apr 11, 2019 at 8:01 PM, Eric Fried <openstack at fried.cc> wrote:
>>> Then we need two steps:
>>> 1) handle RPs that only have traits but not resources
>>> 2) allow having the numbered request groups specify only a trait
>>> without requesting resources.
>> 
>> Nothing stops me from traiting an inventoryless provider today, right?
> 
> Does GET /allocation_candidates query handles them properly?

No, I was just pointing out that "step 1" was okay, depending on what you mean by "handle".

>> Do we actually need to involve numbered request groups? Does a concept
>> of required_in_tree=$trait_list satisfy the requirements?
> 
> I don't know. I guess I have to read required_in_tree=$trait_list spec. 
> Please ignore me.

There's no such spec yet. The above is a sincere question that could lead to one.

The GET /a_c syntax

 required_in_tree=$trait_list

would cause the result to include results where the listed traits are *anywhere* is the tree, even if the providers having those traits don't provide resources to the request. This should be fairly simple to implement. I'm asking us to ponder whether it will satisfy our use cases here.

Another option is something like root_required=$trait_list (the traits are only on the root, even when the root doesn't provide resources to the request). This satisfies the immediate use cases, but it's obviously more restrictive, and I don't think it's any easier to implement. 

Neither of these is perfect, probably. But also neither requires doing anything with numbered groups. Did you have something else in mind for that?

efried
.