Open mrysavy opened 1 year ago
Another benefit of special flag (like syncPolicy.automated.disabled
) could be possibility (in another case) to temporary disable autoSync+selfHeal of this field by it in managedFields
under specific field manager and set this field manager to
ignoreDifferences[].managedFieldsManagers
.
As selfHeal
is a part of the auto sync feature, I don't think this is a valid bug but should be an enhancement request instead.
I'm also not sure I like the disabled
semantics, it feels a little counter-intuitive as compared to having the flag named as enabled
. But I see that, without making it a breaking change, there is probably no other possibility to specify a flag that controls the state of auto sync.
As
selfHeal
is a part of the auto sync feature, I don't think this is a valid bug but should be an enhancement request instead.
From my point of view this is a design bug, because ArgoCD as a GitOps tool should allow to manage autosync functionality in a GitOps way like all other functionalitites. But I don't want to start a flame :-)
I'm also not sure I like the
disabled
semantics, it feels a little counter-intuitive as compared to having the flag named asenabled
. But I see that, without making it a breaking change, there is probably no other possibility to specify a flag that controls the state of auto sync.
Flag enabled
(with true
as default for backward compatibility) is also the right solution in my use cases
this relates to https://github.com/argoproj/argo-cd/issues/8686
Today looked into declaratively generating auto sync from an Application Set, depending on a value from a YAML file (using the Git File Generator). With the limited Go templating options available within an AS, I cannot make that work. If the toggle becomes more ‘natural’, acting on the value of a key called enabled
, not on the existence of a key, that might be easier; but there’s still the limitation that a Go template there cannot render a boolean value :(
This is an important feature which is missing, we bumped into this problem too...
No updates for many years? so sad for that. many problems while templating the argocd
+1 for this.
Checklist:
argocd version
.Describe the bug
Application resource schema doesn't allow to force autosync disabled using GitOps way and app-of-apps pattern.
I have parent Application (app-of-apps pattern) which contains child Application resources only and which have autoSync with selfHeal enabled. I need this parent Application to force child Applications to have autoSync completely disabled. I need parent Application selfHeal to disable autoSync of child applications again when somebody enables it directly in Kubernetes.
Unfortunately, autosync is disabled only when
spec.syncPolicy.automated
is not present on resource and I don't know how to write child Application resources in the way that ArgoCD forces it in Kubernetes with fieldspec.syncPolicy.automated
absent.I've tried to use
spec.syncPolicy: {}
andspec.syncPolicy.automated: null
but none of them works in ArgoCD (it means that in both cases in Git andspec.syncPolicy.automated: {}
present in Kubernetes ArgoCD consider asSynced
).To Reproduce
First create parent Application:
My public GitHub repo contains two child Application resources, one with
spec.syncPolicy: {}
and the other withspec.syncPolicy.automated: null
.Now both child Applications are OutOfSync because it is specified in git.
Than enable autoSync on both child Applications:
Now all Applications are Synced:
And the problem is that although automatic synchronization on child Applications is supposed to be turned off, it is turned on, even though parent Application has selfHeal enabled.
SyncPolicy of first application from GIT:
and from Kubernetes cluster:
SyncPolicy of second application from GIT:
and from Kubernetes cluster:
Expected behavior
Expected behavior is to have a possibility to enforce autosync disabled on child Application by parent Application selfHeal. Proposal could be having a flag to disable autosync in
automated
block, like:Version