[placement][nova][ptg] Resourceless trait filters
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>
>>>> 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,
>> 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
>>> of required_in_tree=$trait_list satisfy the requirements?
>> I don't know. I guess I have to read required_in_tree=$trait_list
>> 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
> 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.
|____ 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:
"required": ["CUSTOM_PHYSNET0", "CUSTOM_VNIC_TYPE_NORMAL"]
"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
> 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.