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 =:-> On Wed, Nov 26, 2014 at 8:17 AM, Tim Penhey <tim.pen...@canonical.com> wrote: > 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.pen...@canonical.com > > <mailto:tim.pen...@canonical.com>> wrote: > > > > 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> > > > <mailto: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 <mailto:Juju-dev@lists.ubuntu.com> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
