incompatible charm upgrades

[William Reade]

Hi all

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

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

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.
* if a config setting's type is changed in Y, block the upgrade.
* if a new config setting is added, insert its default value into the
service config.
* 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.
* 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.

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

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

Cheers
William

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