thesabear/public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: orchestration — add homelab-inventory-sync flow (card [77])

Browse Source
This commit is contained in:
automation-bot committed 2026-09-06 15:08:27 +03:00
1 parent 75e8b3f694
commit f9737456a8
1 file changed
+5 -4
Download Patch File Download Diff File Expand all files Collapse all files
docs/orchestration.md
+5 -4
View File
@@ -6,11 +6,11 @@
# 🔁 Orchestration # 🔁 Orchestration
> [!NOTE] > [!NOTE]
> Kestra runs every scheduled maintenance flow across the fleet — 13 flows covering OS updates, container updates, app updates, disk cleanup, and KB self-maintenance. Most run straight through on their own schedule with nobody watching; exactly one is built around a check → pause → human approval → apply pattern instead, reserved specifically for the one category of change judged worth a checkpoint. > Kestra runs every scheduled maintenance flow across the fleet — 14 flows covering OS updates, container updates, app updates, disk cleanup, fleet inventory, and KB self-maintenance. Most run straight through on their own schedule with nobody watching; exactly one is built around a check → pause → human approval → apply pattern instead, reserved specifically for the one category of change judged worth a checkpoint.
This is the real flow list, not a claimed count: This is the real flow list, not a claimed count:
![Kestra's real flow list, homelab namespace: 13 flows total, every one showing a real last-execution date and SUCCESS status](../assets/orchestration-flow-list.png) ![Kestra's flow list for the homelab namespace — every flow showing a real last-execution date and SUCCESS status](../assets/orchestration-flow-list.png)
## Why Only One Flow Gets a Human Gate ## Why Only One Flow Gets a Human Gate
@@ -18,7 +18,7 @@ A blanket human-gate policy was the obvious simpler design, and it was rejected:
## Two Patterns, Not One ## Two Patterns, Not One
![12 of 13 flows run straight through on schedule with no human gate, relying on the automated health-check/rollback path instead; the one flow applying Vault/Technitium/Alloy updates runs a check-mode pass, pauses indefinitely on anything pending, and only applies after explicit human approval](../assets/orchestration-flow-patterns.svg) ![13 of 14 flows run straight through on schedule with no human gate, relying on the automated health-check/rollback path instead; the one flow applying Vault/Technitium/Alloy updates runs a check-mode pass, pauses indefinitely on anything pending, and only applies after explicit human approval](../assets/orchestration-flow-patterns.svg)
That's not just a diagram of the pattern — it's the actual flow's own topology in Kestra, `wait_for_approval` sitting right there as a real node between the pending-check and the apply step: That's not just a diagram of the pattern — it's the actual flow's own topology in Kestra, `wait_for_approval` sitting right there as a real node between the pending-check and the apply step:
@@ -30,7 +30,7 @@ This is the real check, not an assumption — every flow's own definition, queri
``` ```
$ for flow in os-update-vms os-update-pve os-update-pve-verify os-update-pbs \ $ for flow in os-update-vms os-update-pve os-update-pve-verify os-update-pbs \
container-update disk-cleanup app-update; do container-update disk-cleanup app-update homelab-inventory-sync; do
echo "$flow: $(curl -s .../flows/homelab/$flow | grep -c 'core.flow.Pause')" echo "$flow: $(curl -s .../flows/homelab/$flow | grep -c 'core.flow.Pause')"
done done
os-update-vms: 0 os-update-vms: 0
@@ -40,6 +40,7 @@ os-update-pbs: 0
container-update: 0 container-update: 0
disk-cleanup: 0 disk-cleanup: 0
app-update: 1 app-update: 1
homelab-inventory-sync: 0
``` ```
## One Dedicated Identity, Not a Shared One ## One Dedicated Identity, Not a Shared One