This is the documentation for the configuration system for Bedrock instances. We have two distinct types
of configuration values: static and dynamic. Static configurations are those that are loaded at app startup in
bedrock/settings/base.py file primarily. They require an app restart to pick up new values and get their
values from either the environment or a .env file in the app root directory.
The second kind of configuration is one that can change while the app is running. At the moment the only use of
these is waffle switches and funnelcake configuration. These can be loaded from the same places as static configs
(environment and .env) but also from the database. So you can continue using your
.env file locally to test
settings, but we can distribute said settings to our running instances via the database update process. This is why
we've separated these values into separate files.
Static configurations are currently stored in the directories named after the cluster and namespace (e.g. iowa-a/bedrock-dev).
So you want to flip a waffle switch in production? Great! Do this:
- Clone the
- Fork the repo into your Github account.
- Edit the
waffle_configs/bedrock-prod.envfile to add the name and value you need. You'd add a line like
SWITCH_WE_DO_PHRASING=onto set that key and value in the settings database for prod. Or you can find the line that already has the variable you need and change the value if it already exists.
- Commit the change.
- Push the change to a branch on your fork.
- Submit a pull-request against the
- Ask for a review in the
#wwwIRC channel or in the PR itself.
- Once the PR is reviewed and merged it will automatically roll out to our production instances in 5 to 10 minutes.
Editing the Configs
The configurations are in the
waffle_configs directory in the repo. They are simple environment files in the format usable by Foreman.
Deleting a variable is simply deleting the line from the file. The full list of configurations are refreshed every time for those values.
Any commit that triggers a deployment to our dev, staging, or prod environments will also trigger a suite of test jobs configured in .gitlab-ci.yml. That file also specifies a number of jobs to be run if a pipeline provided a BASE_URL, which we can use to test independent of deployment.
- visit https://gitlab.com/mozmeao/www-config/pipelines/new
- by default the
masterbranch is populated
- Add a new variable:
- Input variable key is
- Input variable value should be equal to the URL you want to run the tests against (example: https://www-demo1.allizom.org)
- Input variable key is
- By default the latest bedrock_test image is used for the tests