Open Stack

On Tue, 21 Aug 2018 17:36:18 -0500, Eric Fried wrote:
>> Affinity modeling and shared storage support are compute features
>> OpenStack operators and users need. Operators need affinity modeling in
>> the placement is needed to achieve parity for affinity scheduling with
>> multiple cells. That means, affinity scheduling in Nova with multiple
>> cells is susceptible to races and does*not*  work as well as the
>> previous single cell support.
> Sorry, I'm confused - are we talking about NUMA cells or cellsv2 cells?
> If the latter, what additional placement-side support is needed to
> support it?

Cells v2 cells. We were thinking about native affinity modeling in 
placement for this one because the single cell and legacy case relied on 
compute calling up to the API database to do one last check about 
whether affinity policy was violated, once the instance landed on 
compute, in a race situation. If the check failed, the build was aborted 
and sent back for rescheduling. With multiple cells and split message 
queues, compute cannot call up to the API database to do the 
late-affinity check any longer (cannot reach the API database via 
message queue). So we are susceptible to affinity policy violations 
during races with multiple cells and split message queues.

If we were able to model affinity in placement, placement could tell us 
which compute host to place the instance on, satisfying affinity policy 
and protected from races (via claiming we already do in placement).

-melanie