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

已关闭
  • 哪里不对？
#3,270 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go, kubernetes
领域
backend-api-design, infrastructure

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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
主要语言
Go
星标
6.4k
派生
720
平均合并
1 天 18 小时
30 天内合并 PR
413

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

agent-substrate/substrate 的其他 Issue

查看 agent-substrate/substrate 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。