Postgresql alignment/questionnaire

[almadigabor]

General info

Postgresql is a dependency of many products. Currently teams are using this database as a dependency in their helm chart. This is fine for a development scenario but will be insufficient in a production environment where most probably a managed instance will be used instead. Therefore we would like to align on many aspects of the Postgresql database. This would also help the development of the e2e-testing helm chart which is starting to get more relevant after a time of inactivity. You might already be familiar with our TRGs and the one describing the aligned dependency versions. Any additional help or suggestions about spinning up all these databases in a single instance is much appreciated.

What to do

Below you will see a form/questionnaire with database related topics. I would kindly ask each team who's product has a Postgresql dependency to copy this form and fill it in the comments. Also feel free to add your own ideas to this topic.

On this page on the right you can select your chart version and see the associated app version with it. To determine the database size in the container filesystem in ArgoCd select your database pod, go to Terminal and type du -sh /bitnami/postgresql/. As these resources might differ in every environment I would suggest to use int or stable as a baseline.

Form

Product name:
Current Postgresql app version:
Current Bitnami Postgresql chart version:
CPU request set for the database container:
CPU limit set for the database container:
Memory request set for the database container:
Memory limit set for the database container:
Volume size PV/PVC) for the database container in Gb:
Actual size of the database (du -sh /bitnami/postgresql/):
Username who owns the database:
Have tested the helm chart with external database (not helm dependency): yes/no
Please describe how the tables/objects/data is created/seeded (like init scripts, init containers, etc.):
Additional remarks:

[evegufy]

Product name: Portal
Current Postgresql app version: 15.4.0
Current Bitnami Postgresql chart version: 12.12.x
CPU request set for the database container: 250m
CPU limit set for the database container: none
Memory request set for the database container: 256Mi
Memory limit set for the database container: none
Volume size PV/PVC) for the database container in Gb: 8Gi
Actual size of the database (du -sh /bitnami/postgresql/): 313M
Username who owns the database: postgres
Have tested the helm chart with external database (not helm dependency): yes
Please describe how the tables/objects/data is created/seeded (like init scripts, init containers, etc.):
ConfigMap for init:
https://github.com/eclipse-tractusx/portal-cd/blob/portal-1.7.0-RC4/charts/portal/templates/configmap-backend-postgres-init.yaml
And migrations jobs:
https://github.com/eclipse-tractusx/portal-cd/blob/portal-1.7.0-RC4/charts/portal/templates/job-backend-portal-migrations.yaml
https://github.com/eclipse-tractusx/portal-cd/blob/portal-1.7.0-RC4/charts/portal/templates/job-backend-provisioning-migrations.yaml
 
Product name: CX-IAM
Current Postgresql app version: 15.4.0
Current Bitnami Postgresql chart version: 12.x.x
CPU request set for the database container: 250m
CPU limit set for the database container: none
Memory request set for the database container: 256Mi
Memory limit set for the database container: none
Volume size PV/PVC) for the database container in Gb: 8Gi
Actual size of the database (du -sh /bitnami/postgresql/):
• centralidp: 367M (on DEV but 6G on INT)
• sharedidp: 211M
Username who owns the database:
• centralidp: kccentral
• sharedidp: kcshared
Have tested the helm chart with external database (not helm dependency): yes
Please describe how the tables/objects/data is created/seeded (like init scripts, init containers, etc.): none
 
As discussed this week, I'm all for automation in the e2e testing helm chart, still it may a good idea to integrate first manually at least once on a common external database server (at least for the products for which that could make sense) to have an easier time automating.