-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-23 12:27 AM, John Meinel wrote:
> Thinking it through a bit more, I wonder if that is the best
> option. Because if someone is already bootstrapped on CloudSigma
> you really don't have any reason for it to not support CloudSigma.
> It is ju
I don't ever see us moving a provider back behind a feature flag after we
move it out from one, but I agree with the point. If a user was using a
devel version and in a release, we moved a provider behind a flag, they
would stop working and their bootstrapped environment would be stuck, and
that wo
So if we want feature flagged providers I think the best option is to
change registration code path.
Probably my ideal would be to have
environs.RegisterFlaggedProvider(name, flag string, p EnvironProvider,
alias ...string)
and then we can track in environs/config.go that a given provider name is
That sounds reasonable to me Aaron. Also Eric just suggested I put the set
flag in export_test.go, he did something similar for GCE and it worked, so
I will try that.
Thanks.
On Wed, Apr 22, 2015 at 9:25 AM, Aaron Bentley
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2015-04-2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-04-22 09:00 AM, Wayne Witzel wrote:
> I've been told to place cloudsigma provider behind a feature flag,
> but the result of that is that the provider is not registered
> unless the env variable for cloudsigma is set.
>
> So after wrapping the
I've been told to place cloudsigma provider behind a feature flag, but the
result of that is that the provider is not registered unless the env
variable for cloudsigma is set.
So after wrapping the registration of the provider in the feature flag
(see:
https://github.com/juju/juju/commit/0a2cf42dc
