Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MOODLE_DOCKER_DBHOST #238

Open
scara opened this issue Nov 1, 2022 · 3 comments
Open

Add MOODLE_DOCKER_DBHOST #238

scara opened this issue Nov 1, 2022 · 3 comments

Comments

@scara
Copy link
Contributor

scara commented Nov 1, 2022

Hello,
while working on MDL-69581 I found an unbalanced situation when playing, better jamming, with the Toolbox environment through an external DB server.
Indeed we can set the DB credentials via ENV VAR:

  • MOODLE_DOCKER_DBNAME
  • MOODLE_DOCKER_DBUSER

but not the DB Host, not strictly required in the Toolbox ecosystem unless when crossing an external DB instance could be a valuable option still for testing purposes.

Does it make sense?
I'd open a PR if it won't hurt adding a new ENV VAR defaulting to db (the service name in the compose file) and mostly unused.

TIA,
Matteo

@stronk7
Copy link
Member

stronk7 commented Nov 8, 2022

That sounds ok for me, can be useful when testing real databases elsewhere (Azure, AWS...) and also local with special debugging, tracing... +1

@scara
Copy link
Contributor Author

scara commented Nov 13, 2022

Hi @stronk7,
here is the proposal:

  1. the minimum required change: scara@95b584c. The local DB server will be still available and if you keep MOODLE_DOCKER_DB in sync with the type of the external DB server you'll be able to use it e.g. as the local DB client
  2. the change I doubt to be required: scara@e0bf9bd. This commit prevents the feature to have even the local DB server available for some use cases like the DB client

My feeling is that (2) would be an option not good for a development toolbox like this one is.

HTH,
Matteo

@stronk7
Copy link
Member

stronk7 commented Nov 13, 2023

Exactly one year later (Nov 13th!)...

I think that the 1st option is good enough. It allows, any time, to point to another database elsewhere, without touching the "own" one, and easily go back, or use the database CLI to connect to the external instance or whatever.

So +1 to the 1st approach.

Ciao :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants