• Immutable Page
• Info
• Attachments
• More Actions:Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

The purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess.

Dynamic Configuration

Launchpad has a registry of configuration options that can be changed by admins through the web ui, without restarting Launchpad.

As a Launchpad developer/operator
I want to turn features on and off without a heavyweight deployment
so that I can more adroitly test and deploy new features
and so that I can recover from emergencies by cutting-off problem features

As a Launchpad developer/operator
I want to limit some features to subsets of users
so that I can do A:B testing, or long-running closed betas.

• This is not a mechanism for general per-user configuration
• This is not a complete replacement for static configuration or other parts of the deployment process
• This only affects new code that specifically uses it; it doesn't magically affect existing code
• This may become a replacement for things that are currently done through SQL queries or configuration files
• This embraces "feature flags" and more, such as site-wide notifications.
• Dark launches
• Closed betas
• Deploy-then-activity
• Scram switches

Rationale

Why are we doing this now?

• We want people to land features faster, and to deploy more often. Having control over when features are generally exposed separately from landing the code may help.

• This could support things like site-wide notifications which would help our users by warning them when Launchpad's about to go offline.

• Some developers are interested in A:B testing of UIs and this would help with that too.

• Some other sites find this very useful: see http://www.scribd.com/doc/16877392/10-Deploys-Per-Day-Dev-and-Ops-Cooperation-at-Flickr

• At the 2010-02 team leads meeting there was enthusiastic support for feature flags but they've stalled.

What value does this give our users? Which users?

• site-wide notifications would be nice
• if it helps develop and deploy Launchpad faster, that benefits them

Stakeholders

Who really cares about this feature? When did you last talk to them?

• LOSAs
• Launchpad devs
• Design group?
• Architect and product strategist

Constraints and Requirements

Must

• A function that can be called from a template or other code, that tells you the value of a configuration item.
• The function must be very cheap to call so that it does not cause performance problems even if it's called several times per request.
• Feature flags can be used to hide or disable some user interface items.

Nice to have

• Configuration scopes:
  • "on edge"
  • "for authenticated/unauthenticated users"
  • "in readonly mode"
  • "for x% of users"
  • "for users in the beta group"
• Configuration that can be changed while in readonly mode.
• Configuration is validated before it is applied: eg if something must be an IP address, we won't let the admin commit a change that makes it invalid.

Must not

• Reduce test coverage by encouraging us to multiply scenarios excessively.
• Cause entanglement by having the same feature flag checked at many points in the code.

Subfeatures

Other LaunchpadEnhancementProposals that form a part of this one.

• Site Wide Notification (to be written)

Workflows

What are the workflows for this feature?

Change configuration

LOSA goes to https://launchpad.net/+config where they see a simple web form allowing them to edit the configuration.

Developers can go there to see but not edit the configuration.

Normal users are not allowed to see it.

Provide mockups for each workflow.

Success

How will we know when we are done?

• You can check flags in code or templates.
• You can change the configuration.
• People do actually change the configuration.

How will we measure how well we have done?

• Adoption of feature flags.
• Developers and LOSAs report satisfaction with the facility and it becomes a standard practice.

Thoughts?

Put everything else here. Better out than in.

• Perhaps needs a better name that "dynamic configuration" that's not confusable with static configuration.
• As a general rule, each switch should be checked only once or only a few time in the codebase. We don't want to disable the same thing in the ui, the model, and the database.

Implementation

The API is: config(name) => value.

This should probably live on a zope utility? Is "config" confusable with other names, and if so what should we call it instead?

The flags are named with the same syntax as Python identifiers. All punctuation is reserved so that we can try scope selectors like server=edge/user_group=beta/soyuz_build_from_branch=True.

The value is a Unicode string.

We will add a machine-readable registry of known names, with a help string and a description of the type to be stored in them. (A little like the Mailman admin interface but much simpler.)

The values are stored in a database table, with two columns: name, value. (If we add scope selectors we'll add a third column, so you can quickly pull out all the rows possibly relevant to the name.)