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

Verify Plutonium revisions during provisioning

Browse Source
This commit is contained in:
josh
2026-09-28 14:50:06 -04:00
parent 3fb59cd598
commit a4a5298408
19 changed files with 414 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/provisioning.md
+15 -3
View File
@@ -9,10 +9,10 @@ server, choose **Manage server** or open its **Server actions** menu.
| Action | Behavior |
| --- | --- |
| Create | Create a new instance using the latest promoted files and verify container health, RCON, and the selected map. |
| Create | Create a new instance using the latest promoted files and verify container health, game status, the selected map, and the Plutonium revision. |
| Start | Start the existing container and verify container health and RCON. |
| Restart | Wait until empty, restart the existing container, and verify container health and RCON. |
| Rebuild | Wait until empty, destroy the instance, delete all server files and its registration, then create a fresh instance in the same server slot and port. Verify container health, RCON, and map. |
| Rebuild | Wait until empty, destroy the instance, delete all server files and its registration, then create a fresh instance in the same server slot and port. Verify container health, game status, map, and Plutonium revision. |
| Stop | Wait until empty, stop the container, and verify that Komodo reports it stopped. Keep the instance for a later Start. |
| Destroy | Wait until empty, remove the container and Komodo deployment, then delete server files and registration. |
@@ -38,6 +38,16 @@ proceed until the old files are fully removed. An interrupted fresh startup can
resume health verification, without repeating teardown or creation. Inspect other
failures before making another request.
Create and Rebuild finish only after RCON reports a runtime revision at least as
new as the current Plutonium production release. The worker checks the production
manifest and records the runtime revision for fleet and server version status as
part of provisioning. An unavailable release or unknown runtime revision keeps the
job awaiting verification and holds its startup slot while the worker retries.
A confirmed older runtime fails the operation with its expected and observed
revisions; it does not trigger an automatic restart. Check Plutainer's startup
updater configuration and server logs before retrying. Telemetry can verify game
status and map, but cannot verify the Plutonium revision.
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 and game-status checks. Failed or ambiguous restart requests retain their recovery
@@ -86,7 +96,9 @@ collection. A completed provisioning job does not imply that its requester has
finished its own verification.
New operations record structured verification evidence alongside their activity:
the check result, source, evaluation time, and expected/observed map when relevant.
the check result, source, evaluation time, and expected/observed map or Plutonium
revision when relevant. Create and Rebuild show **Verify Plutonium revision**, with
separate evidence for the production manifest and the running revision from RCON.
Game status can be verified by RCON or accepted fresh telemetry. Engine-map checks
do not independently verify a T6 start location. Passed checks describe their
recorded observation; later checks can fail or become unknown. Completion describes