search

argoproj / gitops-engine

Democratizing GitOps
https://pkg.go.dev/github.com/argoproj/gitops-engine?tab=subdirectories
Apache License 2.0
1.67k stars 251 forks source link

feat: add ExternalSecret to sync wave #612

Open ckav370 opened 1 month ago

ckav370 commented 1 month ago

I want to be able to use a preSync hook to run some database migrations. This has been working fine, until such a time as updating the container secrets which are using the External Secret Operator and CRD to create a k8s secret which the job created by the preSync hook creates mounts.

As per this Github issue #9891, the recommended approach is to use Argo sync waves. However ExternalSecret is not included in one of the predefined kinds and therefore cannot be part of a different "wave" meaning that any secrets defined by ExternalSecrets cannot be synced before the preSync hook as part of the pre Sync wave.

This would allow the ExternalSecret to have an annotation such as the following

argocd.argoproj.io/sync-wave: "-2"

And a preSync hook to have a greater weighted sync wave such as 

argocd.argoproj.io/sync-wave: "-1"

And all other resources which are part of the deployment would default to weight of 0 without the need for an annotation

schlags commented 1 month ago

Isn't this already possible?

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/sync-wave: "-1000"

We already use ExternalSecrets in this fashion. One of our PreSync jobs requires a secret present and this was our strategy to prevent the catch 22 of initial sync not having that secret defined yet.

ckav370 commented 1 month ago

Isn't this already possible?

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/sync-wave: "-1000"

We already use ExternalSecrets in this fashion. One of our PreSync jobs requires a secret present and this was our strategy to prevent the catch 22 of initial sync not having that secret defined yet.

Using a PreSync jon in this way means that when the secret is updated, the secret will be recreated. In the case where some PreSync job and the main application uses this secret, this would not be a very robust- especially in the case where the secret refresh failed to pull from the ExternalSecret backend.

Granted this is probably more likely in legacy code bases, but it would not be a solution for my current use case :)