[Maas-devel] Feature flag policy

[Jeroen Vermeulen]

On 18/08/14 06:31, Julian Edwards wrote:

> The flags themselves can be as simple as a setting in the Django config
> file.  This allows things to be active in development mode while
> disabled in production mode.  As an example of how to do this, grep for
> "DNS_CONNECT" in the source tree.

The problem with putting them in the Django config is that we won't be
able to access them from provisioningserver code.

In my view, feature flags should be (1) short-lived, and (2) related
much more closely to their feature than to other feature flags.  So I
still prefer simple variables somewhere at the top of the most relevant
module.

And *maybe*, as a separate discussion, a way to initialise a feature
flag as enabled on development systems:

    ENABLE_TEAPOT = this_is_a_dev_system()

Intelligence in feature flags worries me though: if TEABAG is also
behind a feature flag but won't be released just yet, will the
configuration with TEAPOT but without TEABAG get enough testing?

In theory it sounds ideal to have this all in one place so that the
all-knowing overseer can plan and configure and manage.  In practice, we
might be better prepared for scheduling uncertainty if work on each
feature defaults to having just that one feature enabled.  If enabling
feature A (about to be released) breaks feature B (still in
development), then B needs updating.  That's annoying but reasonable,
easy to understand, and relatively unsurprising.


Jeroen