Read the DatastoreMigration CRD at v1 - #5127
Merged
caseydavenport merged 9 commits intoAug 10, 2026
Merged
Conversation
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
force-pushed
the
casey-migration-crd-v1
branch
from
July 30, 2026 22:44
ace1e63 to
ac66c89
Compare
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.
MichalFupso
reviewed
Aug 7, 2026
MichalFupso
reviewed
Aug 7, 2026
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.
MichalFupso
reviewed
Aug 10, 2026
client.Object already provides GetName/GetNamespace, and unstructured objects don't implement ObjectMetaAccessor.
MichalFupso
approved these changes
Aug 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The DatastoreMigration CRD moves to
migration.projectcalico.org/v1in 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: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