Consider these use cases:

1) Deploy a chart connected to the common postgres chart. For security, pass a random value for the postgres user password to the postgres chart. Tell the postgres chart to use persistent storage, such as NFS.

Undeploy that chart.

Now deploy it again, using a different random value, but using the same persistent storage area.

The postgres chart finds the existing database installation, and sets things up to use it from there. However, the password is not updated to the new value that was passed in by the chart. Subsequently, the application cannot do anything with the database.

2) Deploy a chart connected to the common postgres chart. Leave the password set to a default value. Tell the postgres chart to use persistent storage, such as NFS. Later on, for security change the postgres password.

Undeploy that chart.

Now deploy it again, using the same persistent storage area, and specifying the default password again.

The postgres chart finds the existing database installation, and sets things up to use it from there. However, the password is not updated back to the default value that was passed in by the chart. Subsequently, the application cannot do anything with the database. Nor can the application fix up the password.

The only workarounds are to 1) delete the persistent storage before doing the redeployment. Or 2) manually log into the container using kubectl, run the psql command, and fix up the password to a new known value.

The fix is for the helm chart to add a step after deploying to go into the container and fix up the password to whatever was passed in to the chart.

DCAE has this issue because of use case #2.