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.wit...@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.bent...@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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > > > -- > Wayne Witzel III > wayne.wit...@canonical.com > > -- > 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
