Skip to content

Make and Undo a Change

You will make an urgent capacity change to production, release it, and then undo it exactly, with a record in ConfigHub. Notice that you will not touch the cluster yourself. You change the deployment's configuration in ConfigHub and release it; the cluster follows.

1. Make the change and release it. Load has spiked; boost replicas now:

cub function set --variant cubbychat/prod --resource Deployment/backend --protect \
    -o mutations --change-desc "Temporary boost in capacity to handle news event" \
    set-replicas 5
cub release publish cubbychat/prod

Notice what you did not do: no branch, no PR, no pause of reconciliation, no kubectl. The change is scoped to this one deployment, validated like any other change, and recorded in ConfigHub's versioned store with your name and reason on it. --protect keeps the next promote from the base from undoing it behind your back.

source ~/.confighub/clusters/prod.env
kubectl get pods -n cubbychat

2. Undo it. The boost was temporary, and undoing it exactly needs one more word about how a variant is stored. A variant's configuration is held in units. A unit is the granularity at which ConfigHub versions, merges and tracks configuration: each one has its own revision history and its own upstream. The upload made one unit per resource, so the backend Deployment is the unit named backend, addressed by the name its variant is stored under, the component and variant joined with a dash, and its own: cubbychat-prod/backend. (A unit can hold several resources; the upload chose one each.)

Every change already made a revision of that unit, and every release tagged the revisions it shipped, so the state before the boost has a name:

cub revision list cubbychat-prod/backend

Restore the revision at that tag and release again:

cub unit update --patch cubbychat-prod/backend --restore Tag:release-2 \
    -o mutations --change-desc "Revert capacity boost"
cub release publish cubbychat/prod

Restore goes forward, not back. It creates a new revision carrying the earlier data and its protection settings. The boost and the revert both stay in the history, each with the description you gave it:

cub revision list cubbychat-prod/backend

Why this matters. With Configuration as Code, an urgent change like this is where operators break glass. They suspend GitOps reconciliation, change resources in the cluster directly, and update git later, if at all. The record of what was running, and why, lives in someone's terminal history. Here the change and its undo are two ordinary revisions, each released on purpose, each with a description, and the cluster never left the pull-based loop.

Where to go next

  • Scale it up. The value of this model compounds with fleet size. The Components view example walks a six-app, seven-target promotion setup.

Finish

Cleanup the cluster and ConfigHub contents

Further reading