ate-setup deploy ate-system fails on in-place upgrade when v1alpha1 CRDs exist (storedVersions: ["v1alpha1"] missing from spec.versions)

Chiusa
  • Qualcosa non va?
#3,270 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
backend-api-design, infrastructure

Direzione di ricerca

Read cmd/ate-setup/internal/steps/deploy.go at DeployCRDs and inspect the three generated CRDs named in the issue. First reproduce the upgrade failure using the supplied kubectl commands and go run ./cmd/ate-setup deploy ate-system. Done means an in-place upgrade succeeds while preserving existing custom resources; the issue describes keeping the old version during migration or migrating stored objects before removing it.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area/api-machinery area/dev-infra kind/bug
Summary & Root Cause

Commit 48f5744c replaced name: v1alpha1 with name: v1 in the generated CRDs and did not keep v1alpha1 as a served-false, storage-false version. A cluster installed before that change has status.storedVersions: ["v1alpha1"] on workerpools.ate.dev, sandboxconfigs.ate.dev and csidriverconfigs.ate.dev. The API server refuses any CRD update that drops a version still listed in storedVersions. DeployCRDs just re-applies the generated manifests and has no migration step (no StorageVersionMigration, no storedVersions rewrite), so the upgrade fails at the first step.

Affected Code Locations
  • manifests/ate-install/generated/ate.dev_workerpools.yaml:32, 52, 632-633 (single version v1, served: true, storage: true)
  • manifests/ate-install/generated/ate.dev_sandboxconfigs.yaml:43 (single version name: v1)
  • manifests/ate-install/generated/ate.dev_csidriverconfigs.yaml:40 (single version name: v1)
  • cmd/ate-setup/internal/steps/deploy.go:666-676 (DeployCRDs: applies generated with no storage-version handling)
  • Commit 48f5744c ("Move public APIs under api/<api-name>/v1", #2996) renamed the CRD version v1alpha1 → v1 in place, with no transitional v1alpha1 entry.
Detailed Reproduction Guide

  1. On a cluster where a CRD was created with v1alpha1 as its storage version (simulated on a fresh cluster by applying a v1alpha1-only workerpools.ate.dev before the first deploy), confirm:

    kubectl get crd workerpools.ate.dev -o jsonpath='{.status.storedVersions}'

  2. Run the deploy:

    go run ./cmd/ate-setup deploy ate-system

  3. Control: delete the CRD and deploy again:

    kubectl delete crd workerpools.ate.dev
go run ./cmd/ate-setup deploy ate-system
Expected vs. Actual Behavior
  • Expected: deploy ate-system upgrades CRDs in place, either by keeping v1alpha1 in spec.versions with served: false, storage: false until storage is migrated, or by migrating objects and trimming status.storedVersions before applying the new CRD.
  • Actual: The deploy fails immediately at [step]: deploy_crds. It only succeeds after the operator deletes the custom resources and CRDs by hand, which destroys every WorkerPool and SandboxConfig.
Observed Output & Logs
  [step]: deploy_crds
  Error: while applying customresourcedefinition/workerpools.ate.dev: CustomResourceDefinition.apiextensions.k8s.io "workerpools.ate.dev" is invalid: status.storedVersions[0]: Invalid value: "v1alpha1": missing from spec.versions; v1alpha1 was previously a storage version, and must remain in spec.versions ...
  versions after DeployCRDs: v1alpha1

  [step]: deploy_crds
  Error: ... status.storedVersions[0]: Invalid value: "v1alpha1": missing from spec.versions
Lingua principale
Go
Stelle
6.1k
Fork
676
Merge medio
2g 41m
PR unite (30g)
500

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di agent-substrate/substrate

Tutte le issue di agent-substrate/substrate

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.