On Mon, Apr 15, 2019 at 12:48 PM, Eric Fried <openstack@fried.cc> wrote:
On Apr 15, 2019, at 03:14, Balázs Gibizer <balazs.gibizer@ericsson.com> wrote:
On Thu, Apr 11, 2019 at 8:01 PM, Eric Fried <openstack@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 .