Repository navigation
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. |
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:
|
csviri
left a comment
There was a problem hiding this comment.
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> { |
There was a problem hiding this comment.
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.
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.
Ahh, in that case, yes, it might be just enough to document it IMO.
There was a problem hiding this comment.
But I guess the move of the sanitization still makes sense.
There was a problem hiding this comment.
Ok, narrowed this PR to not include the detection of meaningless additional revisions.
There was a problem hiding this comment.
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.
Could we add a comment there as to why we deactivate SSA in that situation, please?
There was a problem hiding this comment.
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 |
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 <shawkins@redhat.com>
|
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 <shawkins@redhat.com>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steve Hawkins <shawkins@redhat.com>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <shawkins@redhat.com>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <shawkins@redhat.com>
- localizes sanitation to ssa matcher - further ensures values won't be logged Signed-off-by: Steven Hawkins <shawkins@redhat.com>
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: