You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A dependent Statefulset resource is always updated when reconcile is triggered #1989
We have a reconciler which configures a StatefulSet as a dependent resource using CRUDKubernetesDependentResource. Everything was working as expected before, but after updating to the latest version of the sdk (we're using Quarkus, so we updated the quarkus-operator-sdk to version 6.2.1, which corresponds to JOSDK version 4.4 as far as I know), we have a problem that the StatefulSet is always updated even when there's no change to the Spec.
After checking, we found that the matcher SSABasedGenericKubernetesResourceMatcher is always reporting a mismatch between actual and desired, and the exact reason is that the actual StatefulSet Spec has the entry status={phase=Pending} as part of volumeClaimTemplates. Are there a mechanism to avoid this other than overriding the match method?
But, to take a look further I need more information regarding this case, could you please turn of trace level logging for the SSABasedGenericKubernetesResourceMatcher and send the logs for this line:
SSA marks the whole persistentVolumeClaim as managed by the controller, see:
f:volumeClaimTemplates: {}
However, there is a status field added there by the statfulset controller, which is not marked in managed fields, (thus rather there should be an explicit list of fields managed by our controller, and this one excluded), see in resources:
Activity
csviri commentedon Aug 1, 2023
Hi @moayad-alyaghshi , as a quick fix you can just use the legacy matching algorithm, see sample:
https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework/src/test/java/io/javaoperatorsdk/operator/sample/ssalegacymatcher/ServiceDependentResource.java#L39-L44
But, to take a look further I need more information regarding this case, could you please turn of trace level logging for the SSABasedGenericKubernetesResourceMatcher and send the logs for this line:
https://github.com/java-operator-sdk/java-operator-sdk/blob/03e06ce4700e9cd5b3f0f8486147ac3464b4dc7e/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/SSABasedGenericKubernetesResourceMatcher.java#L85-L85
I will reproduce and fix the issue based on that.
Thank you!
moayad-alyaghshi commentedon Aug 1, 2023
Hi @csviri, thank you for your quick reply.
The legacy matcher is working as expected.
Here is the log entry of the line you asked for:
I can provide a sample project in case that is needed.
Thank you
csviri commentedon Aug 1, 2023
thx, the second log message seems to be truncated. A simple project to reproduce would be great, thank you!
moayad-alyaghshi commentedon Aug 1, 2023
You can find the sample project attached.
code-with-quarkus.zip
CR:
csviri commentedon Aug 2, 2023
The cause of the problem:
SSA marks the whole persistentVolumeClaim as managed by the controller, see:
However, there is a status field added there by the statfulset controller, which is not marked in managed fields, (thus rather there should be an explicit list of fields managed by our controller, and this one excluded), see in resources:
This is an issue with SSA/statefulset controller implementation in K8S.
I don't see any elegant solution for SSA matcher, other than maybe provide an ignore list. Maybe we could explicitly handle these known cases.
cc @metacosm
csviri commentedon Aug 2, 2023
see also: https://kubernetes.slack.com/archives/C0123CNN8F3/p1690977112340099
(will create an issue in Kubernetes if they don't reply here)
moayad-alyaghshi commentedon Aug 2, 2023
Yes, that was exactly our finding.
I will keep an eye on the progress of this issue, and we will use the legacy matcher for time being.
Thank you
moayad-alyaghshi commentedon Oct 4, 2023
hi @csviri, I see that the issue is closed and there is a merged pull request, so when can we expect the fix to be released and in which version?
Thank you
csviri commentedon Oct 4, 2023
Hi @moayad-alyaghshi yes, these are usually in next minor release, thus will be 4.5, hopefully that will be released this week.