Open Stack

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
       },
   ]
 }

Solution 2: Change the data model in some way TBD - your inputs here.

> Some of the areas of potential contention:
> 
> * Adequate for limited but maybe not all use case solutions

Solution 1 is actually *less* limited than the original proposal, in
that it supports the "different nets" bit of the above example. The only
limitation that remains I think is that subtrees *have* to start one
tier away from the root. And as discussed, there's no known use case
where that's a problem.

> * Strict trait constructionism

No traits, no contention.

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

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

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

> 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?

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

efried
.