incompatible charm upgrades

[Gustavo Niemeyer]

On Tue, Sep 11, 2012 at 5:52 AM, William Reade
<william.reade at canonical.com> wrote:
> On Tue, 2012-09-11 at 05:28 -0300, Gustavo Niemeyer wrote:
>> Hey William,
>>
>> On Tue, Sep 11, 2012 at 5:05 AM, William Reade
>> <william.reade at canonical.com> wrote:
>> > 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).
>>
>> The fact it is a subordinate or not seems relevant too.
>
> Very good point. So, yes, a subordinate-ness change should also block an
> upgrade.
>
>> > * if a config setting is removed in charm Y, block the upgrade.
>>
>> Not sure about this one. If the author decided it's all well and fine
>> without the setting, why would we prevent it?
>
> Because I can't figure out how to update the config state. If we leave
> the setting in place, the config will no longer be "valid", and this
> will complicate any future attempts to change settings even if we
> special-case-hack our way through it at upgrade time; but, if we remove
> the setting, existing units that have not yet completed their upgrades
> may not react well to its absence.
>
> Suggestions?

We can follow your suggestion and just block for the moment then, and
come back to this after we get everything else working well. It
certainly won't be an issue before people can actually use the charms.
:-)


>> > * 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.
>>
>> I'm on the fence on this one. Is there an implementation detail that
>> makes this behavior more convenient?
>
> Consider what will happen if the default for (say) a "use-upstream"
> setting changes. Changing a deployment in this way strikes me as a
> pretty serious potential violation of Least Surprise... *maybe* it's on
> the charm authors to be kind to their users, but I remain a bit
> uncomfortable with the idea.

There's a distinction to be made in terms of what being a nice charm
author means, and what the system does. Seriously harmful cases like
the described example seems to be a bad maintainership which we won't
be able to protect against either way, because the setting might well
not even be a config setting at all and might be changing under the
hood.

Either way, I agree with your principle. If there is a choice of
preserving something on an upgrade, it feels positive to attempt to
change less rather than more as a rule of thumb.


gustavo @ http://niemeyer.net