aiven/aiven-operator

RFE: Make Aiven Operator more GitOps Friendly

Opened this issue · 2 comments

christianh814 commented

The Aiven Operator is great and I can deploy a DB (sample using MYSQL) using it

apiVersion: aiven.io/v1alpha1
kind: MySQL
metadata:
  name: mysql-sample
spec:
  authSecretRef:
    name: aiven-token
    key: token
  connInfoSecretTarget:
    name: mysql-secret
  project: myproj
  cloudName: google-europe-west1
  plan: startup-4

However this stores the credentials in a secret. as specified under spec.connInfoSecretTarget

Usually (and especially true when doing GitOps with Flux/Argo CD), the secret needs to be stored in Git. More specifically it's stored in Git via Vault, Sealed Secrets, and/or External Secret Operator.

I would like to be able to set up connection parameters beforehand (or as much as I can) and have the Aiven Operator "respect" these parameters (i.e. use the parameters to set up the DB).

byashimov commented

Hey.

The Aiven Operator is great and I can deploy a DB (sample using MYSQL) using it

Thank you, that's very nice of you.

Would this work for you?
Say you have applied this yaml stored in git:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: bXktc2VjcmV0

---

apiVersion: aiven.io/v1alpha1
kind: MySQL
metadata:
  name: mysql-sample
spec:
  connInfoSecretTarget:
    name: mysecret
  1. if you provide connInfoSecretTarget.name pointing to an existing Secret then the Operator uses that creds to set
  2. if no Secret found, it creates a new one (as it does right now)

Few cons:

  1. we can't validate the Secret.
  2. for multiple reasons we won't be able to detect secret changes. Reconciliation stops once it has been successfully applied. To do so we mark our resources with annotations. But we never managed secrets so far.
  • 👍2
christianh814 commented 
1. if you provide `connInfoSecretTarget.name` pointing to an existing `Secret` then the Operator uses that creds to set

2. if no `Secret` found, it creates a new one (as it does right now)

Yes, this sounds perfectly reasonable

Few cons:

1. we can't validate the `Secret`.

2. for multiple reasons we won't be able to detect secret changes. Reconciliation stops once it has been successfully applied. To do so we mark our resources with annotations. But we never managed secrets so far.

I think those cons are fine to live with. Documentation should make this clear though.

Thanks! 🙌

  • 👍2