Open idogada-akamai opened 11 months ago
Any news about this?
Just stumbled over the same issue on ArgoCD v2.10.1+a79e0ea. My use case is replicating secrets into multiple namespaces using Reflector. The mirror target's data
object gets updated, resulting in a sync loop.
I tried to use the following but it didn't work:
ignoreDifferences:
- group: ""
kind: Secret
jqPathExpressions:
- select(.metadata.annotations."reflector.v1.k8s.emberstack.com/reflects" != null).data
Here's an example in JQ Playground.
Any update here?
@idogada-akamai best practice is to not comment "any updates" unless you have additional information to offer. If no one has said anything, there is no update. (But requesting attention in Slack, as you did, is fine! It's a better venue for that.)
@sunsided I think what you're doing should prevent the change from appearing in Argo CD's diff interface, but (by itself) it won't prevent Argo from syncing the git values to the cluster. To avoid syncing the git value, enable RespectIgnoreDifferences=true
.
Make sure your jq query successfully targets all relevant values. For example, if you have set stringData
in git, you should probably add that to your jq query.
Also, please try with the most recent stable Argo CD version. There have been recent improvements to ignoreDifferences
.
I stumbled across the same issue, when trying to make a "dynamic" ignore to avoid bloated Application due to a large ignoreDifferences
list.
I am using ApplicationSets, and I don't want to set global ignores for all secrets, or use TemplatePatch / ignoreapplicationdifferences. It should be handled in each scenario to make sure nothing extra is ignored.
Ultimately something like this: https://github.com/argoproj/argo-cd/issues/12686 would be the holy grail solution.
I have tried something like this which is similarly to the other approaches in this issue:
ignoreDifferences:
- kind: Secret
jqPathExpressions:
- . | select(.metadata.annotations.ignore) | .data
Which results in the following:
I would have expected it to outright ignore the difference, instead it thinks it the .data.X doesn't exist then wants to add them, even though they are already present. This makes it hard to perform secret injection in ApplicationSets without using global ignores, or TemplatePatches.
Similarly i found this article: https://medium.com/israeli-tech-radar/how-to-enable-history-and-rollback-for-argo-cd-application-set-with-multiple-sources-52a2f0f3781d but i was not able to reproduce the ignore he made.
i have the same issue. I'm trying to ignore HPA changes if scaleops is configured .
what argo does is as @Goose29 mentioned. it can't find the actual data and wants to set the original data
ignoreDifferences:
- group: autoscaling
kind: HorizontalPodAutoscaler
jqPathExpressions:
- >-
select(.metadata.annotations["analysis.scaleops.io/original-metrics"] !=
null) | .spec.metrics[].resource.target
I think this issue is caused by comparing both the actual state (left side) and the requested yaml (right side) with the ignoreDifferences config.
since the requested yaml doesn't have any of the injected attributes (in this case scaleOps annotations are created by its controller after the HPA has been created) - the select
part fails so it doesn't ignore the desired parts from the requested yaml.
so we get empty attributes (ignored) on left side and normal behavior (unignored) on right side.
I think this deserves a feature request.
ArgoCD versions 2.10 and below have reached EOL. Can you upgrade and let us know if the issue is still present, please?
ArgoCD versions 2.10 and below have reached EOL. Can you upgrade and let us know if the issue is still present, please?
My comment above, was tested on v2.12.1+26b2039.
Checklist:
argocd version
.I am trying to use the jqPathExpressions in an ArgoCD application to ignore .spec.suspend on all cronjobs that have a specific label. I have tried the following:
Unfortunately that ignores the .spec.suspend field for all the cronjobs that are generated by the application.
To Reproduce
controlledByLeader : "true"
ignoreDifferences
controlledByLeader : "true"
label. Notice how the application is still marked as in syncExpected behavior
Whenever a Cronjobs without the
controlledByLeader : "true"
label is modified in the cluster, that the application will be out of sync.Version
2.9.3