upgrade-charm and default configuration values

[Marco Ceppi]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160308/083c52be/attachment.html>