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" <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> > 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 > > [email protected] <mailto:[email protected]> > > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > -- > Juju-dev mailing list > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
