Change windows and locks
Change windows and locks protect production nodes from changes at the wrong time.
- A change window sets the hours when a node group may be changed. Changes requested outside those hours are held and run when the window opens.
- A lock makes one node refuse every change until it is unlocked. The node itself enforces it.
Both are managed by Gardience admins.
Change windows
Add a change window
- Open Automation > Change control.
- Under Change windows, pick the node group.
- Tick the days. Saturday and Sunday are ticked by default.
- Set the start and end times (HH:MM) and the time zone.
- Choose Add window.
The Now column shows whether each window is "Open now" or "Closed". To remove a window, choose Remove. Adding and removing windows is recorded in the audit log.
A window can run past midnight. For example, Saturday 22:00 to 02:00 is open from 22:00 on Saturday until 02:00 on Sunday.
What a change window covers
A window applies to any change aimed at a node in its group, whether the change names the group or reaches the node through another target. If a node is in several groups, a closed window on any of them holds the change. If Gardience cannot find out which nodes are in a group, it holds the change rather than guess.
How each kind of work is treated outside the window:
| Work | Outside the window |
|---|---|
| Dashboard fix buttons | Held per node. Nodes outside the window wait; the others run now. |
| Runbook run from the console, or from an API key that does not require approval | The whole run is held if the target group or any target node is outside its window. |
| Workflow steps, schedules, and API requests that require approval | Held per node. The step runs on the nodes whose window is open. |
| Ansible playbook runbooks | Same as any runbook run. |
| Drift Correct now | Refused with a message. It is not held; correct the node when the window opens. |
| Drift auto-correct | Nodes outside their window are skipped until a later check. |
Held work is listed under Held and queued work on the same page. See Held work.
Exceptions
These are not held by a change window:
- Read-only checks. Pings, node details, update searches (
pkg.list_upgrades,win_wua.list,win_wua.get_needs_reboot), the baseline check and inventory collection always run. Scans keep working at any hour. - Emergency overrides. An admin can release held work early by choosing Run now (override) and giving a reason. See Held work.
- Event rule restarts. When a watched service stops, the Salt master restarts it straight away. See Drift checks and event rules.
- Jobs sent directly to Salt. Change windows are applied by Gardience. A job sent straight to Salt from the fleet console's own job screens, by someone whose role allows it there, is not held. Use a lock when a node must refuse everything.
Locks
Lock or unlock a node
- Open Machines > Inventory.
- In the System lock column, choose Lock… on the node.
- Enter the reason. A reason is required and goes in the audit log.
To unlock it, choose Unlock in the same column. Locked nodes are also listed under Locked nodes on Automation > Change control.
When you lock or unlock a node, Gardience pushes the change to it and waits up to 20 seconds for the node to confirm.
What a lock does
Gardience turns on Salt's blackout mode for the node. While it is on, the node's agent refuses every Salt command except a short list of read-only ones:
test.ping,test.versiongrains.items,grains.itempkg.list_upgrades,win_wua.list,win_wua.get_needs_rebootgardience.baseline,gardience.inventorysaltutil.refresh_pillar,saltutil.find_job,saltutil.sync_all,saltutil.sync_modulesbeacons.list
Because the node enforces it, a lock also refuses jobs sent directly to Salt, and event rule restarts.
In Gardience:
- The dashboard shows "Locked" and the reason in place of the fix buttons. A fix request returns "That node is locked. Unlock it in Inventory first."
- Runbooks, workflows and schedules skip locked nodes and say so in the log.
- Ansible playbook runs refuse every command for a locked node.
- Drift Correct now is refused, and auto-correct skips the node.
- Scans and inventory keep working.
When a node's key is removed from the fleet, its lock is removed too, so a new machine enrolled later under the same name does not inherit it. The audit log records this as node.unlocked with the reason "node removed from the fleet".