Every Automation Profile and Automation Policy has an owner, the user whose cluster access limits which clusters the profile or policy can affect. Ownership keeps automation within the access that your organization has already granted to the owner.
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 an Owner Limits Scope
A profile can affect only the clusters that the profile applies to and that fall within the profile owner's cluster access. When a policy applies the profile, the policy owner's cluster access also applies, so the profile can affect only clusters within the cluster access of both owners.
RealTheory checks each owner's roles and cluster access every time automation runs. A change to an owner's roles or cluster access therefore might change which clusters the profile or policy can affect, without any change to the profile or policy itself.
The owner appears in the Owner field when you create or edit a profile or policy. The user who creates a profile or policy becomes the first owner.
Taking Ownership
Any user with the sys_admin or automation_admin role can take ownership of a profile or policy. When you edit a profile or policy, Take ownership appears next to Owner, unless you are already the owner. You take ownership for yourself, and the change takes effect when you save. Your cluster access then limits which clusters the profile or policy can affect, so the affected clusters might change.
Setting a profile as the default also makes you the owner of the profile, if you are not the owner already. See Setting the Default Automation Profile.
Example
Scenario: Your organization has clusters A, B, C, D, and E.
- Morgan owns a profile, and Morgan's cluster access covers clusters A, B, C, and D.
- Riley owns a policy that applies the profile. The policy's conditions match clusters B, C, D, and E, and Riley's cluster access covers clusters A, B, and C.
What RealTheory evaluates: Each restriction removes clusters, and automation can change workloads only in clusters that pass all three restrictions.
| Step | Restriction | Clusters remaining |
|---|---|---|
| 1 | Morgan's cluster access (profile owner) | A, B, C, D |
| 2 | The policy's conditions | B, C, D |
| 3 | Riley's cluster access (policy owner) | B, C |
What this means: Automation can change workloads in clusters B and C. Within clusters B and C, the profile's guardrails, such as Workload scope, decide which workloads automation can change. If Morgan takes ownership of the policy, cluster D is included too, because Morgan's cluster access covers D. Before you take ownership, review the clusters that the profile or policy applies to, so that you know which clusters the change affects.
If the Owner's Account Is Deactivated
If an owner's account is deactivated, a user with the sys_admin or automation_admin role must take ownership to manage the profile or policy again.
Users with the user_admin or sys_admin role see a warning that the owner's account is deactivated. Users with only the automation_admin role might see a more general notification instead.
See Also
Automation Explained
Automation Profiles Explained
Automation Policies Explained
Setting the Default Automation Profile