incompatible charm upgrades

[Gustavo Niemeyer]

Hey William,

On Tue, Sep 11, 2012 at 5:05 AM, William Reade
<william.reade at canonical.com> wrote:
> Opening discussion on a topic that I think we've maybe handwaved a
> little in the past: how exactly can we determine when it's ok to upgrade
> charm X to charm Y? The obvious points of potential incompatibility are
> relations and service config (please shout if I've missed something).

The fact it is a subordinate or not seems relevant too.

> We've talked a little bit about relations, informally, and IIRC we
> decided:
>
> * if a service is participating in a relation, and that relation is
> change -- or not present -- in charm Y, the upgrade must be blocked.
> * it's fine to change/remove relations if the service is not using them.
> * it's always fine too add new relations. New peer relations will be
> automatically joined, just as they are on first deploy.

+1

> * if a *unit* is still participating in a removed relation when it
> detects an upgrade to charm Y, the upgrade must not be started until the
> relation is broken.
> * if a unit still has charm version X, and the service joins a relation
> present only in Y, the unit must not join the relation until it has
> upgraded to Y.

Very sensible.

> However, we haven't really talked about service config; I have a
> proposal, and I would again welcome discussion.
>
> * if a config setting is removed in charm Y, block the upgrade.

Not sure about this one. If the author decided it's all well and fine
without the setting, why would we prevent it?

> * if a config setting's type is changed in Y, block the upgrade.

+1, this would be messy.

> * if a new config setting is added, insert its default value into the
> service config.

+1

> * if a config setting's default is changed in Y, leave the original
> value of the setting in place, even if it matched the original default.

I'm on the fence on this one. Is there an implementation detail that
makes this behavior more convenient?

> * if a unit still has charm version X, and the service's config (for Y)
> changes, report the change as usual; similarly, in config-get, just
> report the service's current config even if it's intended for a
> different charm version.

+1

> I *think* the consequences here are reasonable -- my only real concern
> with this general approach is that it has a built-in ratchet effect: it
> won't be possible to *downgrade* a charm if the original upgrade added
> any config settings. That said, python doesn't allow for downgrades
> anyway, so maybe it's not a very important use case at this stage [0].

This is related to the question above, so will hold on it.

> Are any of these inconvenient for anyone (or just plain crack)? Speak up
> now, lest someone starts to implement this behaviour...

It feels great overall, thanks for the detailed coverage.

> [0] IMO it would be nice to be able to specify the rev you want to
> switch to, just in general; ATM the only rev you can actually upgrade to
> is the latest for the current charm. This feels like a relatively minor
> feature, that I imagine someone will casually add at some point; but if
> anyone forsees any problems with doing so, I'd be interested to hear
> about them.

+1 on all grounds.


gustavo @ http://niemeyer.net