Not logged in - Log In / Register

Revision 3 as of 2011-02-15 07:50:06

Clear message

Feature Flags

FeatureFlags allow Launchpad's configuration to be changed while it's running, and for particular features or behaviours to be exposed to only a subset of users or requests.



A feature flag has a string name, and has a dynamically-determined value within a particular context such as a web or api request. The value in that context depends on determining which scopes are relevant to the context, and what rules exist for that flag and scopes. The rules are totally ordered and the highest-prority rule determines the relevant value.


A change to a flag in production counts as a production change: it is made by a LOSA on request from a squad lead, or other relevant manager. Ask in #launchpad-ops or #launchpad-dev.

Web interface


A html comment at the bottom of rendered pages describes which features were looked up, and which scopes were consulted to make that decision. This doesn't include features that could be active but aren't relevant to the page, or scopes that may be active but aren't relevant to deciding the value of the features.


Feature flags are designed and intended to be fast enough that they can be used as much as is useful within reason. The result of a flag and of a scope is checked at most once per request.

Naming conventions

Flags should be named as

where each of the parts is a legal Python name (so use underscores to join words, not dashes.)

The scope is the general area of Launchpad this relates to: eg 'code', 'librarian', ...

The feature is the particular thing that's being controlled, such as 'recipes' or 'render_time'.

The effect is typically 'enabled', 'visible', or 'timeout'. These should always be in the positive sense, not 'disabled'. If timeouts are given, they should be in seconds (decimals can be given in the value.)

Checking a feature flag

Adding a new feature flag

Adding a new scope controller

See also