Feature flag for a provider?

[Wayne Witzel]

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 would be no good.

I like the idea of having juju just work and I think moving this in to the
providers Bootstrap call is good. I will make a up a card for that work.
Thanks John.


On Thu, Apr 23, 2015 at 12:27 AM, John Meinel <john at arbash-meinel.com>
wrote:

> 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
> flagged with a given feature flag, and have
> environs.Provider() check if a given provider is flagged, and only return
> it if the flag is set.
>
>
> 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 just broken if it
> isn't working. (Imagine they used a version of juju that didn't have the
> flag, and upgraded to a version that requires the flag, and suddenly
> everything just breaks.)
>
> What I'd rather see is that only "juju bootstrap" pays attention to
> whether this is a supported provider. And everything else just treats it as
> a fully recognized provider.
>
>
> That might be easiest if we just change CloudSigma.Bootstrap() to check
> for the flag? Does that work out ok for you? That still lets us install the
> provider support, if you're using the provider it JustWorks, and we just
> give you an Error when Bootstrap is called pointing you for how you can
> enable this provider.
>
> John
> =:->
>
>
> On Wed, Apr 22, 2015 at 6:19 PM, Wayne Witzel <wayne.witzel at canonical.com>
> wrote:
>
>> 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 <
>> aaron.bentley at canonical.com> wrote:
>>
>>> -----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 registration of the provider in the feature
>>> > flag (see:
>>> >
>>> https://github.com/juju/juju/commit/0a2cf42dcf051fe43bd803ebb144358723b4af82
>>> ),
>>> >
>>> >
>>> the tests no longer pass, since there is no registered provider for
>>> > cloudsigma. Manually calling s.SetFeatureFlag(feature.CloudSigma)
>>> > from the Suite and/or Test setup methods doesn't help since by that
>>> > point the "init" for each provider has already been run.
>>> >
>>> > Looking for suggestions? My thought is that the flag isn't needed
>>> > since by nature providers are contained and their code is only
>>> > called if you explicitly use the provider.
>>>
>>> I think there's a potential quality issue.  I don't know anything
>>> about the state of the cloud sigma provider code, but since it's being
>>> kept behind a feature flag, I have to think
>>> a) The code is not yet production quality or
>>> b) The API isn't stable.
>>>
>>> Say you're using Juju 2.5, in which the cloud sigma provider is fully
>>> production quality.  You create an environment.  Then you go to a
>>> machine that has Juju 2.4, where the provider was not
>>> production-quality, and try to perform an operation on that
>>> environment.  Does Juju break?  Does the environment?
>>>
>>> Because you weren't paying attention to the Juju version number, you
>>> may be surprised by poor behaviour.  Instead, it would be better if
>>> Juju said: "CloudSigma is not production-quality in this version of
>>> Juju.  To enable it anyway, set JUJU_DEV_FEATURE_FLAGS to $FOO."
>>>
>>> So to avoid surprising users, I think a feature flag makes sense.
>>>
>>> Aaron
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJVN6FkAAoJEK84cMOcf+9hXR8IAKoenxmb8797B7xaNB842ZkH
>>> tlwwvsc/joO8Cy73OPFyNg1NQ14g4FVCUJJ6q0qgj51ubIrB1725a0XwilUYSme5
>>> uQGqEebZx6o9Q1SCP7uxOAZ4SEH7KftjIiqKG7kTzV93ZSeJtyK3Y7K7IuKw18UL
>>> VvOdhxrAie/dBnxhx16CqqbJcSj21RqLmd9osgL+gWTPtZ+UkAwV5nDqunAfaqt4
>>> 9DeoYloYVeqaFlQoTsyMB0hxd3Z63S+gHcjGWSRfAqdXCOZFjMntdbq8+dOMDMvB
>>> FkL0GBKliC7tPio2/w7OF4UW8AGMxQvMGddJflOFFt+CNAGwaLtxf6mHuA9jRGw=
>>> =VdEM
>>> -----END PGP SIGNATURE-----
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>>
>>
>> --
>> Wayne Witzel III
>> wayne.witzel at canonical.com
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>


-- 
Wayne Witzel III
wayne.witzel at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150423/b35d7ffb/attachment.html>