incompatible charm upgrades

[Gustavo Niemeyer]

On Fri, Sep 14, 2012 at 11:49 AM, William Reade
<william.reade at canonical.com> wrote:
> 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?

It's a bit more involved than that. Besides having to deal with
configuration upfront before even starting to download, every time the
configuration changes we'd have to tell whether it is for the charm we
have at hand or not, and there's actually no good way to say whether
it is or not because the only thing we can tell is that we have both a
configuration change and an upgrade at the same time. This seems to go
back to Clint's first suggestion: do not run changed if there's an
upgrade in progress.


gustavo @ http://niemeyer.net