Open Stack

On Mon, Apr 15, 2019 at 12:48 PM, Eric Fried <openstack at fried.cc> wrote:
> 
> 
>>  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.

Sorry there was too many mails for me to process. So I assumed I 
overlooked this one as well.

> 
> 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.

That would be yet another new way to require something in a different 
way that we requiring things so far.

We had initially the unumbered group (we didn't even called it that way 
from the start) with resources and traits (and aggregates), then we 
realized that we needed more granularity to express two sets of 
resources fulfilling different, even contradicting traits, so we 
created numbered request groups. Now we have the next complication due 
to traits are not on the same RP we are requesting resources from but 
numbered groups are fulfilled from a single RP only.

So what we need to solve is. Two (or more) sets of resources where the 
different sets requires different, contradicting traits, in a setup 
where the trait is not on the RP where resource inventory is.

compute RP
|
|
|____ OVS agent RP
|      |     * CUSTOM_VNIC_TYPE_NORMAL
|      |
|      |___________ br-int dev RP
|                       * CUSTOM_PHYSNET_PHYSNET0
|                       * NET_BW_EGR_KILOBIT_PER_SEC: 1000
|
|
|____ SRIOV agent RP
|      |     * CUSTOM_VNIC_TYPE_DIRECT
|      |
|      |
|      |___________ esn1 dev RP
|      |                * CUSTOM_PHYSNET_PHYSNET0
|      |                * NET_BW_EGR_KILOBIT_PER_SEC: 10000
|      |
|      |___________ esn2 dev RP
|                       * CUSTOM_PHYSNET_PHYSNET1
|                       * NET_BW_EGR_KILOBIT_PER_SEC: 20000


Then having two neutron ports in a server create request:
* port-normal:
    "resource_request": {
    "resources": {
            orc.NET_BW_EGR_KILOBIT_PER_SEC: 1000},
    "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_NORMAL"]

* port-direct:
    "resource_request": {
    "resources": {
            orc.NET_BW_EGR_KILOBIT_PER_SEC: 2000},
    "required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_DIRECT"]

Today this will become two numbered request groups. But as the numbered 
groups are always fulfilled by a single RP and therefore the a_c result 
is empty due to CUSTOM_VNIC_TYPE_ traits.

The 'required_in_tree' in this case would need to contain both 
CUSTOM_VNIC_TYPE_NORMAL and CUSTOM_VNIC_TYPE_DIRECT which would be 
either be contradiction (if we interpret it in a way that both needs to 
be fulfilled from the same RP) or would not express the port request 
(if we interpret in a way that the trait needs to be in the tree 
somewhere).

> 
> 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.

the 'root_required' would not solve the above example either as the 
above example does not depend on the root RP at all.

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

See above. I think the above example is a bit more generic than the 
NUMA based one due to the fact that it does not depend on the root 
having traits. Also it shows the why the numbered groups needs to be 
considered when we talk about traits not being on the RP that provides 
the requested resources.

I would try to extend the api in a way that extends the existing tools, 
the groups, to be able to support requests against the above tree. How 
to do that? I don't know. I need to think about it. But we might need 
to revisit the decision to restring numbered group to a single RP.

Cheers,
gibi

> 
> efried
> .
> 
> 
>