Right now, the compute node is responsible for validating that the scheduler
honored the affinity policy of a server group. It does this by listing all
the instances in a server group and validating that affinity or anti-affinity
was kept true. With cellsv2, this check requires an upcall to the API
database as server groups are stored there. This violates our goal of not
allowing any upcalls to be congruent with known restrictions that actual
cells(v1) deployers require.
This adds a workaround flag, disabled by default, which defeats this check
in the compute node. For smaller deployments, isolation of the cell and api
services is not as big of a deal, so by default, this check will continue
to work as it does today. Larger deployments which care more about the
isolation than they do the absolute affinity guarantees can enable this
workaround to avoid the upcall check. A user can still detect a violation of
their affinity request by examining the obscured host identifier.
Longer-term, this problem goes away when we're doing claims in the scheduler
and placement has a notion of affinity that it can enforce early in the
boot process, eliminating the race and the need for this check entirely.
Related to blueprint cells-aware-api
Change-Id: I22e1a0736a269d89b55b71c2413fa763d5f1fd0c
ef1c539ad1