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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
