Open Stack

On Wed, 10 Apr 2019, Eric Fried wrote:

> I'll champion the one I described in the third comment at [4], where we
> add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
> because it's per "allocations" rather than per "allocations.$rp". That
> said, both of these options:
>
> - Provide the same information: which request groups got satisfied by
> which providers [5].
> - Violate the "black box" principle and require one side or the other to
> work around it (either client removes or placement ignores the new key
> on PUT /allocations). As I said further down in [4], I don't care about
> that. (Ed?)
> - Maintain the existing levels of hierarchy for the existing elements,
> which Chris explained was important (see bottom five comments at [4]).

It's true that they do not change existing paths to existing data,
but they do "invade" (as you say in your second point) existing data
structures. The cleanest solution would probably be a new top-level
key that provides the mapping information (line 426 on the spec),
but as discussed there that ends up repeating too much information
and needing ordering, because there's no independent identifier of a
single allocation_request.

So yeah, one of those will do.

A moment to riff on one the points of having these conversations in
the expanse of email:

To my internal unfettered brain the above sort-of-mess is yet more
evidence that nested is a nightmare and gosh I wish we had never
done: it, request groups, provider trees on the nova side, and pretty
much all the stuff that's in progress related to enhanced platform
awareness. It makes me squirm, see bad smells everywhere, and
facepalm multiple times per day.

I feel it is important that I get this off my chest and I encourage
anyone else who has internal voices that don't feel enitirely
appropriate go ahead and let them out as part of this pre-PTG email
process. We are much more likely in the long term to be able to get
things done in a useful fashion if we are able to honestly
flush/vent such concerns in "public" and safely.

Because a lot of this stuff is the reality that we have and a
situation that we need to solve. We can achieve the goals better by
building up a shared language of what it is. That language includes
the shit as well as the shine.

All that stuff above that I don't like at some gut level, I do like
(or at least appreciate the value of) at a more practical level.

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