Add ability to pass db user and password when creating (as we do with url etc)

[amp-cli]

Add ability to pass db user and password when creating (as we do with url etc)

[totten]

Well, I can't really give an affirmative or negative opinion because it's not clear enough to me what option is being considered or what the pain-point is for "pre-creat[ing] a services.xml."

It seems that there are a few things floating around here:

1. The configuration-management techniques of using amp config:set vs editing services.yml directly vs manipulating env-vars vs runtime CLI args.
2. The workflow of creating MySQL users+databases on-demand (CREATE DATABASE... CREATE USER...) -- versus the workflow of externally pre-creating MySQL users+databases. (mysql_dsn vs mysql_precreated)
3. The formula for naming MySQL users+databases. (For mysql_dsn, that's a fixed formula per https://github.com/amp-cli/amp/blob/master/src/Amp/Database/MySQL.php#L55. But for mysql_precreated, one is required to set their own formula via PRECREATED_DSN_PATTERN.)
4. The development strategy of making a configurable amp driver (eg amp-cli/amp) vs bespoke amp drivers (e.g. a dumb bash-script that just outputs constants).

It sounds to me like you're mostly concerned with the formula (3) for new DBs - circa Amp/Database/MySQL.php@55. Agree that could be improved. The question is -- what is the new formula?. Here are a few different ways to make the formula work:

• a. Make a setting out of it. (Ex: mysql_db_template={{DIR}}_{{NAME}}_{{RAND}}). Include variables for things like: the base-directory of the build (dmaster vs wpmaster), the logical subparts (cms vs civi vs test), and random nonces. Maybe also passthru env-vars.
  • If your use-cases are agreeable, then you can use a prettier formula like mysql_db_template={{DIR}}_{{NAME}}.
  • If you want to control the names precisely and have the fortitude to consistently set the env-vars then configure mysql_dsn_template=$MY_DB and run with env MY_DB=foo amp create.
• b. Make some kind of callback/callout.
• c. Use an incrementing suffix instead of random code. This requires probing to see if the DB already exists (s.t. new builds don't conflict with old builds), but it also requires some stability (s.t. re-builds have stable/consistent names). I think I wanted that way-way-back (before anything was ever released) but got lazy about how to verify that it'd work in those edge-cases. However, MySQLPrecreated now has a probe - maybe MySQL.php could borrow the probing bits from MySQLPrecreated.php?

The main thing is to keep an eye on the overall usage/workflow when juggling builds, e.g. consider operations:

1. Add new project A
2. Add new project B
3. Rebuild project A
4. Drop project A
5. And new project C
6. Rebuild project B

(Where projects A, B, C may be similar to each other - or different from each other.) At steps 1+2+5, it should pick new names. At steps 3+6, it should retain names. At step 4

[eileenmcnaughton]

@totten right so what I'm finding is that the services.yml can wind up being deleted or being inconsistent/ hard to maintain across environments (CI vs docker vs vagrant) but I want to have a consistent db name that we pre-determine

Note that we are still looking to create the db when we first run civibuild create wmff - it's just that we want to specify the db name it uses in the command. This makes it easier to grant our dbuser (which has the same name) access to other databases and means that we can set up mysql connections in phpstorm (for example) and know that the db name is not going to change.

so looking for something like

civibuild create wmff --admin_pass=admin --db_name=my_db_name

where db_name is an optional param that would override any potentially generated one (& be the default for db_user as is currently the case)

I think the parameter could be ignored / error out if the yml already exists and has a different name

I guess passing in env params is slightly-uglier but equivalent - ie

env mysql_DB_Name=my_db_name && civibuild create wmff --admin_pass=admin