upgrade-charm and default configuration values

[Rick Harding]

Thanks Marco, if I understand what we're dealing with is there a pattern
here where we can get a little mix of both worlds?

What I'm wondering is that, if the charm author needs to make these default
changes for a good reason, that we can bring it to user's attention using
the blocked status? Can we upgrade, but mark the charm as 'blocked on
accepting new config default' and teach users that if they run something,
such as an unset command, or some next config changed event, that the charm
hooks can respond to in a standard fashion?

This allows the charm author to move forward, but also makes sure that
significant changes are made much more apparent to end users.

On Tue, Mar 8, 2016 at 12:18 PM Marco Ceppi <marco.ceppi at canonical.com>
wrote:

> Hello everyone!
>
> tl;dr: upgrade-charm also updates default configuration which can break
> running deployments. Should we be updating charms anyways esp since
> defaults are now broken for fresh deploys? Discuss.
>
> We've had a problem pop up a few times and I wanted to start a discussion
> about it with the community. Default configuration values and upgrade-charm.
>
> We have a few examples where the charm by default is broken, but we're
> getting resistance on updating these because of the default action in Juju.
> On upgrade-charm, if the default configuration is still set on the charm,
> then it will be updated on charm upgrade. I understand why this seems like
> a good idea but I have a few examples where this really hurts.
>
> MySQL
>
> There is a long standing issue with MySQL on local/LXC where because of a
> faulty configuration option default value which has existed since the charm
> was created, it attempts to consume 80% of available ram for a cache
> instead of just a sane default (300M for example) which MySQL experts
> recommend. However, because of the implication of the change for running
> deployments the merge request is essentially on-hold:
>
> [0] https://bugs.launchpad.net/charms/+source/mysql/+bug/1373862
>
> ELK
>
> Recently, a few configuration options were changed for Kibana[1] that
> aligned it with the latest release of that software. This, and changes to
> logstash mean the elasticsearch charm need to be updated too. As it stands
> today, with the defaults in the charms, there is no working ELK stack[2].
> There's a merge[3] to address this but again is being met with resistance
> because this implicit issue of existing deployments get the latest
> configuration if it's still default.
>
> [1]
> https://code.launchpad.net/~chris.macnaughton/charms/trusty/kibana/version_bump/+merge/276709
> [2] https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1553256
> [3]
> https://code.launchpad.net/~lazypower/charms/trusty/elasticsearch/20-bump/+merge/288423
>
> I'm inclined to merge these and properly educate users on configuration
> pinning and bundles to make sure the latest software works as expected but
> am interested in feedback and discussing if we need to potentially change
> the default behavior of Juju to if not allow the user to address this at
> least provide feedback that not only will this new charm be added but these
> configuration values updated.
>
> I understand a lot of the ELK problems go away with resources in 2.0, but
> the MySQL is an example that we run into a bit of times when addressing
> problems in configuration.
>
> Thanks,
> Marco Ceppi
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160309/f5a10407/attachment.html>