-
Notifications
You must be signed in to change notification settings - Fork 218
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
Conversation
Not sure if there is a good solution for this, except to handle this as a specific, case, and provide an implementation accordingly. |
...io/javaoperatorsdk/operator/processing/dependent/kubernetes/MetadataAwareOnUpdateFilter.java
Outdated
Show resolved
Hide resolved
2bdd8f9
to
e9c2639
Compare
I think this needs a rebase too :) |
@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:
|
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.
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
...io/javaoperatorsdk/operator/processing/dependent/kubernetes/MetadataAwareOnUpdateFilter.java
Outdated
Show resolved
Hide resolved
...io/javaoperatorsdk/operator/processing/dependent/kubernetes/MetadataAwareOnUpdateFilter.java
Outdated
Show resolved
Hide resolved
...io/javaoperatorsdk/operator/processing/dependent/kubernetes/MetadataAwareOnUpdateFilter.java
Outdated
Show resolved
Hide resolved
* <p> | ||
* Several of these circumstances seem to have been addressed by ~1.25+ | ||
*/ | ||
public class MetadataAwareOnUpdateFilter<T extends HasMetadata> implements OnUpdateFilter<T> { |
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 would be nice to have an IT for this. That shows the problem, and it is solved by this.
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'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.
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.
Ahh, in that case, yes, it might be just enough to document it IMO.
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.
But I guess the move of the sanitization still makes sense.
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.
Ok, narrowed this PR to not include the detection of meaningless additional revisions.
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.
thx, fine to merge this from my point
protected boolean useSSA(Context<P> context) { | ||
if (this instanceof ResourceUpdaterMatcher) { |
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.
Could we add a comment there as to why we deactivate SSA in that situation, please?
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.
Tbh not sure that ResourceUpdateMatcher abstraction makes that much anymore. But we can discuss in an other PR
@shawkins you need to sign your commits off with -s (or equivalent) now |
...io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java
Outdated
Show resolved
Hide resolved
Yes, I've seen that. For some reason that box won't stay checked by default in eclipse. |
6d0fb7f
to
5766e89
Compare
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steve Hawkins <[email protected]>
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. |
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steve Hawkins <[email protected]>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steve Hawkins <[email protected]>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <[email protected]>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <[email protected]>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <[email protected]>
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: