Proposal: feature flag implementation for Juju

[Tim Penhey]

On 26/11/14 14:18, Andrew Wilkins wrote:
> On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey <tim.penhey at canonical.com
> <mailto:tim.penhey at canonical.com>> wrote:
> 
>     Hi all,
> 
>     There are often times when we want to hook up features for testing that
>     we don't want exposed to the general user community.
> 
>     In the past we have hooked things up in master, then when the release
>     branch is made, we have had to go and change things there.  This is a
>     terrible way to do it.
> 
>     Here is my proposal:
> 
>     http://reviews.vapour.ws/r/531/diff/#
> 
>     We have an environment variable called JUJU_FEATURE_FLAGS. It contains
>     comma delimited strings that are used as flags.
> 
>     The value is read when the program initializes and is not mutable.
> 
>     Simple checks can be used in the code:
> 
>     if featureflag.Enabled("foo") {
>       // do foo like things
>     }
> 
>     Thoughts and suggestions appreciated, but I don't want to have the
>     bike-shedding go on too long.
> 
> 
> I like the idea of having flags.
> 
> I'm not sure about setting it at bootstrap and it being global. How
> would we test upgrade scenarios where some agents have the feature, and
> others don't?

The idea is that the machines get the flags when they are deployed using
environment variables in the upstart script (or other service starting
thingimy-widget).

All agents in a given environment would have the same flags.

I'm in two minds about whether feature flags should be able to be turned
on and off on the fly.

I'm mostly against it as we may have different workers for feature
flags, and this would mean that we'd then have to code watchers for the
flags in order to start and stop workers based on flag changes.

I think simple is better here.

Tim