Open Stack

On Wed, 10 Apr 2019, Eric Fried wrote:

> I feel like good progress is occurring in the
>
>> Spec: https://review.openstack.org/650476
>
> As of this writing, I'm backing totally off of the solution proposed
> there and instead favoring one of:
>
> Solution 1: Assume "subtree" means "exactly one tier away from the root"
> and express groupings of, er, request groups as needing to come from
> "the same subtree". We should *not* do this by making a queryparam whose
> value contains request group numbers, for reasons explained in the
> spec/comments. Any other attempt to represent groups-of-request-groups
> in a querystring is (IMO) untenable, so we should cut over to accepting
> the query as a JSON payload. Here's a sample of what it would look like
> for, "give me proc, mem, and two different nets, all from the same NUMA
> node; and disk from wherever":
>
> { groups: [
>       { requests: [
>             { resources: {DISK_GB: 10} }
>         ]
>       }
>       { requests: [
>             { resources: {VCPU: 2, MEMORY_MB: 128} }
>             { resources: {VF: 1},
>               required: [NET_A] },
>             { resources: {VF: 1},
>               required: [NET_B] },
>         ],
>         group_policy: subtree_affinity
>       },
>   ]
> }

For those of us not in your head, can you explain how the above is
different/better from the following pseudo-query:

      resources=DISK_GB;
      resources1=VCPU:2,MEMORY_MB:128;
      resources2=VF:1;required2=NET_A;group_policy2=subtree_rooter:resources1;
      resources3=VF:1;required2=NET_B;group_policy3=subtree_rooter:resources1

Apologies if I'm missing some details. I probably am, that's why
I'm asking. I'm intentionally ignoring your "should not do this by
making a queryparam ... group numbers" because I didn't fully
understand the explanation/reasoning in the discussion on the spec,
so I'm after additional explanation (that is, if we have to merge
request groups we still need to preserve the distinctiveness of the
groups, and if some form of a hierarchical relationship is present
we need to maintain that).

To be clear, I'm not trying to block the JSON body, I'm trying to
understand. That is: my request for an explanation of the
differences is exactly that.

>> * Evolving the complexity of placement solely for the satisfaction
>>   of hardware representation in Nova
>
> Mm. I get that it would be nice to identify non-Nova needs for this
> feature, but hopefully you're not suggesting that we should avoid doing
> it if we can't find some.

As I said on the spec at

https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst@135

"a way that placement can work that happens to satisfy NUMA" (using
placement-related primitives) as opposed to making a solution that
is directly modeled off NUMA concepts. I'm pretty sure we're not
doing the latter, but it is a thing to be aware of while having a
wide-open conversation (which is what this is).

I'm _not_ suggesting we avoid it.

>> * Inventory-less resource providers
>
> An interesting topic, but IMO not related to $subject. This will come up
> as soon as we model NUMA + sharing at all. We shouldn't muddy these
> waters by hashing it out here.

I'm sorry to beat on this drum over and over again, but the reason
to have this pre-PTG stuff is exactly to churn up the waters and get
all the ideas out in the open so that we are thinking about the
entire system, not specific details.

>> * Developing new features in placement before existing features are
>>   fully used in client services
>
> Are we not pretty close on this? Are there any placement features that
> don't have client uses either already implemented or proposed for Train?
> Again, IMO not a thing to even consider blocking on. And also not
> specific to this topic.

It's nothing to do with blocking, it's about being aware. Strict
adherence to thread discipline is not desired in this process.
Ramble. Talk. Spitball. We have the time. Use it.

>> I list this not because they are deal breakers or the only thing
>> that matters, but because they have presented stumbling blocks in
>> the past and we may as well work to address them (or make an
>> agreement to punt them until later) otherwise there will be
>> lingering dread.
>
> How about we do that in a separate thread, then?

Why? See my two paragraphs above and my facepalming in another
thread.

>> We'd like to figure out the best solution that can
>> actually be done in a reasonable amount of time, not the best
>> solution in the absolute.
>
> Yeah, so to that point, I fear analysis paralysis if we decide to go
> JSON query, trying to get the schema absolutely perfect. Parity with the
> existing querystring impl plus the subtree affinity feature ought to be
> good enough to start with.

I suspect if we can come up a sufficient explanation for why query
params are not gonna do it (which might be relatively painless) we
might, if we give ourselves the leeway to hash it out effectively,
come up with a reasonable set of constraints for an initial version
(which we have license to evolve).

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent