Proposal: feature flag implementation for Juju

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.

Re: Proposal: feature flag implementation for Juju

I like the idea. Thinking out loud: do we want to combine this with "the wrench" so that we have 1 consistent way to fiddle with Juju behavior? On Tue, Nov 25, 2014 at 4:47 PM, Tim Penhey wrote: > Hi all, > > There are often times when we want to hook up features for testing that > we don't want

Re: Proposal: feature flag implementation for Juju

On Wed, Nov 26, 2014 at 6:47 AM, 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 t

Re: Proposal: feature flag implementation for Juju

On 26/11/14 14:18, Andrew Wilkins wrote: > On Wed, Nov 26, 2014 at 6:47 AM, 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

Re: Proposal: feature flag implementation for Juju

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 wrote: > On 26/11/14 14:18, Andrew Wilkins wrote: > > On Wed, Nov 26, 2014

Re: Proposal: feature flag implementation for Juju

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 pollutin

Re: Proposal: feature flag implementation for Juju

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/

Re: Proposal: feature flag implementation for Juju

I don't think you gain anything over: feature-flags: foo,bar,baz It doesn't have to be 1 config item per flag, it gives you the same syntax as the env variable, and it puts it in the place where you're going to need to effectively put it for every machine to read it during initialization. John =