Auto-sync option in application CRD instance

[jessesuen]

The application instance needs an option to automatically sync on every push. Currently this is an separate action performed by the user.

[jessesuen]

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

[jessesuen]

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

syncPolicy:
  always:
    frequency: 5m
    retry: false

[merenbach]

@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

[jessesuen]

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.

[jessesuen]

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)

[marioduarte]

One more consideration I would bring up:

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

[jessesuen]

@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: {}

[jessesuen]

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