Greenfield prod-ready Django settings without YAML

[kdmccormick]

Background

• Let's talk about OEP-45 (Configuring & Operating Open edX) open-edx-proposals#587

Proposal

"Just" start fresh with idiomatic Python-defined Django settings files.

There would be four new settings files:

• lms/settings.py
• lms/test_settings.py (derived from lms/settings.py)
• cms/settings.py (derived from lms/settings.py)
• cms/test_settings.py (derived from cms/settings.py and lms/test_settings.py)

The recommended mechanism for configuring edx-platform would be to define a Django settings module for LMS and for CMS, each based on their respective settings.py module, and then set DJANGO_SETTINGS_MODULE to point to the correct custom module in each environment. This is standard Django practice.

Several things would be deprecated:

• all of lms/envs/
• all of cms/envs/
• yaml-based config via LMS_CFG and CMS_CFG

Backwards compatibility

Tutor would need to change significantly to adapt to this, but it could certainly be done, and possibly could be done in a way that doesn't break any patch points from the perspective of Tutor plugin devs and users.

Direct deployers of edx-platform would need to adapt. We would leave lms/envs/ and cms/envs/ in place for 6 months to allow for migration. After they are removed, direct deployers could still use them (and YAML config) by copying the settings modules they need into their private fork and/or deployment pipeline, and setting DJANGO_SETTINGS_MODULE accordingly.

[kdmccormick]

fyi @feanil

[feanil]

I realized that we may also want a standard dev_settings.py

[kdmccormick]

@feanil good pooint. I was imagining that Tutor would take care of overriding settings.py for development, but on second thought, if we want to support bare-metal dev, then we need dev_settings.py as well.

One question that raises is whether dev_settings.py would use localhost:xxxx as the LMS_BASE vs. a container-friendly domain like local.openedx.io. If the latter, then Tutor could use dev_settings.py as a base.

[feanil]

Yea, I'm totally okay with it using a container friendly domain by default.