Actually: the example bundle I listed is moot. It uses the percona-cluster charm. And it's pinned to a specific charm revision like a good little bundle.
On Thu, Aug 13, 2015 at 10:57 AM, Ryan Beisner <ryan.beis...@canonical.com> wrote: > 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
