6.3 KiB
Fleet settings
Administration → Settings has independent Concurrency and Retention sections. Settings persist in SQLite, apply without restarting the controller, and are writable only by administrators. Saving one section preserves the other section's saved values. Upgrades preserve existing values and add new defaults.
Concurrency
The existing fleet restart, startup and destruction limits default to 1. Additional limits default to 0 (no additional cap):
- Restarts per host, including starts and rebuild recovery.
- Startups per host, including creation and rebuilds.
- Destructions per host, including migration source removal.
- Combined lifecycle work across create/start/stop/restart/rebuild/destroy.
- Rebuilds across the fleet, including host drain migrations.
- Hosts downloading or verifying game files simultaneously, including manual imports.
Limits are checked again before command submission after asynchronous preflight. Launch-file preparation reserves capacity. A lifecycle workflow counts once in the combined pool; unresolved commands and recovery keep capacity occupied. Migrations keep rebuild capacity through source removal and destination creation. Lower limits do not cancel admitted work. Game-file preparation slots are assigned on agent command delivery and survive interrupted transfers. Runtime pulls, the four file transfers per host and the two health probes per host remain unchanged.
Retention
For age settings, 0 means no expiry. An explicit version-count policy can still expire unused artifact versions when their age policy is disabled. Game-file grace is a delay: 0 adds no delay. A positive age and version count together preserve the minimum count as well as versions younger than the age threshold.
| History or storage | Default |
|---|---|
| Campaigns | 7 days |
| Successful routine operations | 1 day |
| Provisioning workflows | Indefinite |
| Agent actions | Indefinite |
| Explicitly resolved failures | Indefinite |
| Non-update maintenance jobs | 30 days |
| Resolved recovery incidents | Indefinite |
| Host resource history | 7 days |
| Instance resource samples | 1 day |
| Fleet occupancy metrics | 31 days |
| Telemetry diagnostics | 7 days; 200 per server; 10,000 overall |
| Completed/interrupted matches | Indefinite |
| Closed betas and test evidence | Indefinite |
| Campaign file bodies and closed beta snapshots | No separate expiry |
| Unused artifact versions | No automatic expiry; no minimum count |
| Unused game files | No grace period; keep latest 1 version per game |
| Incomplete browser uploads | Indefinite |
| Authentication audit events | Indefinite |
| Minimum history count | 0 additional records |
Telemetry age and count policies are independent; 0 disables each individual cap. Diagnostic responses remain bounded to 10,000 rows when the per-server retention cap is disabled. Metric and capacity chart time ranges are unchanged; increasing storage retention does not automatically add new chart ranges. Capacity learning continues to use its 24-hour window independently of longer sample retention.
Cleanup and dependencies
Background cleanup runs in bounded batches. New age policies for previously permanent history default to indefinite. Pending work, unresolved failures, recovery dependencies and explicitly protected records are never removed merely because they are old. Referenced artifact versions are retained, including versions referenced by historical campaigns and betas. Collection workflows with unfinished members, cancellation links and recovery slots can keep provisioning history longer than its configured age.
Update attempts and dismissed watchdog incidents remain durable suppression evidence. Host setup, credential/decommission operations and referenced agent commands are protected. Expired unreferenced action history drops payloads, results and events but keeps compact terminal receipts and request fingerprints. Reusing an idempotency key cannot execute an expired command again. Agent mutation journals remain intact; this policy controls controller history, not the agent's execution recovery journal.
Expiring campaign file bodies preserves file paths, hashes and summary records but makes file comparisons and rollback unavailable. The detail page identifies this state and rollback requests fail explicitly. Active beta rollback images stay protected. Expiring matches removes their player participation rows and changes leaderboard/player totals; lifetime aggregates are not retained separately.
Game-file minimums apply per game. Grace starts when a version is superseded. Live, stopped, rebuilding and provisioning instances pin their files; unresolved operations and offline host copies also prevent controller deletion. Controller cleanup still waits for every host to report its copy absent. Incomplete browser uploads expire based on their last activity, including resume checks; active chunk writes and publication hold locks against cleanup. Metadata remains after files expire. Raising retention cannot restore previously deleted bytes.
Preview and record protection
Expand Cleanup preview and protected records to preview the values currently entered without saving them. Preview lists eligible records and known payload sizes; SQLite file space may be reused rather than immediately returned to the OS. Policies can overlap, so payload sizes should not be added together. Unknown row, index, upload and agent-disk overhead is not included.
Use a record's ID from its detail URL or the preview to protect it. Protection can be removed in the same panel. Protecting a campaign or beta also protects its file bodies; protecting those bodies prevents deletion of their parent history. Game-file and incomplete-upload protections apply to storage cleanup.
The minimum history count preserves recent records per history category. It does not apply to telemetry caps, metric/resource samples or game-file storage, which have their own policies. Explicit holds protect individual history/storage records, not individual resource samples or telemetry diagnostics.
Failed campaigns, provisioning workflows and agent commands require explicit resolution before the resolved-failure period applies. Resolution does not bypass recovery/dependency checks. Resolving a failed campaign stops automatic campaign retry requests; it does not cancel commands already submitted.