incompatible charm upgrades

[Gustavo Niemeyer]

On Tue, Sep 11, 2012 at 5:28 AM, William Reade
<william.reade at canonical.com> wrote:
> On Tue, 2012-09-11 at 10:05 +0200, William Reade wrote:
>> We've talked a little bit about relations, informally, and IIRC we
>> decided:
>>
>> * if a service is participating in a relation, and that relation is
>> change -- or not present -- in charm Y, the upgrade must be blocked.
>> * it's fine to change/remove relations if the service is not using them.
>> * it's always fine too add new relations. New peer relations will be
>> automatically joined, just as they are on first deploy.
>> * if a *unit* is still participating in a removed relation when it
>> detects an upgrade to charm Y, the upgrade must not be started until the
>> relation is broken.
>> * if a unit still has charm version X, and the service joins a relation
>> present only in Y, the unit must not join the relation until it has
>> upgraded to Y.
>
> Just realised: I haven't considered the impact of --force here. My gut
> says that "--force" always means "just do it, damn the consequences";
> but I'm not sure just how catastrophic it might be for a unit to attempt
> to participate in a relation that doesn't exist. Thoughts?

--force is related to ignoring runtime errors, which doesn't quite
feel like the same thing as the structural constraints you've
described. Most of them seem to be necessary to ensure a working
charm, and a sane system for us to code and debug.


gustavo @ http://niemeyer.net