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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >> >> >> >> -- >> Wayne Witzel III >> [email protected] >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > -- Wayne Witzel III [email protected]
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
