...
Configuration Type | Description | Examples | Current Mechanisms | ||||
---|---|---|---|---|---|---|---|
System/Library Configuration | Platform-wide configuration and configuration needed by a specific 3rd party libraries |
|
| ||||
Library Feature Flagging and Configuration | Configuration needed by a specific 3rd party library |
|
| Feature Flag | Specific values which tune the behavior of a feature for all users of the platform, including enabling or disabling the feature site-wide 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/Library 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 | . | pyDjango libraries read out of this standard location for settings, and we would need to modify them to use any other solution. |
Feature FlagFlagging and Configuration | ConfigurationModel .enabledproperties | ConfigurationModel adds an enabled field to all subclasses, and allows individual subclasses to define their own configuration fields. 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 ). |