Auto-sync option in application CRD instance about argo-cd HOT 8 CLOSED

Spoke with @alexmt. auto-sync based on a difference from a tracking branch and live state, is not yet implemented.

This should be a new field in the ApplicationCRD. I propose something like:

syncPolicy: Always

from argo-cd.

This needs more thought. A string is too simplistic. We probably need more knobs. e.g.

syncPolicy:
  always:
    frequency: 5m
    retry: false

from argo-cd.

@jessesuen, unless we expect to have other keys under syncPolicy, I'm not convinced it's as semantically useful to nest under always. Maybe promoting the frequency and retry directives up a level would help simplify configuration, something like:

sync:
    policy: Always
    frequency: 5m
    retry: false

from argo-cd.

The keyword sync will be too generic. For example, I already anticipate a need for a syncStrategy. Today, our only sync strategy is kubectl apply. However in the future, we will support a workflow based sync, or perhaps kubectl replace.

The reason I proposed this structure:

syncPolicy:
  always:
    frequency: 5m
    retry: false

Is because this nesting of data-structures as types, is a common API pattern in k8s (volumes is a good example). deploymentspec also use RollingUpdate type, with the anticipation of different update strategies in the future. There is a good reason for this: not all the options may be applicable to all policies. My example is probably not the best, because frequency and retry might be something applicable to all policies and we would likely promote it higher, but you could imagine something like:

syncPolicy:
  workflow:
    path: guestbook/workflows/blue-green.yaml
    parameters:
    - name: foo
      value: bar

In the above case, path, and parameters only apply to the workflow sync policy, and we would not want to pollute the syncPolicy datastructure with those fields.

from argo-cd.

Revisiting this based on recent discussions:

Considerations:

• how do we prevent unnecessary syncs? e.g. we need to record that we already attempted to sync to a revision.
• what happens if there is a very active repo? e.g. user's code repo shared with deployment repo
• how does auto-sync play nicely with parameter overrides?
• how does auto-sync play with rollback? (i think rollback action needs to be disabled)

from argo-cd.

One more consideration I would bring up:

• Do we have an option to enable or disable prune on auto-sync?

from argo-cd.

@marioduarte thanks for the feedback. For the implementation for configuring automated sync, I have added an option to disable pruning. Default behavior will be to prune. Current proposal for the spec is:

spec:
  destination:
    namespace: asdf
    server: https://localhost:6443
  project: default
  source:
    path: kustomize-guestbook/base
    repoURL: https://github.com/jessesuen/argocd-example-apps.git
  syncPolicy:
    automated:
      disablePrune: true

This is how you would configure it with pruning:

spec:
  destination:
    namespace: asdf
    server: https://localhost:6443
  project: default
  source:
    path: kustomize-guestbook/base
    repoURL: https://github.com/jessesuen/argocd-example-apps.git
  syncPolicy:
    automated: {}

from argo-cd.

On second thought, I think it will be safer to make automatic pruning behavior opt-in. The default will be off:

spec:
  destination:
    namespace: asdf
    server: https://localhost:6443
  project: default
  source:
    path: kustomize-guestbook/base
    repoURL: https://github.com/jessesuen/argocd-example-apps.git
  syncPolicy:
    automated: {}

and to enable automatic pruning:

spec:
  destination:
    namespace: asdf
    server: https://localhost:6443
  project: default
  source:
    path: kustomize-guestbook/base
    repoURL: https://github.com/jessesuen/argocd-example-apps.git
  syncPolicy:
    automated:
      prune: true

from argo-cd.