I have some questions about how to configure the GoodData.CN helm chart to connect to our RDS cluster in AWS. - Under metadataApi, there are existingSecret and existingExporterSecret values for the "md" database, but only one "user" property. How does this user have two secrets? Seems I'm missing something. I'm assuming no passwords are needed if we configure existing secrets (please confirm). I'm also assuming these are k8s secrets (vs. AWS secrets) - please also confirm. It looks like several services share the same secrets key "postgresql-password", which I assume means they must also share the same user in the DB. - The RDS cluster supplies both endpoints and reader_endpoints. I assume we should assign the main (writer) endpoint to the host property under service.postgres (please confirm). Should we assign the reader_endpoint anywhere in the helm chart? Are the reader_endpoints used? - There are references to S3 settings in values.yaml for the GoodData.CN helm chart. Do we need to set up an S3 bucket to use GoodData.CN on AWS? Thanks for clarifying! 😀

Hi, regarding the metadataApi secret confusion. Indeed, there are two distinct secrets - existingSecret (containing application user's password in key

postgresql-password

) and

existingExporterSecret

(containing

md_exporter

user's password in key

exporter-password

). While application user name is configurable (using

metadataApi.database.user

), the

md_exporter

is hardcoded 😞 The puprose of this user is not documented, but it is exclusively used in GoodData Cloud product (deployment hosted by GoodData) for collecting internal statistics. In GoodData CN, it has absolutely no purpose, and it's a mistake we didn't make this user optional. Unfortunately, some older database migrations already rely on this user's existence to create reporting views in

md

database, so it would be rather difficult to remove it. k8s Secrets/aws secrets/passwords: If you precreate k8s secrets (one with

postgresql-password

key and one with

exporter-password

key), you do not need to specify

metadataApi.database.password

. AWS secrets (for AWS secrets manager product) are completely irrelevant. we don't use them. sharing postgresql-password: not exactly. There are 3 distinct services that need some database credentials (dex, metadataApi and sqlExecutor). Each service can have its own user and password. dex user: dex.config.database.user dex pass: dex.config.database.password dex existing secret (can be used instead of dex password): dex.config.database.existingSecret -- metadata-api user: metadataApi.database.user (described above) metadata-api pass: metadataApi.database.password metadata-api secret: metadataApi.database.existingSecret (as described above, can be used instead of metdata-api password) -- sql-exec-api user: sqlExecutor.database.user sql-exec-api pass: sqlExecutor.database.password sql-exec-api secret: sqlExecutor.database.existingSecret (can be used instead of sql-exec-api password) All these "existingSecret"s need to have password stored in

postgresql-password

key. There's yet another set of db credentials, configured in

service.postgresql

structure: •

username

- name of pg admin user (usually

postgres

) •

password

or

existingSecret

- password of admin user. This account is used only during installation to create necessary databases (dex, md, and execution) and to create all the application users described above. It is not used in runtime. RDS endpoints: Assign only the writer endpoint. multi-node Aurora is used primarily for high-availability, not for load distribution.

service.postges.host (and port)

is the right place for setting the writer endpoint. reader endpoints are not used. S3 Settings: S3 can be used to store PDF and tabular exports (CSV, XLS). If not configured (default), local file system is used. If you decide to use S3, you need to provision S3 bucket (e.g. by terraform) and provide static aws credentials. IRSA credentials do not work as described in docs due to 3rd-party library bug we discovered and fixed 2 days ago 😞 But gooddata-cn version 2.4.0 will have it fixed.

@Robert Moucha could you provide an example of the yaml structure we would need to store the metadata-api password and sql-exec-api password in the same k8s secret with key "postgresql-password"? (We're not using dex, so don't need a secret for dex.) Since multiple services will be sharing data in the same k8s secret, we need some clarity on the exact structure of the "data:" section of this k8s secret.

You may use command like:

kubectl -n gooddata-cn create secret generic gdcn-db-secrets \
  --from-literal=postgresql-password=somepassword \
  --from-literal=exporter-password=otherpassword \
  --dry-run=client -o yaml

to generate yaml-formatted secret with keys

postgresql-password

and

exporter-password

:

apiVersion: v1
data:
  exporter-password: b3RoZXJwYXNzd29yZA==
  postgresql-password: c29tZXBhc3N3b3Jk
kind: Secret
metadata:
  creationTimestamp: null
  name: gdcn-db-secrets
  namespace: gooddata-cn

Thanks, Robert. This is super helpful 😀

`kind: Secret`also accepts

stringData

instead of

data

where you can place values in raw strings (without base64 encoding):

apiVersion: v1
stringData:
  exporter-password: otherpassword
  postgresql-password: somepassword
kind: Secret
metadata:
  creationTimestamp: null
  name: gdcn-db-secrets
  namespace: gooddata-cn

🙂