Skip to content

fix: make ManagementClusterClassifierReconciler shard-aware - #514

Merged
gianlucam76 merged 1 commit into
projectsveltos:mainfrom
gianlucam76:mgmtclassifier-shard
Sep 16, 2026
Merged

gianlucam76 merged 1 commit into
projectsveltos:mainfrom
gianlucam76:mgmtclassifier-shard

Conversation

@gianlucam76

Copy link
Copy Markdown
Member

ManagementClusterClassifierReconciler never checked ShardKey, unlike ClassifierReconciler.
In fv-sharding (two classifier-manager deployments, default + shard1), both instances reconciled the same ManagementClusterClassifier and raced to update labels on the same Cluster object. That caused the "multi-GVK requirement" FV test to time out waiting for labels to be removed after CR deletion.

This PR fixes that. When ShardKey is set, no-op immediately, same as ClassifierReconciler already does. This resource is evaluated entirely against the management cluster itself, so sharded deployments have no role to play for it.

`ManagementClusterClassifierReconciler` never checked `ShardKey`, unlike
`ClassifierReconciler`.
In `fv-sharding` (two classifier-manager deployments, default + shard1),
both instances reconciled the same `ManagementClusterClassifier` and raced
to update labels on the same Cluster object. That caused the
"multi-GVK requirement" FV test to time out waiting for labels to be removed
after CR deletion.

This PR fixes that. When `ShardKey` is set, no-op immediately, same as
`ClassifierReconciler` already does. This resource is evaluated entirely
against the management cluster itself, so sharded deployments have no
role to play for it.
@gianlucam76
gianlucam76 merged commit 3bc7fa3 into projectsveltos:main Sep 16, 2026
9 checks passed
@gianlucam76
gianlucam76 deleted the mgmtclassifier-shard branch September 16, 2026 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant