Application Configuration and Feature Flagging

Owned by Calen Pennington (Deactivated)
Last updated: May 24, 2023 by Brian Mesick
2 min read

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/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)
Feature Flagging and Configuration

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)
  • django.conf.settings
  • ConfigurationModel
A/B TestingEnabling/disabling a particular feature for subsets of the users of the platform 
  • django-waffle flags


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/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. Django libraries read out of this standard location for settings, and we would need to modify them to use any other solution.
Feature Flagging and Configuration

ConfigurationModel properties

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.