Simplify edx-platform settings

[kdmccormick]

Intended final settings structure

• openedx/envs/common.py: Defaults shared between LMS and CMS (new!).

  • lms/envs/common.py: LMS default settings. Wherever possible,
    prod-ready values should be used; where not possible, obviously-incorrrect
    values should be used.

    • $THIRD_PARTY/lms/production.py: Third-party providers (like edx.org) and
      tools (like Tutor) will need to provide a custom setting settings file
      derived from common.py in order to deploy LMS.

    • lms/envs/test.py: Override LMS settings for unit tests. Should work
      in a local venv as well as in CI.

    • lms/envs/development.py: Override LMS settings so that it can run
      "bare metal" directly on a developer's local machine using debug-friendly
      settings. Will use local.openedx.io (which resolves to 127.0.0.1) as
      a base domain, which should be suitable for third-party tools as well.

      • $THIRD_PARTY/lms/dev.py: Third-party tools (like Tutor, and 2U's
        Devstack) will need to provide a custom settings file derived from
        development.py in orer to serve a local LMS.

  • cms/envs/common.py

    • $THIRD_PARTY/cms/production.py:

    • cms/envs/test.py

    • cms/envs/development.py

      • $THIRD_PARTY/cms/dev.py

Tasks

Preview Give feedback

1. refactor: Clean up lms/envs/production.py cruft #36115
   +0
2. [Attempt 2] refactor: Clean up lms/envs/production.py cruft #36131
   create-sandbox +1
3. feat: dump_settings management command #36162
   +0
4. feat: Make dump for fns, classes more stable and helpful #36188
   +0
5. refactor: Use derived_settings to lazy load settings. #36124
   +0
6. [old] refactor: A Better API for Derived Settings #36132
   +0
7. feat!: A Better API for Derived Settings #36192
   +0
8. refactor: Use derive_settings to lazy load settings. #36205
   +0
9. docs: Settings Simplification ADR #36224
   +0
10. build: Start watching the production.py files. #36225
    +0
11. Clean up cms/envs/production cruft (like we did for lms/envs/production)
12. Make initial openedx/envs/common, using imported settings in cms/envs/common into openedx/envs/common. Ensure code annotations are loaded for generated settings docs.
13. Move settings up from (cms,lms)/envs/production -> (cms,lms,openedx)/envs/common.
14. Merge any remaining (lms,cms)/envs/common definitions -> openedx/envs/common.
15. Make (lms,cms)/envs/development.py and update Bare Metal guide. Warn community that devstack.py will actually go away in one release.
16. Ensure (lms,cms)/envs/common actually have good production defaults

Related / nice to have

• De-crazy the logging settings overrides.
• De-crazy the MODULESTORE settings conversions.
• Collapse FEATURES dict
• Warn/fail when "required" common settings, e.g. secrets, aren't overridden.

Open questions

• When exactly do we "rebase" Tutor's settings onto (lms,cms)/envs/(common,development)? Most likely, we should do it all at once when those four files are ready, as Tutor's settings are all coupled together into a Jinja hierarchy.
• Should the settings object should have same type signature between LMS and CMS?

Potential Follow-on Work

• Simplify Logging Config
  • Related Info
    • A draft for making a decision on managing logging configurations  #28603
    • https://discuss.openedx.org/t/improving-the-flexibility-of-the-edx-platform-log-configuration/5379/4

[kdmccormick]

@robrap , @dianakhuang -- I have split this off from the greater Let's Talk About OEP-45 issue. We'll be tracking the ongoing edx-platform settings simplification here.