Open Stack

> 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". 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]).
- Don't require correlation by list index, which was the only thing I
was a hard -1 on.

So if anyone has a strong preference for [3], I'm not going to fight hard.

efried

> [3] 
> https://review.openstack.org/#/c/597601/1/specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst@323
[4]
https://review.openstack.org/#/c/597601/1/specs/stein/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst@447
[5] Note that they also both *don't* provide information about which
*resource* satisfied which request group. E.g. this spec doesn't help us
with the "multiple disks" problem:
resources1=DISK_GB:50&resources2=DISK_GB:25&group_policy=none may result
in one RP providing DISK_GB:75, request_groups=[resources1,resources2].
I'm assuming we don't care (yet).
[6] https://review.openstack.org/#/c/631244/