Proposal: feature flag implementation for Juju

[Tim Penhey]

Yes, that is exactly what the code that came with the proposal did :-)

Tim

On 27/11/14 23:40, John Meinel wrote:
> It sounded like we needed the env set in agents as well. What gets them
> set there? Just a change to the upstart job that runs them?
> 
> John
> =:->
> 
> On Nov 27, 2014 12:52 PM, "William Reade" <william.reade at canonical.com
> <mailto:william.reade at canonical.com>> wrote:
> 
>     So, having spoken to Tim about this, and coming to understand the
>     motivations a bit more, I think the "env var propagated everywhere, no
>     exceptions" approach is the winner.
> 
>     The deciding factor is that environ-config requires an API connection,
>     and that (one of) the motivating use case(s) involves exposing
>     incomplete CLI commands via feature flag (and I'm not aware of ones
>     that can't be fulfilled by env vars). I understand that environ-config
>     is superior in some other respects, but it's also more complex; and
>     furthermore I'd like to avoid having multiple mechanisms for the same
>     thing.
> 
>     The biggest risk is that people will start to use and depend upon
>     feature flag behaviour, so I require that anyone using a feature flag
>     make it abundantly clear that it's unsupported behaviour, by (1)
>     including something like "DEV" in the var name and (2) logging its
>     usage promiscuously, and making clear in those messages that the
>     behaviour is not supported.
> 
>     Cheers
>     William
> 
>     On Wed, Nov 26, 2014 at 4:50 PM, Casey Marshall
>     <casey.marshall at canonical.com <mailto:casey.marshall at canonical.com>>
>     wrote:
>     > +1 for feature flags in general and +1 for using environment variables
>     > in upstart to get them to the servers & agents.
>     >
>     > I think it'd be nice to have an environment variable per flag, with a
>     > common prefix JUJU_FEATURE_. That way, if you need to check one in a
>     > package init(), you don't have to parse the whole list of flags to
>     find
>     > the one you care about -- or depend on a globally initialized
>     parsing of
>     > that list.
>     >
>     > env config seems reasonable, but dealing with parsing, errors and then
>     > making that config globally available at init seems complex and not
>     > always feasible.
>     >
>     > How about defining them "free form" in an env config field, which is
>     > then used to emit the env vars as described above to the upstart
>     config
>     > during bootstrap?
>     >
>     > -Casey
>     >
>     > On 11/25/2014 10:16 PM, Ian Booth wrote:
>     >> 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
>     >>>
>     >>
>     >
>     >
>     > --
>     > 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
>     >
> 
>     --
>     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
> 
> 
>