Greetings, I'm all for sensible defaults and eliminating or mitigating paper cut risk. Those are all good things. I do think we need to take a hard look at the potential impact of a default charm config option value change, any time that is considered. My main concern is that, in changing a default value, we risk breaking existing users. But as long as we give advanced notice, eta, updated docs, release notes, etc., I think it could be completely reasonable to pursue a default value change.
As I understand the original motivation behind this proposed default value change, when deploying the mysql charm into lxc, it may fail unless the dataset-size option value is set to something like 128MB instead of the default 80%. So, a user may not be able to just drop the mysql charm into lxc with the defaults and experience success. They need to set the config option value to something workable for their environment. That impacts adoption. ie. It doesn't "just work." If we do make the default value change, we need to take a look at the bundles in the charm store to identify and adjust any which rely on the established default value. For example... ;-) and I'm not at all biased: https://jujucharms.com/openstack-base/36 ( https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-36/archive/bundle.yaml ) That one is easy enough to identify and fix, but it underscores the need to take the time to identify, evaluate and discuss the risks, then define the things-to-do, and proceed if that is the consensus. Cheers, Ryan On Thu, Aug 13, 2015 at 10:15 AM, John Meinel <j...@arbash-meinel.com> wrote: > I believe there is work being done so that you can do "juju get" and send > that output directly into "juju set" or even "juju deploy --config". And I > think that's a much better story around repeatable deployments than trying > to make sure the defaults never change. If they really care about > repeatable they're probably going to pin the version of the charm anyway. > > So I'd bias clearly on the "fix something that isn't working well" rather > than "fear change because someone might depend on the current sketchy > behaviour". Obviously the call is somewhat situational. > > John > =:-> > On Aug 13, 2015 10:03 AM, "Jorge O. Castro" <jo...@ubuntu.com> wrote: > >> Hi everyone, >> >> See: https://bugs.launchpad.net/bugs/1373862 >> >> This morning Marco proposed that we change the default dataset-size >> from "80%" of the memory to "128M". >> >> Ryan thinks that before we make a default change like this that we >> should discuss the implications, for example, if you have an existing >> Juju MySQL deployment, and say you want to replicate that in another >> environment, the default change is an unexpected surprise to the user. >> >> I am of the opinion that MySQL is one of the first services people >> play with when trying Juju and that the charm not working ootb with >> the local provider is a big papercut we'd like to fix. >> >> >> >> -- >> Jorge Castro >> Canonical Ltd. >> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
