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

Bug 1863011: Fix checking if ClusterRoleBindings need update #932

Merged
merged 3 commits into from Sep 24, 2020

Conversation

paulfantom
Copy link
Contributor

@paulfantom paulfantom commented Sep 17, 2020

  • I added CHANGELOG entry for this change.
  • No user facing changes, so no entry in CHANGELOG was needed.

Fixing CRB re-creation checks by using the same logic as we have for RoleBindings.

@openshift-ci-robot openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. labels Sep 17, 2020
@openshift-ci-robot
Copy link
Contributor

@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
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

WIP: Bug 1863011: Do not use annotations for detecting if resource needs to be reconciled

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.

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 17, 2020
@paulfantom paulfantom changed the title WIP: Bug 1863011: Do not use annotations for detecting if resource needs to be reconciled WIP: Bug 1863011: Prevent unnecessary recreations of ClusterRoleBindings Sep 17, 2020
@openshift-ci-robot
Copy link
Contributor

@paulfantom: This pull request references Bugzilla bug 1863011, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

WIP: Bug 1863011: Prevent unnecessary recreations of ClusterRoleBindings

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 paulfantom force-pushed the rolebinidings branch 2 times, most recently from b96a7ec to 16813f9 Compare September 17, 2020 07:49
@paulfantom paulfantom changed the title WIP: Bug 1863011: Prevent unnecessary recreations of ClusterRoleBindings WIP: Bug 1863011: Do not compare annotations to detect if reconciliation is needed Sep 17, 2020
@paulfantom paulfantom changed the title WIP: Bug 1863011: Do not compare annotations to detect if reconciliation is needed WIP: Bug 1863011: Do not compare annotations to detect if recreation is needed Sep 17, 2020
@openshift-ci-robot
Copy link
Contributor

@paulfantom: This pull request references Bugzilla bug 1863011, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

WIP: Bug 1863011: Do not compare annotations to detect if recreation is needed

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)
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link

@sttts sttts Sep 17, 2020

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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)
}

@paulfantom
Copy link
Contributor Author

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 paulfantom changed the title WIP: Bug 1863011: Do not compare annotations to detect if recreation is needed Bug 1863011: Do not compare annotations to detect if recreation is needed Sep 17, 2020
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 17, 2020
@openshift-ci-robot
Copy link
Contributor

@paulfantom: This pull request references Bugzilla bug 1863011, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1863011: Do not compare annotations to detect if recreation is needed

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 paulfantom changed the title Bug 1863011: Do not compare annotations to detect if recreation is needed Bug 1863011: Fix checking if ClusterRoleBindings need update Sep 17, 2020
@openshift-ci-robot
Copy link
Contributor

@paulfantom: This pull request references Bugzilla bug 1863011, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.6.0) matches configured target release for branch (4.6.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1863011: Fix checking if ClusterRoleBindings need update

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
Copy link
Contributor Author

Fixing the annotation issue will be done as part of https://bugzilla.redhat.com/show_bug.cgi?id=1879930

@paulfantom paulfantom force-pushed the rolebinidings branch 2 times, most recently from da522f0 to fcef60a Compare September 23, 2020 13:41
@simonpasquier
Copy link
Contributor

Fixing CRB re-creation checks by using the same logic as we have for RoleBindings.

Looking at the code it seems that CreateOrUpdateRoleBinding should be updated too?

if reflect.DeepEqual(rb.RoleRef, r.RoleRef) &&
reflect.DeepEqual(rb.Subjects, r.Subjects) &&
reflect.DeepEqual(rb.Labels, r.Labels) &&
reflect.DeepEqual(rb.Annotations, r.Annotations) {
return nil
}

@paulfantom
Copy link
Contributor Author

Looking at the code it seems that CreateOrUpdateRoleBinding should be updated too?

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 CreateOrUpdateRoleBindings and rebased.

// 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
Copy link

@sttts sttts Sep 24, 2020

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.

Copy link

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@s-urbaniak
Copy link
Contributor

/lgtm once green

@s-urbaniak
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 24, 2020
reflect.DeepEqual(rb.Subjects, r.Subjects) &&
reflect.DeepEqual(rb.Labels, r.Labels) &&
reflect.DeepEqual(rb.Annotations, r.Annotations) {
mergo.Merge(&rb.Annotations, existing.Annotations)
Copy link

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.

Copy link

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

Copy link
Contributor Author

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.

Copy link

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.

Copy link
Contributor

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.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 24, 2020
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Sep 24, 2020
@s-urbaniak
Copy link
Contributor

/test e2e-aws-operator
/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 24, 2020
@s-urbaniak
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 24, 2020
@openshift-ci-robot
Copy link
Contributor

[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:
  • OWNERS [paulfantom,s-urbaniak]

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

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@paulfantom
Copy link
Contributor Author

/retest

@openshift-merge-robot openshift-merge-robot merged commit eb64b73 into openshift:master Sep 24, 2020
@openshift-ci-robot
Copy link
Contributor

@paulfantom: All pull requests linked via external trackers have merged:

Bugzilla bug 1863011 has been moved to the MODIFIED state.

In response to this:

Bug 1863011: Fix checking if ClusterRoleBindings need update

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.

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. bugzilla/severity-urgent Referenced Bugzilla bug's severity is urgent for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants