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
Bug 1863011: Fix checking if ClusterRoleBindings need update #932
Bug 1863011: Fix checking if ClusterRoleBindings need update #932
Conversation
@paulfantom: This pull request references Bugzilla bug 1863011, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
@paulfantom: This pull request references Bugzilla bug 1863011, which is valid. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
b96a7ec
to
16813f9
Compare
@paulfantom: This pull request references Bugzilla bug 1863011, which is valid. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
@@ -1106,7 +1105,6 @@ func (c *Client) CreateOrUpdateClusterRoleBinding(crb *rbacv1.ClusterRoleBinding | |||
changed := reflect.DeepEqual(crb.RoleRef, existing.RoleRef) | |||
changed = changed || reflect.DeepEqual(crb.Subjects, existing.Subjects) | |||
changed = changed || reflect.DeepEqual(crb.Labels, existing.Labels) | |||
changed = changed || reflect.DeepEqual(crb.Annotations, existing.Annotations) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we have to be a little smarter. If we just ignore the annotations then it is fine, but I think we have to preserve the existing annotations of the object that was found, aka crb.Annotations = existing.Annotations
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @sttts @p0lyn0mial for verification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could "merge" the annotation map instead of ignoring it.
please have a look at https://github.com/openshift/library-go/blob/master/pkg/operator/resource/resourceapply/rbac.go#L58 this is what we use in our operators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either merging, or restrict deep equal to the annotation "subdomain" you own, e.g. monitoring.openshift.io. But you have to allow everything else without wiping it, e.g. important.customer.com/foo: bar
. It's allowed for every actor to put annotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@p0lyn0mial in case of merging annotations, should we follow the same pattern you have of merging whole ObjectMeta? Is there any benefit to such approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't merge the whole ObjectMeta, just only a few things
func EnsureObjectMeta(modified *bool, existing *metav1.ObjectMeta, required metav1.ObjectMeta) {
SetStringIfSet(modified, &existing.Namespace, required.Namespace)
SetStringIfSet(modified, &existing.Name, required.Name)
MergeMap(modified, &existing.Labels, required.Labels)
MergeMap(modified, &existing.Annotations, required.Annotations)
}
Seems like we had an incorrect logic for checking if CRB needs a change. The last commit fixes it by porting logic used in RB to do the same |
@paulfantom: This pull request references Bugzilla bug 1863011, which is valid. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
aa7b164
to
9229c02
Compare
@paulfantom: This pull request references Bugzilla bug 1863011, which is valid. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
Fixing the annotation issue will be done as part of https://bugzilla.redhat.com/show_bug.cgi?id=1879930 |
da522f0
to
fcef60a
Compare
Looking at the code it seems that cluster-monitoring-operator/pkg/client/client.go Lines 1056 to 1061 in 40bb0e8
|
fcef60a
to
ca45dd1
Compare
Yes, but we also have another BZ to fix this for all resources: https://bugzilla.redhat.com/show_bug.cgi?id=1879930. That said I updated |
ddb43f9
to
9e92f35
Compare
pkg/client/client.go
Outdated
// TODO(paulfantom): currently, we don't set our own annotations for cluster role bindings. | ||
// This needs a more elaborated merging logic once we do. | ||
// See discussion from https://github.com/openshift/cluster-monitoring-operator/pull/932#discussion_r490089300 | ||
rb.Annotations = r.Annotations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens when you set your own annoations? Having a time bomb known to fail without unit tests or other means to tell is not a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't annotation merge logic simple enough to just do it here rather than adding two TODOs plus those "means" I mention above? Seems like time well spend to make it correct once and for all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are aware and I am working on a fix for this in a follow-up BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1879930. Fix would be applied to all resources, not only CRB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My 2 cents: if the merging logic is not too much effort, I'd pull it in as @sttts suggests. especially given the fact that 4.6 is going to be an LTS release.
@paulfantom do you estimate how much effort it would mean to pull in merging for cluster-role-bindings/role-bindings only? I agree that tackling all the other resources can be done separately as they don't seem to suffer the issue we're observing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I added merging Annotations for RBs and CRBs. Other resources will be done in follow-up PR.
I am re-using github.com/imdario/mergo
for merging as we already have it in vendor
due to transitive dependency on k8s/client-go.
9e92f35
to
e3a2030
Compare
e3a2030
to
69d7294
Compare
/lgtm once green |
/lgtm |
reflect.DeepEqual(rb.Subjects, r.Subjects) && | ||
reflect.DeepEqual(rb.Labels, r.Labels) && | ||
reflect.DeepEqual(rb.Annotations, r.Annotations) { | ||
mergo.Merge(&rb.Annotations, existing.Annotations) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this won't remove old annotations. Is that ok?
At least this must be godoc'ed on this func.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this mutates rb.Annotation.
/hold
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this won't remove old annotations. The goal was to merge old/existing ones with what is defined by the operator.
Since rb
and crb
is what we hardcode in operator, mutating rb.Annotation
is how we can update whole object with added Annotations.
I have added a comment to reflect that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is very bad style to have side-effects in such a function, especially when named CreateOrUpdateRoleBinding
. None of the upstream client funcs does that for a reason. This func should not divert. It is even dangerious if it does because consumers will not expect it and potentially invalidate objects from a cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree here, for the caller this is unexpected. @paulfantom let's make sure we address this in the follow-up. An easy way forward would be to create a deep copy of rb
.
69d7294
to
b4446f3
Compare
b4446f3
to
f65020b
Compare
/test e2e-aws-operator |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: paulfantom, s-urbaniak 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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest |
@paulfantom: All pull requests linked via external trackers have merged: Bugzilla bug 1863011 has been moved to the MODIFIED state. In response to this:
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/test-infra repository. |
Fixing CRB re-creation checks by using the same logic as we have for RoleBindings.