On Tue, 9 Apr 2019, Chris Dent wrote:
* The problem: we want to be able to request allocation candidates filtered by a trait that exists on the root provider; but
* (a) the root provider may provide no resources (eventually - e.g. CPU/mem in NUMA providers, shared disk); and/or
* (My brain hurts from the concept for a provider that provides nothing. Perhaps it provides something we aren't remembering to count?)
* (b) we are using only numbered groups and would have to guess where to stuff the `required` - again probably based on looking for the VCPU/mem resources, which, as above, may wind up not on the root provider.
I've been trying to think about this (and related nested things) in a general way. In part to see if I can resolve my unease with them, but also to see if there are other angles at which we can come at the problems. Basically look around from all angles. In [1] Tetsuro talks about "spanning" and how we have different spanning policies for different situations. Ed mentions "graphs" as a better model for providers, often. How far away are we from being able to say that all attributes could be treated as spanning whether requests are expressed granularly or not? It seems we are closer in some areas, less so in others, and different depending on how we ask. If we made it true by default, in all contexts, would it help? For example, if we said that "traits always flow down [4]" (the phrase that entered my brain and got me to start this email, "down" in this case is "in the direction of children") then some traits could be on the compute node, but expressed in a numbered request group if that happened to be more convenient. This mental model works well for me, because nested often represents a _containing_ hierarchy [2]. If the "compute RP has no resources to give [...] but it's still the thing exposing traits we want to filter by" [3], if we make it so the children inherit those traits (because they have flowed down and the children are "inside" the thing) things feel a bit saner to me. Would be good if Eric were able to express in more detail why inherit feels "terrible" [3]. It could very well be. Similarly, aggregate membership would flow down as well, because a child is always in its parent's aggregate too because it is inside its parent. A numeric requiredN or member_ofN span would be capped by the resource provider that satisfied resourcesN. As I'm writing this I'm feeling a big sense of "isn't this the obvious way?" and "what am I missing?" and "somewhere there is a DAG lover laughing". So: * Where is it like this? * Where is it not like this? * What now? We need to work out a consistent and relatively easy to explain mental model for this, because we need to be able to talk about it with other people without them being required to re-experience all the mental hurdles we are having to overcome. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004909.htm... [2] Where this might break down is with interactions with neutron if we're trying to get switches into the mix. However, if the port is considered effectively a part of the node, not really an issue. I think this is okay. A shared provider is one that we care about but is not "inside". Nested means nested. [3] https://review.openstack.org/#/c/645316/1/nova/compute/api.py@1098 [4] A corollary could be "classes of inventory always flow up": If you need a SRIOV_NET_VF, this root resource provider can provide it because it has a great grandchild which has it. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent