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

Move binding's namespace/name from work's label to work's annotation #752

Merged
merged 1 commit into from
Oct 9, 2021

Conversation

XiShanYongYe-Chang
Copy link
Member

@XiShanYongYe-Chang XiShanYongYe-Chang commented Sep 22, 2021

Signed-off-by: changzhen [email protected]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

The key of a label must be no more than 63 characters. When a binding object is generated, the name format is as follows: ${name}-${kind}, this may cause the length to exceed the limit.

The key of a annotation has no limits, so i move binding's namespace/name from work's label to work's annotation.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Following labels which previously added on the Work object now have been moved to annotations:
* `resourcebinding.karmada.io/namespace`
* `resourcebinding.karmada.io/name`
* `clusterresourcebinding.karmada.io/name`

@karmada-bot karmada-bot added the kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. label Sep 22, 2021
@karmada-bot karmada-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 22, 2021
@RainbowMango
Copy link
Member

RainbowMango commented Sep 23, 2021

Propoase a util:

// HasAnnotation tells if the 'annotation' contains the expected key-value pair.
func HasAnnotation(annotation map[string]string, expectKey string, expectValue string) bool {
	if annotation == nil {
		return false
	}

	value, exist := annotation[expectKey]
	if !exist {
		return false
	}

	return value == expectValue
}

@XiShanYongYe-Chang
Copy link
Member Author

Propoase a util:

// HasAnnotation tells if the 'annotation' contains the expected key-value pair.
func HasAnnotation(annotation map[string]string, expectKey string, expectValue string) bool {
	if annotation == nil {
		return false
	}

	value, exist := annotation[expectKey]
	if !exist {
		return false
	}

	return value == expectValue
}

Got it.

@RainbowMango
Copy link
Member

/assign @Garrybest @mrlihanbo @GitHubxsy
Please take a look. This is kind of an API change.

// GetWorkListByCRBName get works by ClusterResourceBinding name.
func GetWorkListByCRBName(c client.Client, name string) ([]workv1alpha1.Work, error) {
workList := &workv1alpha1.WorkList{}
err := c.List(context.TODO(), workList)
Copy link
Member

Choose a reason for hiding this comment

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

I'm afraid that it is potentially expensive that we list all RBs every time and range them to filter the matched ones when we have a lot of RBs. What about only moving names to annotations and leave namespace in labels? So we could list work by namespace label first. That will narrow work list.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good.

Copy link
Member Author

Choose a reason for hiding this comment

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

But separating namespaces and namespaces can be confusing. How do you think @RainbowMango

Copy link
Member

Choose a reason for hiding this comment

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

Can we have both the label and annotation? E.g.

diff --git a/pkg/apis/work/v1alpha1/well_known_labels.go b/pkg/apis/work/v1alpha1/well_known_labels.go
index 9cc3d813..657ad8cc 100644
--- a/pkg/apis/work/v1alpha1/well_known_labels.go
+++ b/pkg/apis/work/v1alpha1/well_known_labels.go
@@ -1,6 +1,15 @@
 package v1alpha1

 const (
+       // ResourceBindingReferenceKey is the key of ResourceBinding object.
+       // It is usually a unique hash value of ResourceBinding object's name and intended to be added to the Work object.
+       // It will be used to retrieve all Works objects that derived from a specific ResourceBinding object.
+       ResourceBindingReferenceKey = "resourcebinding.karmada.io/key"
+       // ClusterResourceBindingReferenceKey is the key of ClusterResourceBinding object.
+       // It is usually a unique hash value of ClusterResourceBinding object's name and intended to be added to the Work object.
+       // It will be used to retrieve all Works objects that derived by a specific ClusterResourceBinding object.
+       ClusterResourceBindingReferenceKey = "clusterresourcebinding.karmada.io/key"
+
        // ResourceBindingNamespaceLabel is added to objects to specify associated ResourceBinding's namespace.
        ResourceBindingNamespaceLabel = "resourcebinding.karmada.io/namespace"

The label is used to retrieve Work by RB/CRB and the annotation is used to retrieve RB/CRB by Work.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's greate. How do you think @Garrybest ?

If that's ok, i am going to modify with this command.

Copy link
Member

Choose a reason for hiding this comment

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

So we have both annotations and labels of resourcebinding in work? And the value is a unique hash value? I don't understand why annotations still need to be kept if we keep the labels. Could you give a example?

Copy link
Member

Choose a reason for hiding this comment

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

Good question.

resourcebindingNamespace, namespaceExist := labels[workv1alpha1.ResourceBindingNamespaceLabel]
resourcebindingName, nameExist := labels[workv1alpha1.ResourceBindingNameLabel]

The binding controller wants to enqueue Binding once the relevant Work is changed, in order to such as, grab status.

Copy link
Member

Choose a reason for hiding this comment

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

OK, let's do it.

@Garrybest
Copy link
Member

Oh I see. The annotation is used to record the namespace and name for finding the relevant RB of a work. And the hash label is used to select all relevant works of a RB quickly.

@Garrybest
Copy link
Member

/lgtm

@karmada-bot karmada-bot added the lgtm Indicates that a PR is ready to be merged. label Oct 8, 2021
@XiShanYongYe-Chang
Copy link
Member Author

Oh I see. The annotation is used to record the namespace and name for finding the relevant RB of a work. And the hash label is used to select all relevant works of a RB quickly.

That's true. :)

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.

Generally LGTM.
But since we missed the PR from v0.9.0, so the comments should be updated.

Delete this logic in the next release to prevent incompatibility when upgrading the current release (`v0.9.0`)

@karmada-bot karmada-bot removed the lgtm Indicates that a PR is ready to be merged. label Oct 9, 2021
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 Oct 9, 2021
@RainbowMango RainbowMango added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 9, 2021
@karmada-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

Approval requirements bypassed by manually added approval.

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 merged commit 093520b into karmada-io:master Oct 9, 2021
@XiShanYongYe-Chang XiShanYongYe-Chang deleted the move-work-label branch October 26, 2021 08:18
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/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants