Background
At edX, in both edx-platform
and in other services, there is often a need to make functionality configurable, either to allow it to be turned on and off on a user or installation specific basis, or to be tuned for a specific implementation. As is often the case in evolving software projects, there are several different ways current in use to achieve the same effect. This proposal will set out a standard for how we would like configuration to happen on an ongoing basis.
Types of Configuration
Configuration Type | Description | Examples | Current Mechanisms |
---|---|---|---|
System Configuration | Platform-wide configuration |
|
|
Library Configuration | Configuration needed by a specific 3rd party library |
|
|
Feature Flag | A setting to enable/disable an entire feature throughout the platform for all users |
|
|
A/B Testing | Enabling/disabling a particular feature for subsets of the users of the platform |
| |
Feature Configuration | Specific values which tune the behavior of a feature for all users of the platform |
|
|
Proposal
The problematic aspects of configuration are those for which we have multiple current mechanisms. Going forward, we should standardize on the following:
Configuration Type | Proposed Mechanism | Rationale |
---|---|---|
System Configuration |
| This is where Django knows to read settings from. Any mechanism we build to replace this would need to emulate this module, and wouldn't be able to use Django for any of its implementation. |
Library Configuration |
| Django libraries read out of this standard location for settings, and we would need to modify them to use any other solution. |
Feature Flag |
| ConfigurationModel adds an enabled field to all subclasses. It also provides live modification (an advantage over django.conf.settings ) and logging of who modified the configuration and when (an advantage over django-waffle ). |
A/B Testing |
| This is the functionality that django-waffle is centered around, and isn't supported by our other solutions. |
Feature Configuration |
| ConfigurationModel allows you to specify bundles of configuration as a Django model. This gives us a strongly typed and easily managed way of packaging up feature configuration. It also provides live modification (an advantage over django.conf.settings ) and logging of who modified the configuration and when (an advantage over django-waffle ). |