What is the correct way to add a prefix to the name of the MySQL database, using tutor? My question extends to all applications (openedx, forum, ecommerce, notes, etcetera). I want to add an environment prefix to all of these database names, such as:
Hi Lawrence!
I am using the K8s namespace as a suffix, and set the db names in a plugin like this:
patches = {
"common-env-features": {
-- feature flags --
},
"lms-env": {
"OPENEDX_MYSQL_DATABASE": "edxdb_{{ K8S_NAMESPACE | replace('-', '_') }}",
"NOTES_MYSQL_DATABASE": "notes_{{ K8S_NAMESPACE | replace('-', '_') }}",
"DISCOVERY_MYSQL_DATABASE": "discovery_{{ K8S_NAMESPACE | replace('-', '_') }}",
},
"cms-env": {
"OPENEDX_MYSQL_DATABASE": "edxdb_{{ K8S_NAMESPACE | replace('-', '_') }}",
"NOTES_MYSQL_DATABASE": "notes_{{ K8S_NAMESPACE | replace('-', '_') }}",
"DISCOVERY_MYSQL_DATABASE": "discovery_{{ K8S_NAMESPACE | replace('-', '_') }}",
}
}
for patch, settings in patches.items():
for key, value in settings.items():
hooks.Filters.ENV_PATCHES.add_item(
(
patch,
'{}: {}'.format(key, str(value))
)
)
Note that db names should not include dashes “-”, but underscores “_”.
In my case, I use “-prod”, “-dev”, etc. as suffix for the namespaces (e.g. mycustomer-prod), that’s why I have to use the replace function in the template, but you may not need this.
thanks @Andres.Aulasneo. Yes, this is what what i was missing. i created a plugin today and got everything working but nevertheless i ultimately went in a different direction. The Cookiecutter already manages most of the MySQL connection information on a per-client / per-environment / per-database basis and so it made more sense to add the database name to the existing data which is stored in K8s secrets. see this example
The crux issue regards the source of the other information that derives the db prefix. There were two principal issues. First, the data is already present inside of Terraform and is thus pretty easy to work with. And second, there are ridiculous character length limitations with both MySQL database names and usernames; both of which are problematic if you’re attempting to integrate stuff like domain names into your naming convention. I ended up doing a lot of twentieth century string manipulations on the database name prefixes in order to ensure that they conformed to the length limitations while not losing too much pertinent information.
Here’s a generic example of the kinds of names that the Cookiecutter is now producing:
It’ll do this for all databases that are part of the overall Open edX application suite
Putting this all together:
