Proposal: feature flag implementation for Juju

[Ian Booth]

I like feature flags so am +1 to the overall proposal. I also agree with the
approach to keep them immutable, given the stated goals and complexity
associated with making them not so.

I think the env variable implementation is ok too - this keeps everything very
loosely coupled and avoids polluting a juju environment with an extra config
attribute.

On 26/11/14 08:47, Tim Penhey 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.
> 
> Tim
>