On 26/11/14 14:18, Andrew Wilkins wrote: > On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey <tim.pen...@canonical.com > <mailto:tim.pen...@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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
