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