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

Cerrado
  • ¿Algo no está bien?
#3,270 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
backend-api-design, infrastructure

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
6.1k
Forks
676
Merge medio
2 d 1 h
PR fusionados (30 d)
481

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agent-substrate/substrate

Todos los issues de agent-substrate/substrate

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.