incompatible charm upgrades

[William Reade]

On Fri, 2012-09-14 at 11:38 -0300, Gustavo Niemeyer wrote:
> 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! :-)

Yeah, this can wait :).

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

D'oh! Ok, this makes perfect sense. Am I right in thinking that `juju
set svc val=` will/should unset `val` in `svc`?

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

That was exactly the race scenario I was thinking of... but, for some
reason this approach (persisting locally) feels cleaner/saner than
maintaining multiple configs per service in global state. I *think* all
we need is to make sure we've locally persisted a config for version X
before we start to download version X, and we're golden; but having
multiple configs per service sounds like a recipe for confusion. Would
you expand on your concerns a little please?

Cheers
William