incompatible charm upgrades

[Gustavo Niemeyer]

On Fri, Sep 14, 2012 at 3:20 AM, William Reade
<william.reade at canonical.com> wrote:
>> --remove-removed-relations ? :)
>
> Sounds sensible, I'd just rather not have it default to true :). Changed
> relations still feel tricky, though...

Basics first! :-)

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

Yeah, we need to think more about this, but I suggest just doing the
obviously right first, and then we can improve from there.

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

I think the scheme above mentioned by Clint actually allows for that.
If the admin *sets* a value, it ends up in the services settings, and
will override the default, even if it changes.

It would definitely be wrong to change a default value that was in
fact explicitly set.

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

Yeah, this sounds like a nice direction. We could say that on upgrade
the old settings are cloned and corrected to fit the new charm, and
each charm observes their respective version, but juju set always acts
on the lastest version. Of course, this is all internal details.. to
the admin it just works and there's a single visible concept of
service settings.

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

The above sounds equivalent, but at the same time it seems to reduce
some of the pain that would be introduced by having to manipulate it
locally upfront (imagine a unit that has the charm download in
progress by the time the upgrade happens).

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

+1


gustavo @ http://niemeyer.net