Open Stack

On 04/10/2019 10:31 AM, Eric Fried wrote:
>> It is on my TODO list to create a story for it in placement and move
>> the spec to the placement repo. I don't know when I will reach this
>> item on my list, sorry.
> 
> I was getting ready to volunteer (again) to help move the ball on this
> because it's really important that we get this done.
> 
> But then I started thinking, is it really? The workarounds we have in
> the client-side code right now are pretty sucky, but they work. The
> effort of $subject is an optimization and suck-reducer, but is it
> crucial? Probably not. Though I would like to hear from Cyborg before we
> decide we can live without it for Train.
> 
>> When I move the spec I can add the open questions from the nova spec
>> review to the placement spec directly to help continuity. Is that OK?
> 
> WFM.
> 
>> Pinging Cyborg folks. Does Cyborg needs something similar?
> 
> I know for sure this is a yes (somewhere around [6]?), but I won't be
> able to express the details as well as Sundar.
> 
>> I can own the first alternative in the spec [3].
> 
> 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".

After considering the alternatives, this is my preference as well. 
Having a "mappings" key in each element of the "allocation_requests" 
array makes sense to me: We are providing information *about that 
particular allocation request's request group to provider mapping* and 
therefore I feel this is the best location for it to be.

Best,
-jay