incompatible charm upgrades

[Clint Byrum]

Excerpts from William Reade's message of 2012-09-11 01:05:51 -0700:
> 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.

--remove-removed-relations ? :)

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

+1 to all as well

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

This means "no charm can ever remove a config setting." We should think
long and hard about this. I don't think thats reasonable, so we need
to think of a way to handle this situation. I think the right thing to
do is to alert the upgrade-charm user, and to keep these setting values
somewhere so that admins can extract them with 'juju get'.

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

Agreed, and I think a policy for the official store of "Config settings
cannot change type" is also reasonable.

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

-1, python juju does it the exact opposite of that, and it was on my
request. The scenario is that a charm author may fix a security flaw by
setting the default. The way to do this is just to make these settings
cascading.. so values in the service structure are only there if they
override the defaults, and on fetch you do something like

if services has a value
  return that
else if charm has a default value
  return that

> * 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 you can't fire config-changed events until the units are upgraded.
Its entirely possible, even likely, that on upgrade the meaning of a config
setting changes.

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

I'd prefer that downgrading be possible, but that it not be considered
the primary target. If the behaviors are a little bit weird on downgrade,
we can disable it and require a --force-downgrade flag. This pattern
has worked out well for Debian and Ubuntu for a long time.

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

Sounds like a nice Wishlist bug to me. :)