josh/electric-cherry
1
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: make provisioning own instance lifecycle operations

Browse Source
This commit is contained in:
josh
2026-09-27 14:45:00 -04:00
parent cfed584614
commit df265d1900
44 changed files with 1791 additions and 1609 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/provisioning.md
+18 -3
View File
@@ -1,7 +1,8 @@
# Provisioning
Open **Operations → Provisioning** for instance lifecycle work, blueprints, and
persistent activity. Create a server using **Create server**. For an existing
persistent activity. Provisioning owns the queues, safety checks, execution, and
recovery for all six actions. Create a server using **Create server**. For an existing
server, choose **Manage server** or open its **Server actions** menu.
| Action | Behavior |
@@ -30,8 +31,7 @@ failures before making another request.
Start and Restart share the rolling restart limit with campaigns, betas, and
maintenance. A successful API reply is followed by a recovery delay and actual
container/RCON checks. Failed or ambiguous restart requests retain their recovery
slot and are not automatically replayed. Automated restart submissions also appear
in Provisioning history. Stop requires an explicit stopped container state; an
slot and are not automatically replayed. Stop requires an explicit stopped container state; an
unreachable Komodo API is not evidence that a stop succeeded.
Disruptive operations require a fresh zero-player RCON result, unless Komodo
@@ -40,6 +40,21 @@ campaign, beta, maintenance, or provisioning work. Duplicate pending requests fo
the same action return the existing operation; a different action returns a
conflict. Requests and events survive application restarts.
Campaigns, beta runs, and maintenance submit durable restart requests to
Provisioning and observe the resulting operation by ID. Their pages link to that
operation, and its history links back to the requesting work. Provisioning owns
the empty-server check, conflict handling, restart capacity, remote command, and
health verification. The callers retain file deployment, beta evidence, and
Plutonium revision verification. Jobs remain visible while waiting for players,
other work, or integration configuration.
Campaign changes queued before submission can share one restart. Changes arriving
after submission require a new operation. A failed or interrupted request keeps
its original ID and never automatically replays. An explicit beta retry starts a
new attempt, preserving prior history; paused or closed beta work cannot start a
queued restart. Recovery of an already submitted restart continues even if its
requester closes. Upgrades adopt existing restart intent for observation only.
## Routes and compatibility
- `/provisioning`: active operations, blueprints, and history filtered by action.