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

クローズ
  • 何か問題がありますか？
#3,270 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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.1k
フォーク
676
平均マージ
2日 2時間
マージ済み PR（30日）
538

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

agent-substrate/substrate のほかの issue

agent-substrate/substrate の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。