Re: Proposal: feature flag implementation for Juju

[Tim Penhey]

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"  > 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
> mailto: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

Re: Proposal: feature flag implementation for Juju

[John Meinel]

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" 
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
>  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

Re: Proposal: feature flag implementation for Juju

[William Reade]

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
 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

Re: Proposal: feature flag implementation for Juju

[Casey Marshall]

+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
>>
> 



signature.asc
Description: OpenPGP digital signature
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Proposal: feature flag implementation for Juju

[John Meinel]

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

Re: Proposal: feature flag implementation for Juju

[Tim Penhey]

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  > wrote:
> 
> On 26/11/14 14:18, Andrew Wilkins wrote:
> > On Wed, Nov 26, 2014 at 6:47 AM, 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.
> >
> >
> > 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
> 
> 


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Proposal: feature flag implementation for Juju

[Ian Booth]

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

Re: Proposal: feature flag implementation for Juju

[John Meinel]

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 
wrote:

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

Re: Proposal: feature flag implementation for Juju

[Tim Penhey]

On 26/11/14 14:18, Andrew Wilkins wrote:
> On Wed, Nov 26, 2014 at 6:47 AM, 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.
> 
> 
> 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

Re: Proposal: feature flag implementation for Juju

[Andrew Wilkins]

On Wed, Nov 26, 2014 at 6:47 AM, 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.


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?

Cheers,
Andrew
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Proposal: feature flag implementation for Juju

[Katherine Cox-Buday]

I like the idea. Thinking out loud: do we want to combine this with "the
wrench" so that we have 1 consistent way to fiddle with Juju behavior?

On Tue, Nov 25, 2014 at 4:47 PM, 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

Proposal: feature flag implementation for Juju

[Tim Penhey]

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