<div dir="ltr"><div class="gmail_quote"><div>Hi there Marco,</div><div><br></div><div dir="ltr">On Wed, Mar 9, 2016 at 4:18 AM Marco Ceppi <<a href="mailto:marco.ceppi@canonical.com">marco.ceppi@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello everyone!<div><br></div><div>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.</div></div></blockquote><div><br></div><div>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...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>MySQL</div><div><br></div><div>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:</div><div><br></div><div>[0] <a href="https://bugs.launchpad.net/charms/+source/mysql/+bug/1373862" target="_blank">https://bugs.launchpad.net/charms/+source/mysql/+bug/1373862</a><br></div><div><br></div><div>ELK</div><div><br></div><div>Recently, a few configuration options were changed for Kibana[1] that aligned it with the latest release of that software.</div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> 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].</div></div></blockquote><div><br></div><div>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:</div><div><br></div><div><a href="https://code.launchpad.net/~onlineservices-charmers/charms/trusty/elasticsearch/elasticsearch2">https://code.launchpad.net/~onlineservices-charmers/charms/trusty/elasticsearch/elasticsearch2</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Michael</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> 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.</div><div><br></div><div>[1] <a href="https://code.launchpad.net/~chris.macnaughton/charms/trusty/kibana/version_bump/+merge/276709" target="_blank">https://code.launchpad.net/~chris.macnaughton/charms/trusty/kibana/version_bump/+merge/276709</a><br></div><div>[2] <a href="https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1553256" target="_blank">https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1553256</a></div><div>[3] <a href="https://code.launchpad.net/~lazypower/charms/trusty/elasticsearch/20-bump/+merge/288423" target="_blank">https://code.launchpad.net/~lazypower/charms/trusty/elasticsearch/20-bump/+merge/288423</a></div><div><br></div><div>I'm inclined to merge these and properly educate users on configuration pinning and bundles to make sure the latest software works as expected</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> 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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,<br>Marco Ceppi</div></div>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju<br></a><br>
</blockquote></div></div>