potential upgrade-charm bugs

[Kapil Thangavelu]

On Mon, Jun 4, 2012 at 6:34 AM, William Reade
<william.reade at canonical.com>wrote:

> Hey guys
>
> It crosses my mind that there are some interesting failure cases around
> upgrading charms whose metadata changes significantly; for example, a
> subordinate service could suddenly become non-subordinate (or vice
> versa); or interfaces could be added or removed.
>
> It seems, offhand, that interfaces can be added safely, but interface
> removal is trickier: it *can* be safe, but only if no relations are
> using that interface (and we don't have any checks for that either). So
> I feel we should allow these cases (with appropriate checks).
>
> However, I don't think that it ever makes sense to upgrade a service's
> charm and change subordination status in the process, and I think we
> should just flat-out refuse such attempts.
>
> Opinions?
>


Hi William,

That's a good point. The subordinate case doesn't concern me as much as a
normal relation, as the common case for subordinates is against the system
provided identity interface (juju-info). I think its sensible to check and
bail with appropriate warning if a currently established relation is no
longer valid with an upgraded charm. Ie. tell the user which relations are
no longer valid, and ask them to manually remove them before upgrading.
This state no longer valid on upgrade also applies to service config (ie
invalid/incompatible typing, (ie. str -> int). There perhaps the option  of
just warning and putting into place the new defaults (perhaps via a flag),
or requiring new config to be passed on upgrade.

cheers,
Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20120604/7223ca01/attachment.html>