Desired State: The Promise

"Desired state is the sentence 'this machine should…' — written down, versioned, and owned."

Policy is a promise you write down

Desired state is the layer where you record what a machine is for — not what it's doing this second, but what it's supposed to be. It's a small set of policy fields, and it's the whole difference between a dashboard that nags and one worth trusting.

The fields of "should"

A host's policy carries things like an availability_policy (is it always-on, sleep-allowed, manual, or in maintenance?), a desired_power_state, the expected_services that ought to be loaded, which allowed_operation_classes may target it, and an alert_after that says how long silence is tolerable before it means something. Each field is a promise the status engine can check reality against.

Overrides are typed, not edits

When Dad leaves on a trip, the right move is not to delete the laptop or rewrite its truth to offline is fine forever. It's a temporary override with an owner, a reason, a start, and an expiry: this machine may be unreachable until the 20th. The base policy is untouched, the override lapses on its own, and nobody has to remember to undo it.

Desired can't contradict membership

Policy has a boss: membership. A retired machine can't be expected online — its management_enabled is derived from its membership state, so suspended and retired hosts are simply never eligible for new work. Desired state is powerful, but it lives inside the lifecycle, never above it.

Write the promise, not the panic. Encode what a machine should be once, in policy, so that 'is this a problem?' becomes a comparison instead of a judgment call at 2 a.m.

Code

A host's desired state·json

{
  "host_id": "laptop",
  "membership_state": "active",
  "availability_policy": "sleep_allowed",
  "desired_power_state": "sleep_allowed",
  "expected_services": ["backup-agent"],
  "allowed_operation_classes": ["read", "low", "medium"],
  "alert_after_seconds": 604800,
  "override": {
    "owner": "dad",
    "reason": "traveling until the 20th",
    "starts_at": "2026-07-06T00:00:00Z",
    "expires_at": "2026-07-20T00:00:00Z"
  }
}
// Note what ISN'T here: a live "online" field. Policy says what SHOULD
// be true. Whether the laptop is reachable right now belongs to the
// observed layer and is computed AGAINST this promise -- never stored
// as if the promise and the fact were the same thing.

Exercise

Write a five-field policy for one machine you own: its role, whether it may sleep, one service that must always run, how long silence is okay before you care, and who is allowed to change the policy. Then write a temporary override for a two-week trip that expires on its own.

Hint

If your override is 'set online-ok = true' with no expiry, you didn't write an override — you edited the truth, and you will forget to change it back the moment the trip ends.

Policy is a promise you write down

The fields of "should"

Overrides are typed, not edits

Desired can't contradict membership

Code

External links

Exercise

Progress

Comments 0