incompatible charm upgrades

[William Reade]

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?

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

Cheers
William