Support templating generated secret.

[khusseini]

It would be amazing if we could change the generated secret for a database and map its values similar to how the connectionStringTemplate works, but for all the values. This has the advantage that we could have the keys for the database variable. It makes it easier for writing deployments.

Maybe something like this

apiVersion: "kci.rocks/v1alpha1"
kind: "Database"
metadata:
  name: "example-db"
spec:
  secretName: example-db-credentials # DB Operator will create secret with this name. it contains db name, user, password
  instance: example-gsql # This has to be match with DbInstance name
  deletionProtected: false # Protection to not delete database when custom resource is deleted
  backup:
    enable: false # turn it to true when you want to use back up feature. currently only support postgres
    cron: "0 0 * * *"
  secretEnvTemplate:  |
    DATABASE_HOST={{ .DatabaseHost }}
    DATABASE_USERNAME={{ .UserName }}
    DATABASE_PASSWORD={{ .Password }}
    DATABASE_URL=pgsql:{{ .Protocol }}://{{ .UserName }}:{{ .Password }}@{{ .DatabaseHost }}:{{ .DatabasePort }}/{{ .DatabaseName }}?version={{ .DatabaseVersion }} 
    DATABASE_NAME={{ .DatabaseName }}
    DATABASE_PORT={{ .DatabasePort }}
    DATABASE_VERSION={{ .DatabaseVersion }} 

[dabde]

Add this to our internal agenda.

[allanger]

I'm on it now. In the first iteration, I would not remove the connectionStringTemplate field from the CRD. Just in case it's used by someone already. But if it's used, I would just add a warning log that this field is going to be removed soon.

And if the connection string is not set explicitly in a database manifest, the default template is used to generate a CONNECTION_STRING value, I think the new way of generating secrets should overtake this logic. So now I see it like this:

If spec.secretsTemplates field is defined, then secret generation is using templates and names that are provided in this field.

spec:
  secretsTemplates:
    PASSWORD: "password is {{ .Password }}"
    USERNAME: "username is {{ .UserName }}"

Will produce a secret like this

apiVersion: v1
data:
  # Templated secrets 
  PASSWORD: password is password_example
  USERNAME: username is username_example 
  # Default secrets
  POSTGRES_DB: db
  POSTGRES_PASSWORD: password
  POSTGRES_USER: user
kind: Secret

If the spec.connectionStringTemplate is set, then it's working like it used to work before

If none of them are set, there will be one field created by the secret generator:

apiVersion: v1
data:
  # Now it's generated not by the connection string generator but by the new secret generator 
  CONNECTIOM_STRING: connection_string_example
  # Default secrets
  POSTGRES_DB: db
  POSTGRES_PASSWORD: password
  POSTGRES_USER: user
kind: Secret

If both fields are set, spec.connectionStringTemplate is ignored and only spec.secretsTempltates is used. And also there is a log warning about that.

@dabde @hyunysmile what do you think?

[allanger]

This is merged: https://github.com/kloeckner-i/db-operator/pull/161 And the db-oeprator chart is updated: https://github.com/kloeckner-i/charts/releases/tag/db-operator-1.4.0