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

Refinements to SSA matching #2028

Merged
merged 2 commits into from
Sep 22, 2023
Merged

Conversation

shawkins
Copy link
Collaborator

This highlights the state observed with kubernetes/kubernetes#118519

Note that the desired Secret uses stringData and the actual state after SSA references stringData as managed, but the resource is actually using data instead.

The matcher will currently throw an NPE when this occurs, so there's a minor change to allow it to continue - but it still of course sees this as a difference.

We know this occurs with Ingress as well - an empty path was being used in Keycloak because that is recommended in the openshift documentation when using the ImplementationSpecific pathType. If it's left in the spec, it gets pruned and that causes the matching logic to think there has been a change. However it does not seem necessary to use an empty path and so we removed that.

Some thoughts on how to handle this:

  • It is likely an api server bug, but it doesn't look like it will be resolved any time soon.
  • This situation, or anything involving pruning / modification of the apiServer state vs what's in the managed fields is problematic, and it won't be understood by the generic matcher either.
  • You could consider some type specific canonicalization logic (Secret conversion of stringData to data for example) - but automatically handling empty strings will likely be more problematic.
  • recommend or automatically install something like the MetadataAwareOnUpdateFilter when SSA is being used. Even if the update is issued this will filter out the update event because there will be no real changes in the new vs the old cache state. Of course this logic is extremely close to what's in the generic update matcher (just that status would be meaningful also) - so there is potential for reuse.

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 23, 2023
@csviri
Copy link
Collaborator

csviri commented Aug 25, 2023

The matcher will currently throw an NPE when this occurs, so there's a minor change to allow it to continue - but it still of course sees this as a difference.

Not sure if there is a good solution for this, except to handle this as a specific, case, and provide an implementation accordingly.

@csviri
Copy link
Collaborator

csviri commented Sep 6, 2023

I think this needs a rebase too :)

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 7, 2023
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 13, 2023
@shawkins shawkins changed the title shows what is happening with secrets that use stringdata and ssa generally prevent reconciliation loops with ssa Sep 13, 2023
@shawkins shawkins marked this pull request as ready for review September 13, 2023 12:38
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 13, 2023
@shawkins
Copy link
Collaborator Author

@csviri In double checking the statefulset and ingress issues that were highlighted previous in kubernetes issues, they do seem to be resolved with newer kubernetes versions wrt creating additional resource versions (they will still have match issues though).

I've refined this pr to do a couple of things:

  • localizes sanitation to ssa matcher. If possible it doesn't seem like the josdk should be explicitly setting fields in the spec that aren't part of the users desired state.
  • further ensures values won't be logged
  • will detect if a non-meaningful revision has been created

Copy link
Collaborator

@csviri csviri left a comment

Choose a reason for hiding this comment

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

Looks good to me, thank you!
except the missing tests. Could you add at least some unit test for the filter.

(We can think also some additional integration tests and feature flags, but that can be a separate PR

* <p>
* Several of these circumstances seem to have been addressed by ~1.25+
*/
public class MetadataAwareOnUpdateFilter<T extends HasMetadata> implements OnUpdateFilter<T> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually would be nice to have an IT for this. That shows the problem, and it is solved by this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've retested the issue seen with Secrets, Ingress, and StatefulSets on 1.26.3 - they no longer exhibit the behavior of creating an additional version. The upstream statefulset issue mentions a fix in 1.25. So this is really a fix to ensure there's no regressions or to support older Kube versions with SSA. Alternatively we could just document this rather than introducing this class.

Secrets and Ingress (with empty strings) though will still have matching issues, but this is a lesser problem as we're already excluding secrets from SSA and without the additional revision there won't be the loop behavior.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ahh, in that case, yes, it might be just enough to document it IMO.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But I guess the move of the sanitization still makes sense.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, narrowed this PR to not include the detection of meaningless additional revisions.

Copy link
Collaborator

Choose a reason for hiding this comment

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

thx, fine to merge this from my point

protected boolean useSSA(Context<P> context) {
if (this instanceof ResourceUpdaterMatcher) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we add a comment there as to why we deactivate SSA in that situation, please?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Tbh not sure that ResourceUpdateMatcher abstraction makes that much anymore. But we can discuss in an other PR

@shawkins shawkins requested a review from metacosm September 14, 2023 13:22
@metacosm
Copy link
Collaborator

@shawkins you need to sign your commits off with -s (or equivalent) now
A quick way to do so for all your commits is to do a git rebase --signoff HEAD~N and then force push.

@shawkins
Copy link
Collaborator Author

@shawkins you need to sign your commits off with -s (or equivalent) now

Yes, I've seen that. For some reason that box won't stay checked by default in eclipse.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 15, 2023
@csviri csviri force-pushed the next branch 2 times, most recently from 6d0fb7f to 5766e89 Compare September 18, 2023 13:55
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steve Hawkins <[email protected]>
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 21, 2023
@shawkins
Copy link
Collaborator Author

@metacosm @csviri rebased

@csviri
Copy link
Collaborator

csviri commented Sep 22, 2023

after rebase, we can merge also this imo

@shawkins
Copy link
Collaborator Author

shawkins commented Sep 22, 2023

after rebase, we can merge also this imo

Again? Is next being rebased against main frequently? Ah, this was due to the other pr being merged, not a general rebase. I'll update things.

@csviri csviri merged commit 2c50a83 into operator-framework:next Sep 22, 2023
csviri pushed a commit that referenced this pull request Oct 3, 2023
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steve Hawkins <[email protected]>
shawkins added a commit to shawkins/java-operator-sdk that referenced this pull request Oct 4, 2023
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steve Hawkins <[email protected]>
shawkins added a commit that referenced this pull request Oct 4, 2023
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steven Hawkins <[email protected]>
csviri pushed a commit that referenced this pull request Oct 4, 2023
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steven Hawkins <[email protected]>
csviri pushed a commit that referenced this pull request Oct 18, 2023
- localizes sanitation to ssa matcher
- further ensures values won't be logged

Signed-off-by: Steven Hawkins <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Check Issues with SSA Matcher discovered in Keycloak
4 participants