Events¶

CAPTF records a Kubernetes Event for each step in the life of an object: the manager once per transition, and a Job’s runner in real time while the Job runs. This page lists every reason, grouped by situation. Jump to: lifecycle, Jobs, ordering and leases, plans and approvals, state, drift and health, identity and credentials, deletion, pools and templates, runner events.

Reading events¶

Events are events.k8s.io/v1 objects recorded on the CAPTF object they are about. Read them in order with kubectl events:

kubectl events --for terraformcluster/<name> -n <namespace>
kubectl events --for terraformmachine/<name> -n <namespace>
kubectl events --for terraformmachinepool/<name> -n <namespace>
kubectl events --for terraformmachinetemplate/<name> -n <namespace>
kubectl events --for terraformclusteridentity/<name> -n default

kubectl describe shows the same events at the end of its output. A TerraformClusterIdentity is cluster-scoped, so its events land in the default namespace. Add -o wide to see which events the manager recorded (captf-manager) and which a runner did (captf.io/runner).

Three rules hold for every event:

• The manager emits an event once per transition or occurrence, never on every reconcile. A reason that appears again means the thing happened again.
• A condition that first appears emits an event only when it starts in its bad state, so a new object’s first reconcile is quiet.
• Notes never carry credentials, tfvars, outputs, plan values or raw stderr.

Where a table says “any provisioned kind”, the event is recorded on a TerraformCluster, TerraformMachine or TerraformMachinePool. The Type column is the Kubernetes event type: Normal reports progress, Warning reports something that needs a look. For a Warning, the Action column says what to check next; the condition that backs the event is in Conditions.

Lifecycle and readiness¶

Jobs¶

Ordering and leases¶

An object runs one operation at a time, and a machine waits for its cluster. These events say what an operation waits for. See Leases.

Plans and approvals¶

These events belong to the destructive-plan guard and to applyPolicy: Manual. See Approvals.

DestructivePlanBlocked is also recorded for a TerraformMachinePool apply that would change the cluster’s exports. The pool keeps applying with the exports of its last successful apply until you approve the change. If an earlier apply may have left such a change partly applied, the pool waits for the approval, as a cluster does.

State¶

See State and Backups.

Drift and health¶

See Drift and health.

Identity and credentials¶

See Identity and credentials.

Deletion¶

See Deletion.

Pools and templates¶

Runner events¶

A Job’s runner posts its own progress as events on the object the Job is for, related to the Job itself. They fire in real time, which makes them the quickest way to see which step a long Job is in. The manager enables them with --runner-events, which defaults to true; see Manager flags. The runner needs create on events in its ClusterRole, which the shipped manifests grant.

For where to read events during an incident, see Observability.