fix: use SSA matcher to filter events#2749
Closed
shawkins wants to merge 1 commit intooperator-framework:mainfrom
Closed
fix: use SSA matcher to filter events#2749shawkins wants to merge 1 commit intooperator-framework:mainfrom
shawkins wants to merge 1 commit intooperator-framework:mainfrom
Conversation
closes: operator-framework#2249 Signed-off-by: Steve Hawkins <shawkins@redhat.com>
openshift-ci
bot
added
the
do-not-merge/work-in-progress
Collaborator
Author
|
Given our other discussions, this is not worth persuing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes: #2249
Seeing the recent #2742, I was wondering about revisiting #2249. One thought shown roughly here is that if we use the SSA matcher to compare the new / old. If it matches, then the change may not be meaningful as it didn't touch an owned field. Any normalization that kubernetes does wouldn't cause false positives here.
It's currently wired in dubiously - it probably would need to be done somehow via SSA enabled KubernetesDependentResources adding a filter to their informer event sources - which could make this independent of using the previous annotation.
When won't this work:
The only ways to workaround that I can think of would be to declare what non-owned state you care about and to track if we are behind on reconciling a resource - however these additional complexities may not be worth it.