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.re...@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.marsh...@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@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 >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
