Policies, Constraints, and Automation Levels
Policies decide what the market may do and how far automation goes. Items usually describe a scoped group and an action type, then ask what actually executes.
Automation levels
- Disabled: no recommendation and no action.
- Recommend: the action is generated and appears in Pending Actions but waits for a human.
- Automated: the Action Orchestrator executes it, or hands it to external orchestration such as a ServiceNow change or Ansible runbook.
- Mode is set per action type, per entity type, per scope. It is not one global switch per VM.
Scope and precedence
- The base (default) policy applies to everything; automation and placement policies override it for the entity types and groups they name.
- Specificity wins: a policy scoped to a 20-VM group beats the base policy.
- Schedules define when automated actions may run, and maintenance windows belong here rather than in ad hoc manual handling.
Constraints and placement
- Placement policies express affinity: must and must not (hard), should and should not (soft preference), don't care.
- Capacity and sizing constraints bound what the market may propose, for example a maximum number of VMs per host or a no-resize rule for tagged workloads.
Worked example
Production VMs must never be resized automatically but may be moved automatically. Reasoning: create one automation policy scoped to the production group with entity type Virtual Machine, set Resize to Recommend, and set Move to Automated. A single automated toggle cannot express this, because modes are per action type.
Traps
Enabling automation at the base policy first; expecting a placement policy to execute something (it only biases the market, the automation mode still decides); forgetting that a parent-level Disabled suppresses child recommendations.