Repository navigation
Hoist production.py defaults into common.py #36892
Description
Currently at the top of both the lms/envs/production.py file and cms/envs/production.py file, there are settings that are being explicitly set.
The goal of the production.py files is to facilitate overriding defaults which are specific to a deployment but in most of the cases here, the defaults at the top of these files are just sensible production defaults that should be set in the relevant {lms,cms}/envs/common.py or openedx/envs/common.py setting file. The common files should house the default settings needed for production and the test.py and devstack.py files should override them with anything needed for development.
As a part of this task, we should re-organize and change the defaults in the various common.py files such that we can remove these defaults from the production.py files.
This should be done in a way that does not change the rendered settings for operators:
- Use the Settings Diffing tooling to check this
- See the testing instructions in previous PRs here:
Activity
wgu-taylor-payne commentedon Jul 8, 2025
UPDATE: I decided to keep values as they render now, based on the instruction in this issue:
@kdmccormick What should we do with edx.org specific defaults? For example, this AWS related setting looks like it might be edx.org specific in the
production.pyfiles:I think the value set in the
common.pyfiles is a good default that clearly signals that the setting needs to be overridden, and so I would like to bring that up toopenedx/envs/common.py. Do we need to work with edx.org to make sure they are providing values to setting such as these in their yaml files before removing them?kdmccormick commentedon Jul 21, 2025
@wgu-taylor-payne Good question. Best to leave the edx.org-specific defaults in place for now, just to keep our changes as close to "pure refactorings" as possible. But at some point soon, it'll make sense to replace those edx.org defaults with something better for the community. We don't need to work with edX/2U directly, but we should announce planned changes to defaults as breaking changes and give edX/2U (and other early deployers like MIT ODL) a couple weeks to update their internal overrides accordingly. We can do so by making a fast-track DEPR issue for every batch of breaking changes we make.
refactor: move production defaults to common modules (#37045)
fix: studio api-docs crashes with 500 error
fix: studio api-docs crashes with 500 error
refactor: move production defaults to common modules (openedx#37045)
refactor: move production defaults to common modules (openedx#37045)
refactor: move production defaults to common modules (openedx#37045)