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

OCPBUGS-17157: *: filter informers when preconditions are met #3021

Conversation

stevekuznetsov
Copy link
Member

*: 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 skuznets@redhat.com


depends on #3020

@openshift-ci-robot openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. labels Aug 28, 2023
@openshift-ci-robot
Copy link
Collaborator

@stevekuznetsov: This pull request references Jira Issue OCPBUGS-17157, which is valid.

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

Requesting review from QA contact:
/cc @jianzhangbjz

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

*: 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 skuznets@redhat.com


depends on #3020

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.

@@ -0,0 +1,106 @@
package labeller
Copy link
Contributor

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?

Copy link
Member Author

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.

},
}

func Validate(ctx context.Context, logger *logrus.Logger, metadataClient metadata.Interface) (bool, error) {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member Author

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 🤦

Copy link
Member Author

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.

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 <skuznets@redhat.com>
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
@tmshort
Copy link
Contributor

tmshort commented Sep 6, 2023

/retest

@stevekuznetsov
Copy link
Member Author

I can't get any of the fail-forward e2e tests to fail locally :|

Copy link
Contributor

@tmshort tmshort left a comment

Choose a reason for hiding this comment

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

/lgtm
Seems reasonable.

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 6, 2023
@openshift-ci
Copy link

openshift-ci bot commented Sep 6, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 6, 2023
@openshift-merge-robot openshift-merge-robot merged commit c0c61fe into operator-framework:master Sep 6, 2023
16 checks passed
@openshift-ci-robot
Copy link
Collaborator

@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 refresh.

Jira Issue OCPBUGS-17157 has not been moved to the MODIFIED state.

In response to this:

*: 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 skuznets@redhat.com


depends on #3020

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. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. 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

6 participants