upgrade-charm and default configuration values

Wed Mar 9 03:19:41 UTC 2016

Hi there Marco,

On Wed, Mar 9, 2016 at 4:18 AM 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.
>

I think the updating of default config options is a good discussion to
have, but more specifically, the question I feel needs answering is: Can a
charm not only update the default config options (to point to a new major
version, for eg.) but also update it's support to only handle that new
default option. This is, afaiui, what seems to happen. More details below...

>
> 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.
>

The issue isn't just that the default config options were changed - if you
check that MP [1] you'll see kibana3 used a javascript configuration file
on the unit itself (search for files/charm/config.js), whereas kibana4 uses
a yml file (search for files/charm/config.yml).

So once I upgrade-charm to this version, even if I've explicitly set my
kibana_source and kibana_source_checksum options so it won't unexpectedly
get new defaults of kibana4, it still won't work because my kibana3 won't
know what to do with the yml config file - it'll still expect the js one
(or perhaps it'd just keep using the old file - but the init script which
runs /srv/kibana4 would fail). In that case, it may be better if I'd not
set kibana_source so I would upgrade to the new version - not sure.

That is, the change here to upgrade-charm would break an existing
deployment. I'm not saying it was the wrong thing to land those changes,
just that we need to be aware (and make sure people who use the charms for
more than demo's are aware).

> 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].
>

I don't think that's true - we're using elasticsearch2, kibana4 and
logstash2 for an ELK deployment currently (since late last year). The
change in the kibana charm (to kibana4) meant we needed to use ES2.x and
Logstash2.x. I explicitly didn't land the es2 and logstash2 charm changes
in the upstream stable charms for the above reason, instead creating an
elasticsearch2 branch:

https://code.launchpad.net/~onlineservices-charmers/charms/trusty/elasticsearch/elasticsearch2

Not ideal - but it won't break existing deployments. If you think it's
better, I can propose the elasticsearch2 charm (and the related logstash2)
 for merging into the main "stable" trusty charms, but we just need to be
aware that we may break existing deployments if people upgrade.

I don't know that you can generally update a major version of a service
automatically on upgrade-charm without affecting related services. We have
an existing project which currently uses ES1.x which we're upgrading to 2.x
(not via upgrade-charm). If you want more details about why we can't simply
upgrade-charm, feel free to reach out to Wes Mason, who's doing the upgrade.

Cheers,
Michael

> 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/d509b473/attachment.html>