Automation Policies Explained

While RealTheory uses Automation Profiles to define the guardrails for automated changes, Automation Policies provide a dynamic, granular, and scalable mechanism for assigning those profiles to the appropriate clusters in your environment. Using labels, you can minimize the need for excessive oversight and management. Automation Policies provide a highly efficient way to manage your automation strategy in large organizations with large numbers of clusters.

Automation is opt-in. Automation is disabled by default and enabled by you. When you enable automation, RealTheory can make configuration changes within the scope and parameters of your automation profiles, including any default values that you have not changed. See Automation Opt-In Requirements Explained.

How Automation Policies Work

Automation Policies define a relationship between clusters with a specific label that you specify and the Automation Profile whose guardrails govern automated changes to workloads in clusters with that label.

Example

Suppose that you have the following situation:

Your production clusters run customer-facing services and need small, infrequent changes outside business hours.
Your development clusters can accept larger changes at any time.
Some clusters are not ready for automation yet.

You might associate a label with each cluster that you want automated:

automation=production
automation=development

You then create one policy for each label.

Policy	Conditions	Profile
1	`automation=production`	Cautious
2	`automation=development`	Cost-focused

Clusters without either label match no policy, so automation does not change their workloads.

Note: You do not need a default profile. Setting a default profile lets automation change workloads in every automation-ready cluster that no policy or direct assignment covers, so set a default only when you want that coverage.

How Policy Matching Works

Each policy includes conditions (a label selector) and an associated Automation Profile.
RealTheory evaluates the policies from top to bottom.
The first policy whose conditions match a cluster applies the policy's profile to that cluster.
If no policy matches, the default policy applies the default profile. If no default profile exists, the cluster has no profile.

Note: Only one policy applies to each cluster. The first policy that matches wins.

To change the order, drag a policy to a new position in the Automation Policies view. A direct assignment always takes precedence over an assignment by any policy, including the default policy.

Which Workloads a Policy Affects

Automation changes a workload only when all of the following are true:

The workload is within the profile's Workload scope, and the profile does not exclude the workload.
The profile applies to the workload's cluster, and the cluster is automation-ready.
The cluster is within the profile owner's cluster access.
If a policy applies the profile, the cluster is also within the policy owner's cluster access.

See Scope and Parameters.

The user who creates a policy becomes the policy's first owner. The policy owner’s cluster access applies in addition to the profile owner’s. Another user can take ownership, and the new owner's cluster access then applies instead. See Automation Owners Explained.