Gen3 Admin Updates - GT-Edge-AI/GT-AI-OS GitHub Wiki

Updates

Start Here

  1. Open Updates in the Control Panel sidebar.
  2. In interim builds where UPDATES_UX_ENABLED is false, expect an under development placeholder—in-control-panel deployment update orchestration is not yet generally available in the UI.
  3. For host-level upgrades today, use the Self-Hosted Updating runbook or your GitOps release process instead of the Control Panel placeholder.
  4. When the workspace is enabled in a future release, confirm Backup & Restore posture when required, then follow the request-and-approve workflow (see appendix below).

Why this matters

Updates orchestrate immutable GT AI OS release changes through a request-and-approve workflow so the Control Panel web pod never receives direct deploy privileges. Until that workspace ships, operators need a clear alternative upgrade path and an accurate picture of what the placeholder shows versus the finished UI.

Details

Updates is the Gen 3 Control Panel route for deployment update orchestration.

Under development (interim builds)

When UPDATES_UX_ENABLED is false (current interim posture), the page shows an under development placeholder instead of deployment state, target version selection, and approval controls. The sidebar entry remains visible; the shipped experience is a status callout, not a working update console.

Do not assume the placeholder page can create update requests or approve rollbacks.

Interim release channel (when enabled)

When the workspace is enabled and you select an interim release target, the page surfaces release metadata beyond standard release notes:

  • Maintenance warning — prominent copy when the release publishes a maintenanceWarning (for example "not for production").
  • Unfinished features — bullet list of known incomplete UX or feature-flagged areas shipped with that interim build.
  • Known bugs — bullet list of documented defects operators should expect.

Review these lists before approving an interim upgrade. Stable-channel releases follow the same version picker but omit interim-only gap and bug inventories unless published in release notes.

Control Panel Updates workspace

Appendix: When the workspace is enabled

The sections below describe the intended Control Panel workflow once UPDATES_UX_ENABLED is true. They do not apply while the under-development placeholder is shown.

Access

Only super admins can create update requests, approve pending requests, or request rollbacks. Other signed-in operators can review state in read-only posture.

The page loads runtime state, eligible release targets, the latest update request, progress events, and optional storage preflight results. It refreshes automatically every five seconds.

Deployment state

The top card summarizes:

Field Meaning
Current version Immutable release currently running in the deployment namespace
Previous version Recorded rollback target used when a post-deploy gate fails
Release contract Shared chart path and values model for CLI, Control Panel, and GitOps workflows

Each card also notes the deployment namespace and execution mode reported by the runtime API.

Available versions

Use the Target version dropdown to pick a compatible release newer than the current version. When no compatible targets exist, the selector shows No compatible target versions.

For the selected release, the page shows:

  • chart version
  • release channel (stable or interim)
  • release notes (or a note when none are published)
  • maintenance warning text when the release publishes one
  • Unfinished features and Known bugs lists when the channel is interim and the release metadata includes them

Backup warning override

When the runtime reports an active backup preflight warning that can be bypassed, the page shows a Backup warning callout with summary, detail, and last-check timestamp. You must check I understand this update will continue without requiring a pre-update backup before Update anyway becomes valid.

Without an active bypassable warning, the primary action label is Create update request.

Primary actions

Action When it applies
Create update request / Update anyway Starts a new update request for the selected target version
Request rollback Creates a rollback request to the recorded previous version

Update and rollback requests use client-generated idempotency keys so repeated clicks do not create duplicate in-flight requests for the same action and target.

Current request

When a request exists, this section shows:

  • request status badge (for example Pending approval, Running, Waiting for GitOps, Succeeded, Failed, Rollback running)
  • action direction from current version to target version
  • current step and attempt count
  • execution mode and last error when present

Approve request is enabled only while status is Pending approval and you are a super admin.

If the request was created with a backup warning override, a note explains that approval will continue without requiring a pre-update backup.

Storage preflight

When the API attaches storage-capacity results, a nested card shows:

  • capacity status (available or blocked)
  • additional required storage and schedulable capacity
  • CNPG PVC contract volumes
  • blocking reason or probe error when preflight failed
  • remediation bullet list when provided

Progress log

The progress table lists timestamped step events with step name, status, and summary or detail text.

When no requests exist yet, the section states that no deployment update requests have been created.

Recommended workflow (when enabled)

  1. Confirm current and previous versions on Deployment state.
  2. Pick the target release and read release notes, maintenance warnings, and (for interim) unfinished features and known bugs.
  3. Resolve any backup warning or acknowledge the override deliberately.
  4. Create the update request.
  5. Approve the request when it reaches Pending approval.
  6. Watch the progress log through completion.
  7. Use Request rollback only when you intend to return to the recorded previous version.

Best practices (when enabled)

  • Treat backup warnings as operator signals, not cosmetic copy.
  • Do not approve a request until storage preflight and backup posture match your change window.
  • Read interim Unfinished features and Known bugs before approving non-production interim cuts.
  • Use rollback against the recorded previous version rather than inventing ad hoc targets in other tools.
  • Coordinate with Backup & Restore before major upgrades when pre-update backups are required.

Related pages