Operating `tazuna destroy`

This page summarizes the procedure and the guards you should have in place when running tazuna destroy against a near-production cluster. For the command specification itself, see the tazuna destroy reference.

Why Make a Runbook

destroy is the operation that removes Tazuna-managed resources from the cluster, and it is the only systematic write command whose impact can span the entire cluster. Unlike running kubectl delete by hand, anything Tazuna considers its own management target disappears in one shot.

The two-layer guard (prompt + environment variable) is a structural defense, but on the operational side you also need to build in “confirm what will be deleted in advance” and “don’t mistake the context.”

What to Prepare in Advance

If there is any possibility you will run destroy against the cluster, we strongly recommend including spec.context_matches in that tazuna.yaml.

spec:
  context_matches:
    - ^prod-tokyo$
  context_match_mode: or
  manifests:
    # ...

With this in place, destroy will fail without touching the cluster at all if current-context is not prod-tokyo. It is the cheapest possible insurance against local context misconfiguration. See tazuna.yaml - context_matches for details.

Standard Flow

Steps 1 to 3 below are operational pre-checks, not internal processing of tazuna destroy. Tazuna itself does not call state list, but running it by hand before destroy is strongly recommended.

# 1. Check current-context (always do this immediately before destroy)
kubectl config current-context
kubectl get nodes

# 2. Understand what will disappear (recommended)
tazuna state list

# 3. Narrow the scope if needed (use exactly the same --tags as at execution time)
tazuna state list --tags experimental   # For confirmation

# 4. Real execution. Deletion only proceeds when both the prompt and the env var are satisfied
TAZUNA_DESTROY_EXECUTABLE=true tazuna destroy --tags experimental

tazuna destroy itself runs in the following order.

Load and validate tazuna.yaml.
Evaluate context_matches. Abort immediately on mismatch.
If --force is not set, prompt for Y/N.
If TAZUNA_DESTROY_EXECUTABLE=true is not set, only log and exit.
If all guards are satisfied, invoke each Manager’s Destroy in order.

Resources are not deleted unless both “Yes at the prompt” and “the env var TAZUNA_DESTROY_EXECUTABLE=true” are set.

Narrowing the Scope

If you want to remove only a specific group rather than the entire cluster, narrow it down with --tags.

TAZUNA_DESTROY_EXECUTABLE=true tazuna destroy --tags experimental

--tags is evaluated as OR (see tazuna.yaml - tags). A useful pattern is to attach a dedicated tag like lifecycle:deprecated to things scheduled for removal, and then delete by that tag.

tazuna destroy --tags <empty> targets all Manifests. When you are doing an unnarrowed destroy, look at the full inventory in advance with tazuna state list to make sure no unexpected resources are present.

Accident-Prone Scenarios

Common patterns and their countermeasures.

Scenario	Where it stops / why it becomes an incident	Recommended countermeasure
Current-context was production when you thought it was staging	If `context_matches` is written, it stops at step 2. Without it, execution proceeds.	Always include `context_matches` in production-tier `tazuna.yaml`. Avoid `--force` so that the prompt remains as a stop.
Wiring destroy into CI and triggering it accidentally on `main`	Without the env var, it stops at step 4. If `TAZUNA_DESTROY_EXECUTABLE=true` is permanently set across CI, execution proceeds.	Do not wire destroy into CI. If you absolutely need it, create a dedicated manual workflow and pass the env var only in that job temporarily.
Forgetting `--tags` and wiping everything	Execution proceeds when both the prompt and env var are satisfied.	Treat “unnarrowed destroy” as something you do not do on near-production clusters. When you do, always run `state list` beforehand.
Things applied by hand with `kubectl apply` are not removed by destroy	Resources not in State are treated as outside Tazuna’s management and are not targets of `destroy`.	If you decide state has diverged, visualize the divergence with `tazuna state diff` first, then decide on the response.

Looser Alternatives to destroy

When you do not need to “delete it completely right now,” remember that the following options exist.

tazuna state sync + TAZUNA_STATE_SYNC_DELETE=true — remove a Manifest from tazuna.yaml and then run state sync; it will be deleted under the removed classification (see tazuna state sync). This cannot be used when you want to reset without changing the source of truth in tazuna.yaml.
A destroy narrowed with --tags — see above.

Command spec: tazuna destroy
Evaluated context_matches: tazuna.yaml
Pre-deletion check: tazuna state list

Keyboard shortcuts

Tazuna