Suggestions for removing confusion around the configuration settings using Docker Compse

[swcurran]

I find sorting out where to set configurations (mostly environment variables) very confusing and I don't really trust where to put the changes. There are multiple places env. variables are listed, and it's confusing where to put things -- and what has to happen (build? restart?) to make the changes take effect.

I'd like to suggest the following changes:

• remove from the ./manage script the prompting and on the fly creation and (especially) the removal of the .env file.
• replace with have a env-example (no leading ".") file with comments about how to adjust it for common use cases -- e.g. the same info as on the command line prompt. Document that the file should be copied to .env and edited before running.
• In the docker-compose.yaml file --- set the env variables to match their names (e.g., OIDC_CONTROLLER_DB_USER=${OIDC_CONTROLLER_DB_USER}). Avoid using different env var names (e.g. avoid this DB_HOST=${MONGODB_HOST})
• In the .manage file, set all of the variables with default settings.
• In the env-example (the starting .env) include the commonly overridden variables, commented out and more comments on how to use the setting.
  • Include in the documentation (comments) where a variable changed in the env file needs to be changed elsewhere to match -- e.g. database passwords that are defaulted, but that are in multiple files.
• Right at the end of the ./manage section that sets all the variables, load the .env file to override anything.

Nice to have would be to not repeat all the variables in the docker compose and ./manage file, but I doubt there is much can be done about that.

[swcurran]

Not sure if anything can be done to align the Helm chart settings with the docker compose. That would reduce the duplication, but is not necessary.

[esune]

Thanks for the input @swcurran, will review and see what we can do.

A couple of notes:

• Helm will need to be 1-to-1 with docker-compose: their task is the same, but with different scopes in mind (Helm is for k8s/production, docker-compose for local experimenting and development inmost cases)
• We will still need to have a manage script that sets variables to be able to use ngrok, since that needs to happen on the fly every time the project is started

[swcurran]

Agreed. Not eliminating the manage script — just formalizing its role to set all of the defaults before all the overrides are applied. Agreed the ngrok processing should still be in the manage script.

[esune]

@gurjmatharu FYI while you comb through the project and docs, this might provide some extra context/inspiration.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[esune]

@gurjmatharu was this addressed (in full or partially) in the review you did a few weeks back, or do we still need it open?

[gurjmatharu]

@gurjmatharu was this addressed (in full or partially) in the review you did a few weeks back, or do we still need it open?

This still needs to be addressed I believe. When I went through the repos getting started was difficult so these changes could help.