Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2

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 TypeDescriptionExamplesCurrent Mechanisms
System ConfigurationPlatform-wide configuration
  • the Django database credentials
  • django.conf.settings (from lms/envs/*.py and cms/envs/*.py)
Library 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 FlagA setting to enable/disable an entire feature throughout the platform for all users
  • Whether microsites are enabled
  • the FEATURES dictionary in django.conf.settings
  • django-waffle switches
  • ConfigurationModel.enabled
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:

Configuration TypeProposed MechanismRationale
System 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.conf.settings (from lms/envs/*.py and cms/envs/*.py)

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

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

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).
  • No labels