Open Stack

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

[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