[officialasishkumar]

Summary

When a label is both a PartitionSet dimension and a key of spec.shardSelector.matchLabels, partition() appended it twice to the list of labels used to build the partition key (e.g. +region=eu+region=eu). The key for an existing Partition is computed from its matchLabels map and can only be +region=eu, so it never matched. Every reconciliation therefore deleted the existing Partition and created a new one. The resulting events requeued the PartitionSet, and the delete/create loop never stopped.

This PR builds the label list from a set, so each label is only considered once. sets.List returns the labels sorted, which keeps the key ordering the comparison depends on.

Tests:

• TestPartition now checks the exact keys produced when dimensions and selector matchLabels overlap.
• TestReconcile gains Existing partition kept with selector and dimension overlapping. It checks that an existing matching Partition is neither deleted nor recreated. The existing overlap case only covered the first reconcile, when no Partition exists yet. Without the fix, both new assertions fail: the existing partition is deleted and two partitions are created instead of one.

Manual check with a local kcp start -v=2: I created a shard labelled region: eu and a PartitionSet with dimensions: [region] and shardSelector.matchLabels: {region: eu}.

• Before: the partition name kept changing, and about 7,600 creating partition/deleting partition log lines appeared within 45s.
• After: one Partition (regions-eu-…) was created and stayed unchanged, with a single creating partition log line.

What Type of PR Is This?

/kind bug

Related Issue(s)

Fixes #4549

Release Notes

Fix the PartitionSet controller endlessly deleting and recreating Partitions when a dimension is also part of the shard selector matchLabels.

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign gman0 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kcp-ci-bot]

Hi @officialasishkumar. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.