Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge labels when building RB/CRB by ClusterPropagationPolicy #3239

Merged
merged 1 commit into from
Mar 13, 2023

Conversation

lxtywypc
Copy link
Contributor

@lxtywypc lxtywypc commented Mar 6, 2023

What type of PR is this?

/kind bug

What this PR does / why we need it:
Merge labels in (cluster)resourcebinding when the binding is modifying no matter which kind of propagationpolicy is bind with.

Which issue(s) this PR fixes:
Fixes #3238

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmada-controller-manager`: Fixed the issue that RB/CRB labels are not merged when syncing new changes. 

Signed-off-by: lxtywypc <lxtywypc@gmail.com>
@karmada-bot karmada-bot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 6, 2023
@karmada-bot karmada-bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Mar 6, 2023
@@ -523,7 +523,7 @@ func (d *ResourceDetector) ApplyClusterPolicy(object *unstructured.Unstructured,
"try again later after binding is garbage collected, see https://github.com/karmada-io/karmada/issues/2090")
}
// Just update necessary fields, especially avoid modifying Spec.Clusters which is scheduling result, if already exists.
bindingCopy.Labels = binding.Labels
bindingCopy.Labels = util.DedupeAndMergeLabels(bindingCopy.Labels, binding.Labels)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we don't need to modify this line, because we don't currently support cluster scope resources for the dependency distribution feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, this is not just for the dependency distribution feature, but customized labels as well.
For example, if we have a webhook which would patch some custmized info into the labels of resourcebindings to group them, after I scale the workload once, the info would be lost.
This might not be a good example, but I think even if it is a label for temporary usage, we shouldn't abandon them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable., and it doesn't seem to hurt.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should add some E2E to protect this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Humm......I think it is nice to have.
I hope to help add some.
May I commit them in this PR? Or open a new one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks~

Copy link
Member

@RainbowMango RainbowMango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/assign

@RainbowMango
Copy link
Member

/retitle merge labels when building RB/CRB by ClusterPropagationPolicy

@karmada-bot karmada-bot changed the title merge labels when modifying whichever binding with whichever propagationpolicy merge labels when building RB/CRB by ClusterPropagationPolicy Mar 13, 2023
@RainbowMango
Copy link
Member

Hi @XiShanYongYe-Chang
Could you please open another issue to track the E2E tasks? Given @lxtywypc is a first-time contributor who might feel hard to involve the E2E, I'd like to move this forward because seems no much risk here.

@RainbowMango
Copy link
Member

@lxtywypc Is there anything bad that happened due to this issue? After going through the analysis in #3238, I think this is more like an improvement in stead of a bug, which means we don't need to cherry-pick it to previous releases.

@XiShanYongYe-Chang
Copy link
Member

Hi @XiShanYongYe-Chang
Could you please open another issue to track the E2E tasks? Given @lxtywypc is a first-time contributor who might feel hard to involve the E2E, I'd like to move this forward because seems no much risk here.

Done, refer to #3265

Hi @lxtywypc, you can sign it to you by the command /assign and send a new pr to do it, thanks~

Copy link
Member

@RainbowMango RainbowMango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@karmada-bot karmada-bot added the lgtm Indicates that a PR is ready to be merged. label Mar 13, 2023
@karmada-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@karmada-bot karmada-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 13, 2023
@karmada-bot karmada-bot merged commit 31435bf into karmada-io:master Mar 13, 2023
@lxtywypc lxtywypc deleted the merge-lables branch August 2, 2023 03:54
zach593 pushed a commit to ctripcloud/karmada that referenced this pull request Oct 12, 2023
merge labels when building RB/CRB by ClusterPropagationPolicy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When Modifying (Cluster)ResourceBinding, Labels Was Merged Only When Binding with PropagationPolicy
4 participants