Closed krancour closed 8 years ago
cc @arschles @bacongobbler
I completely and wholeheartedly agree. This was a halfway house before the object store was fully fleshed out. It would make sense to grab all information from the object storage secret in the future, but I decided to defer it to after beta so we can get this in user's hands.
This is item number 1 of 1000 things I'd like to do to postgres, but at some point there has to be a cutoff ;)
+1 as well. We have similar situations in other components too. My vote for this component is to leave as-is for beta (and as such I've marked this issue as RC).
But, for beta purposes, we should improve the official documentation to show how to configure for S3. The object storage config section for deis/database doesn't currently mention this case. I've created https://github.com/deis/workflow/issues/95 as a beta showstopper for that improvement.
See here: https://github.com/deis/postgres/blob/master/rootfs/docker-entrypoint-initdb.d/001_setup_envdir.sh#L5-L26
In that section of code above, variables first get their values from files in the directory specified by the env variable
WALE_ENVDIR
... but then, as a special case, if s3 is being used, the variables are overwritten with values from files in an entirely separate location.This is pretty confusing if you look at the charts, because one would potentially see secrets for both minio and s3 mounted into two separate paths in the container.
Maybe this script can be updated to always read, generically, "object storage" configuration details from one, consistent location on the disk, without special-casing anything?
fwiw, I understand that there may be nuances to boto that demand special-casing some things, but I think there should be no problem always reading these connections details and creds from a consistent mount point, regardless of who the object storage provider is. Ultimately, this would make some further simplifications possible in the chart as well.