-
Notifications
You must be signed in to change notification settings - Fork 545
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
OCPBUGS-17157: *: filter informers when preconditions are met #3021
OCPBUGS-17157: *: filter informers when preconditions are met #3021
Conversation
@stevekuznetsov: This pull request references Jira Issue OCPBUGS-17157, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: 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 kubernetes/test-infra repository. |
96cca36
to
5b069d3
Compare
@@ -0,0 +1,106 @@ | |||
package labeller |
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.
should we add some unit tests around this package?
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 would you like to see? I held off since most of the logic in here is very thin implementation on top of client calls and seemed like it could be validated by inspection.
5b069d3
to
488a1b6
Compare
}, | ||
} | ||
|
||
func Validate(ctx context.Context, logger *logrus.Logger, metadataClient metadata.Interface) (bool, error) { |
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.
Will it be safe to remove this check at some point, e.g. after we know everything has been labeled?
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, whenever we are at a version where all upgrade paths have gone through some state that has the labeling controller in, we can remove this precondition, the label controllers, etc, and just filter by default.
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.
Would it be useful to place a sentinel ConfigMap somewhere that indicates 100% labeling, and check for that, so we don't have to list all the things each time we startup?
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.
There's no capital C consistent way to ensure that is always correct, since storage can be sharded by resource. We're only doing partial object metadata lists here, so I think it should be ok?
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.
Actually ... for Jobs we need the spec 🤦
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.
Found a workaround for jobs that does not need the spec.
488a1b6
to
51f2ba5
Compare
When we can detect at startup time that all of the objects we're about to look at have the labels we're expecting, we can filter our informer factories upfront. Signed-off-by: Steve Kuznetsov <[email protected]>
Signed-off-by: Steve Kuznetsov <[email protected]>
51f2ba5
to
76b6873
Compare
/retest |
I can't get any of the fail-forward e2e tests to fail locally :| |
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.
/lgtm
Seems reasonable.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: stevekuznetsov, tmshort 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 |
c0c61fe
into
operator-framework:master
@stevekuznetsov: Jira Issue OCPBUGS-17157: Some pull requests linked via external trackers have merged:
The following pull requests linked via external trackers have not merged: These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with Jira Issue OCPBUGS-17157 has not 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. |
*: filter informers when preconditions are met
When we can detect at startup time that all of the objects we're about
to look at have the labels we're expecting, we can filter our informer
factories upfront.
Signed-off-by: Steve Kuznetsov [email protected]
depends on #3020