Skip to content

Read the DatastoreMigration CRD at v1 - #5127

Merged
caseydavenport merged 9 commits into
tigera:masterfrom
caseydavenport:casey-migration-crd-v1
Aug 10, 2026
Merged

Read the DatastoreMigration CRD at v1#5127
caseydavenport merged 9 commits into
tigera:masterfrom
caseydavenport:casey-migration-crd-v1

Conversation

@caseydavenport

@caseydavenport caseydavenport commented Jul 30, 2026

Copy link
Copy Markdown
Member

Description

The DatastoreMigration CRD moves to migration.projectcalico.org/v1 in Calico v3.33, and the v3.33 CRD serves v1beta1 (deprecated) alongside v1 (storage). There's no single version the operator can hardcode and be right on every cluster, so it now resolves the served version from discovery at startup, preferring v1 and falling back to v1beta1. That version is used for:

  • scheme registration
  • the startup check for an already-migrated cluster
  • both controller watches

Get it wrong and the watch never becomes ready, the migration phase reads as empty, and the apiserver controller re-creates the aggregated APIService while the migration is deleting it.

An earlier version of this PR assumed an upgraded v3.32 cluster had no CR left to watch, since applying the new CRD meant deleting the old one. Deleting the CRD runs the migration finalizer for real, which is why the new CRD serves both versions instead.

Related: CORE-12573

None

The group/version was hardcoded in five places. Derive them all from
SchemeGroupVersion (now v1) so the next bump is a one-liner.

checkDatastoreMigration falls back to v1beta1 on NotFound, because a
cluster that migrated on v3.32 would otherwise be misread as
unmigrated: the v1 lookup misses, discovery still sees both API
groups, and UseV3CRDS answers "use v1 CRDs".
Drop a redundant nil check, make legacyDatastoreMigrationGVR a var
for symmetry with datastoreMigrationGVR, and fix a comment that
implied deleting the DatastoreMigration CR removes the crd.projectcalico.org
CRDs (it doesn't, they're independent). Also updates checkDatastoreMigration's
doc comment to mention the v1beta1 fallback, and switches the fallback
test's injected error to NewGenericServerResponse so it matches the 404
shape the real apiserver produces instead of a Status-shaped NotFound.

Adds a comment on the installation and apiserver controllers' watch
registration explaining why it's v1-only with no v1beta1 fallback:
upgrading a v3.32-migrated cluster requires deleting the old CRD
first, which cascades to the DatastoreMigration CR, so there's no CR
left to watch after a supported upgrade.
@caseydavenport
caseydavenport force-pushed the casey-migration-crd-v1 branch from ace1e63 to ac66c89 Compare July 30, 2026 22:44
Calico v3.33 serves the CRD at both v1 and v1beta1, so read whichever version the cluster has rather than hardcoding one.
Drops the assumption that an upgraded v3.32 cluster has no CR left to watch.
Comment thread pkg/controller/migration/datastoremigration/version.go Outdated
Comment thread pkg/controller/migration/datastoremigration/version.go Outdated
Resolving once at startup pinned the operator to v1, so a CRD installed later
at v1beta1 left the watch waiting on a version the cluster never serves.
Comment thread pkg/controller/migration/datastoremigration/version.go
client.Object already provides GetName/GetNamespace, and unstructured objects
don't implement ObjectMetaAccessor.
@caseydavenport
caseydavenport merged commit fac018e into tigera:master Aug 10, 2026
5 of 6 checks passed
@caseydavenport
caseydavenport deleted the casey-migration-crd-v1 branch August 10, 2026 22:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants