ef1c539ad1
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