<div dir="ltr">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?<div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 5:22 AM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/11/14 14:18, Andrew Wilkins wrote:<br>
> On Wed, Nov 26, 2014 at 6:47 AM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:tim.penhey@canonical.com">tim.penhey@canonical.com</a>>> wrote:<br>
><br>
>     Hi all,<br>
><br>
>     There are often times when we want to hook up features for testing that<br>
>     we don't want exposed to the general user community.<br>
><br>
>     In the past we have hooked things up in master, then when the release<br>
>     branch is made, we have had to go and change things there.  This is a<br>
>     terrible way to do it.<br>
><br>
>     Here is my proposal:<br>
><br>
>     <a href="http://reviews.vapour.ws/r/531/diff/#" target="_blank">http://reviews.vapour.ws/r/531/diff/#</a><br>
><br>
>     We have an environment variable called JUJU_FEATURE_FLAGS. It contains<br>
>     comma delimited strings that are used as flags.<br>
><br>
>     The value is read when the program initializes and is not mutable.<br>
><br>
>     Simple checks can be used in the code:<br>
><br>
>     if featureflag.Enabled("foo") {<br>
>       // do foo like things<br>
>     }<br>
><br>
>     Thoughts and suggestions appreciated, but I don't want to have the<br>
>     bike-shedding go on too long.<br>
><br>
><br>
> I like the idea of having flags.<br>
><br>
> I'm not sure about setting it at bootstrap and it being global. How<br>
> would we test upgrade scenarios where some agents have the feature, and<br>
> others don't?<br>
<br>
</div></div>The idea is that the machines get the flags when they are deployed using<br>
environment variables in the upstart script (or other service starting<br>
thingimy-widget).<br>
<br>
All agents in a given environment would have the same flags.<br>
<br>
I'm in two minds about whether feature flags should be able to be turned<br>
on and off on the fly.<br>
<br>
I'm mostly against it as we may have different workers for feature<br>
flags, and this would mean that we'd then have to code watchers for the<br>
flags in order to start and stop workers based on flag changes.<br>
<br>
I think simple is better here.<br>
<div class="HOEnZb"><div class="h5"><br>
Tim<br>
<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div>