Proposal: feature flag implementation for Juju

[Tim Penhey]

Because I explicitly wanted to avoid touching config.

We want a simple method for checking flags that can't fail. Dealing with
config doesn't give us that.

I don't think that using an environment variable to define feature flags
is too terrible.  We don't want to make it too easy ;-)

Tim

On 26/11/14 17:10, John Meinel wrote:
> Given the constraints you just listed (globally set in the environment,
> etc), why not just make it environment config, rather than
> yet-another-way to set env config?
> 
> John
> =:->
> 
> 
> On Wed, Nov 26, 2014 at 5:22 AM, Tim Penhey <tim.penhey at canonical.com
> <mailto:tim.penhey at canonical.com>> wrote:
> 
>     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>
>     > <mailto: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
> 
> 
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
>