incompatible charm upgrades

[William Reade]

On Tue, 2012-09-11 at 11:30 -0700, Clint Byrum wrote:
> Excerpts from William Reade's message of 2012-09-11 01:05:51 -0700:
> > * 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 ? :)

Sounds sensible, I'd just rather not have it default to true :). Changed
relations still feel tricky, though...

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

I've been thinking about this, and I'm having a lot of difficulty coming
up with even a *theoretical* implementation that isn't really complex
and unpleasant. I see where you're coming from; but would you talk a
little bit more about how you'd like to see it work in practice?

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

It bothers me a little that there's no way to express reasoned intent to
use a setting that also happens to be a default, but this approach makes
a lot of sense; thanks for the course correction.

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

Hmm, this gets kinda hairy. We guarantee a config-changed after start,
and I'm reluctant to break that. The keep-old-config-around suggestion
above could plausibly mesh nicely with this -- ie the charm always sees
the latest config applied to its current charm version -- but I really
am worried about the complexity this could introduce.

One *possibility* -- and I'm not 100% sure it's good -- would be to make
sure that the unit agent always persists its service config locally (ie
make sure it always runs config-changed hooks at the expected times, but
only uses settings that are right for the current charm). This would be
a little bit hairy, and we'd need to be careful with races, but I could
see it working... is this idea crazy?

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

Well, if we come up with some nice way to address your settings-removal
concerns, I think this problem evaporates (once we have a way to specify
the rev to *grade to, anyway). All the more reason to address that case,
then :).

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

lp:1050750 has a couple of questions in it; I would welcome further
feedback there.