Action Precedence

The following is the complete list of actions, ordered by precedence (highest to lowest), meaning only the action with the highest precedence will be applied to the workload:

Exclude Action

When setting the annotation scaleops.sh/exclude-automation at the workload or namespace level, excluding by workload type, or when excluding by workload labels/annotations matching, the automation will exclude this workload from being managed and optimized by the platform.

Exclude actions applied by custom namespace labels are with lower precedence than the annotation.

Force Action

When setting the annotation scaleops.sh/force-auto or scaleops.sh/force-policy, at the workload level only, the operation (automation or policy attachment) applies directly to the workload without the ability to override it.

Force Annotation

General Actions

When configuring cluster-level automation by the config map, or policy attachment whether by creating or editing the AutomatedNamespace CRD, or through any UI operation—the workload will receive the defined configuration.

ℹ️

Note: Changes made by any of these methods above take effect immediately, and the most recently applied general action overrides previous settings. To return to the Default Actions control after using a higher-precedence annotation, follow the Reset workload actions control steps.

Default Actions

By setting the default annotation scaleops.sh/default-auto or scaleops.sh/default-policy at the workload or namespace level, or with default automation by workload labels/annotations, you can define the initial state of automation or policy attachment that the workload should begin with.

Default actions applied by custom namespace labels are with lower precedence than the annotation.

ℹ️

If no automation initial state is defined, the workload will start as unautomated. If no policy attachment is configured, the platform will automatically choose the appropriate policy based on the type of workload.

Reverting Workload Control to Default Actions

If you’ve previously managed policy or automation using General Actions or any higher-precedence annotations, you can revert control back to your default actions (eg. scaleops.sh/default-auto annotation) by following these steps:

Note: The reset process can take several minutes to complete.

1. Ensure Default Actions Are Defined

First, make sure the desired default actions are set. For example, add scaleops.sh/default-auto: "true" to the relevant workloads:


apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    scaleops.sh/default-auto: "true"

2. (Recommended) Remove Existing Force, AutomatedNamespace, or Cluster-Level Controls

To ensure the reset applies as expected, it is recommended to remove any existing force annotations (scaleops.sh/force-auto, scaleops.sh/force-policy), AutomatedNamespace (ANS) resources, or cluster-level ConfigMaps (such as scaleops-cluster-operations) that may override default actions.
This step helps guarantee that workloads will revert to their default actions after the reset.

3. Reset Workload-Level Controls

You can clear higher-precedence automation and policy controls to allow default actions to take effect. There are two supported methods:

A. Script

Use this script to reset at cluster/namespace/workload level:


curl -sSL https://scriptshelf.scaleops.com/gitops/reset_workload_level_control.sh -o reset_workload_level_control.sh
chmod +x reset_workload_level_control.sh
./reset_workload_level_control.sh --namespace <namespace> --workload <workload> --workload-type <type>

B. GitOps-ConfigMap

To revert workload control across the entire cluster, apply the following ConfigMap in the scaleops-system namespace:


apiVersion: v1
kind: ConfigMap
metadata:
  name: scaleops-control-actions
  namespace: scaleops-system
data:
  resetClusterWorkloadControl: "true"

This will trigger a one-time, cluster-wide reset of workload automation and policy controls, reverting workloads to their default actions if present.
If you want to reset again in the future, simply re-create the ConfigMap or patch any annotation.

Notes:

Workload Exclusions: Using the GitOps approach, workloads that have exclude or force annotation semantics will be skipped during the reset so that the reset operation applies only where allowed. The following annotations will cause a workload to be excluded from the reset:


"scaleops.sh/exclude-automation",
"scaleops-sh/auto",
"scaleops-sh/policy",

AutomatedNamespace (ANS) and Cluster Automation:
- For workloads in namespaces managed by an AutomatedNamespace (ANS) resource, the reset will apply to existing workloads, reverting them to their default annotation if present.
- New workloads created in these namespaces after the reset will inherit the settings from the ANS resource (or from cluster automation if configured via the UI).
- This distinction ensures that the reset does not override namespace-level or cluster-level automation policies for future workloads, but does revert current workloads to their default state.
To enable the reset for new workloads:
If you want new workloads to also start with the default actions after the reset, remove any existing cluster-level ConfigMap (scaleops-cluster-operations) or AutomatedNamespace (ANS) resources that may override the default actions.

Refer to the Action Precedence section above for more details on how different controls interact, and to better understand which settings will take effect in various scenarios.