ReviewOS

stacks/ts-cloud

Add safe platform upgrades, maintenance, cleanup, and disaster-recovery drills

#164
Closed chrisbbreuer opened this 24 days ago · 0 comments
24 days ago

Roadmap relationship

Outcome

Operate the ts-cloud control plane and managed servers over time with version visibility, signed update plans, maintenance windows, disk/log/image cleanup, control-plane backup/restore, rollback, and repeatable recovery drills.

Current gap

CLI upgrade commands are placeholders, server package update/hardening commands are stubbed, and cleanup/version health is fragmented. There is no fleet-wide compatibility matrix, staged rollout, rollback bundle, control-plane recovery workflow, or routine evidence that a new host can restore service.

User experience

  • Show current/latest control-plane, agent/CLI, proxy/runtime, OS, and schema versions with compatibility, release notes, security urgency, and update channel.
  • Upgrade plan lists nodes/components, preflight results, migrations, drain/restart/downtime, backup point, rollout batches, health gates, and rollback support.
  • Maintenance settings cover windows/timezones, automatic security patches, reboots, cleanup retention, disk thresholds, and exclusions.
  • Cleanup previews images, build cache, stopped containers, old releases, logs, temp files, and reclaimable bytes before deletion.
  • Recovery center shows last control-plane backup, restore drill, fleet/bootstrap artifacts, RPO/RTO evidence, and runbooks.

Scope

  • Implement signed update manifest/version check, compatibility policy, download verification, staged canary/batch rollout, health gates, pause/resume, and rollback where supported.
  • Complete provider/driver server update and hardening operations with reboot detection and maintenance coordination.
  • Add safe cleanup policies for deployment artifacts/releases, images/build cache, logs/events, temp files, and orphaned resources with ownership checks.
  • Back up and restore control-plane store, sanitized settings, user/org metadata, and non-secret references; document secret/backend/provider recovery dependencies.
  • Automate disaster-recovery drills that provision/adopt a replacement control plane/server, restore metadata/data, reconcile provider state, and validate representative services.

Technical direction

  • Use immutable versioned artifacts with signature/checksum verification and a tested compatibility matrix.
  • Snapshot control-plane data before migrations/upgrades and retain previous binaries/config sufficient for supported rollback.
  • Cleanup uses dry-run manifests, stable ownership tags, retention locks, and resumable deletion jobs.
  • Drills produce machine-readable evidence, timings, gaps, and cleanup records.

Safety and operability

  • Never self-update from an unsigned/unverified artifact or incompatible schema.
  • Rollouts drain capacity and maintain minimum healthy replicas/control-plane access.
  • Cleanup cannot rely on name patterns alone and must not delete active/pinned/unknown resources.
  • Recovery documentation includes lost credentials, lost host, corrupted store, provider outage, and failed migration paths.

Acceptance criteria

  • A patch upgrade can roll through a multi-server fleet in batches, pause on a failed health gate, and roll back supported components.
  • Cleanup reclaims only previewed eligible data and records exactly what changed.
  • A fresh control-plane instance can restore metadata, reconnect provider resources, and validate a service from documented backups.
  • A scheduled DR drill records measured RPO/RTO and actionable failures.

Verification

  • Manifest signature, version compatibility, migration backup, canary/batch, pause/resume, rollback, and failed-health tests.
  • Cleanup ownership/retention/pinned/active/orphan tests with dry-run parity.
  • Automated fresh-host control-plane restore and representative workload recovery drill.

Non-goals

  • Unattended major upgrades by default.
  • Guaranteeing OS rollback when the underlying distribution cannot provide it.
  • Deleting provider resources merely because they are unknown to the current store.

Sign in to comment on this issue.