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
10 lines
586 B
YAML
10 lines
586 B
YAML
---
|
|
issues:
|
|
- |
|
|
In deployments with multiple (v2) cells, upcalls from the computes to the scheduler
|
|
(or other control services) cannot occur. This prevents certain things from happening,
|
|
such as the track_instance_changes updates, as well as the late affinity checks for
|
|
server groups. See the related documentation on the `scheduler.track_instance_changes`
|
|
and `workarounds.disable_group_policy_check_upcall` configuration options for more
|
|
details. Single-cell deployments without any MQ isolation will continue to operate as
|
|
they have for the time being. |