Skip to content

kars upgrade recovery: in-cluster context ConfigMap, pending-release unstick, and --repair #472

Description

@pallakatos

Follow-up from the kars-upgrade-flow review.

For a cluster broken by a previous buggy CLI, remaining recovery gaps:

  1. Context bound to one machine: kars upgrade aborts without ~/.kars/context.json and tells you to 'run from the machine that deployed the cluster' — single point of failure for a team-operated product. Reconstruct context from a controller-owned ConfigMap (kars-system/kars-release: acrLoginServer, aksCluster, resourceGroup, foundryEndpoint, deployed release) so any authorized operator can upgrade/rollback from anywhere. This also gives version detection a visible, coupled home (vs the current 'dead' karsRelease Helm value).
  2. Stuck Helm release: kars up cleans pending-install secrets; kars upgrade has no equivalent. A pending-upgrade/failed release makes helm upgrade --atomic abort with 'another operation in progress' and no in-tool unstick. Add the same cleanup / helm rollback-to-last-deployed before the atomic upgrade.
  3. No --repair: add an idempotent 'put me back exactly on the version I'm supposed to be on' path (re-import current marker's images + re-apply + restart, skipping the version compare).
  4. Downgrade safety: a stale version marker could silently move a security runtime backwards; consider requiring an explicit, loud --allow-downgrade.

Severity: P1/P2 (reliability/recovery).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions