-
Notifications
You must be signed in to change notification settings - Fork 553
olm,catalog: only validate the resources we label #3165
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
olm,catalog: only validate the resources we label #3165
Conversation
Signed-off-by: Steve Kuznetsov <[email protected]>
Each controller can see (and, therefore, can label) a separate set of GVRs. When we start up, detecting if any OLM-related resource needs labelling means that one controller may start, detect a need for labelling a resource it cannot itself label, detect that it's labelled everything it can, and restart. If the other operator is stuck for whatever reason, this leads the first controller to enter CrashLoopBackOff and break OCP upgrade. Signed-off-by: Steve Kuznetsov <[email protected]>
d2f8939
to
3f66a69
Compare
@stevekuznetsov: This pull request references Jira Issue OCPBUGS-28744, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. 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 openshift-eng/jira-lifecycle-plugin repository. |
@stevekuznetsov: No Jira issue is referenced in the title of this pull request. 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 openshift-eng/jira-lifecycle-plugin repository. |
@stevekuznetsov I removed the downstream jira from the title of this upstream PR |
LGTM. Probably need to investigate e2e failures to see if they're flakes or due to this PR. @joelanford PTAL at the PR - thx |
6a49102
to
04231c1
Compare
Signed-off-by: Steve Kuznetsov <[email protected]>
04231c1
to
da9593a
Compare
Still LGTM. Joe? |
Can't grok how that could be our fault |
if ref.Kind == ownerRef.Kind && ref.Name == ownerRef.Name && ref.UID == ownerRef.UID { | ||
return | ||
} |
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.
Is there any chance that we call this function with the same object, but with different blockOwnerDeletion or isController values?
Curious if we find the owner ref, rather than leaving what's there untouched, we should update what's there?
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 don't believe the codebase does any of that today. Generally speaking I would not expect isController
to be something that logically could change.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: joelanford, stevekuznetsov 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 |
*: don't duplicate owner references
Signed-off-by: Steve Kuznetsov [email protected]
olm,catalog: only validate the resources we label
Each controller can see (and, therefore, can label) a separate set of
GVRs. When we start up, detecting if any OLM-related resource needs
labelling means that one controller may start, detect a need for
labelling a resource it cannot itself label, detect that it's labelled
everything it can, and restart. If the other operator is stuck for
whatever reason, this leads the first controller to enter
CrashLoopBackOff and break OCP upgrade.
Signed-off-by: Steve Kuznetsov [email protected]