Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Configuration TypeDescriptionExamplesCurrent Mechanisms
System/Library ConfigurationPlatform-wide configuration and configuration needed by a specific 3rd party libraries
  • the Django database credentials
  • django.conf.settings (from lms/envs/*.py and cms/envs/*.py)
Library Feature Flagging and ConfigurationConfiguration needed by a specific 3rd party library
  • What steps to use in our assets pipeline
  • django.conf.settings (from lms/envs/*.py and cms/envs/*.py)
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

  • Whether microsites are enabled
  • Which discussion service host to read data from
  • the FEATURES dictionary in django.conf.settings
  • django-waffle switches (only for feature flagging)
  • ConfigurationModel.enableddjango.conf.settings
  • ConfigurationModel
A/B TestingEnabling/disabling a particular feature for subsets of the users of the platform 
  • django-waffle flags
Feature ConfigurationSpecific values which tune the behavior of a feature for all users of the platform
  • Which discussion service host to read data from
  • django.conf.settings
  • ConfigurationModel properties


Proposal

The problematic aspects of configuration are those for which we have multiple current mechanisms. Going forward, we should standardize on the following:

django.conf.settings (from lms/envs/*.py and cms/envs/*)py
Configuration TypeProposed MechanismRationale
System/Library Configuration

django.conf.settings (from lms/envs/*.py and cms/envs/*.py)

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 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

django-waffle flags

This is the functionality that django-waffle is centered around, and isn't supported by our other solutions.Feature Configuration

ConfigurationModel properties

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).