Unit state during charm upgrade

[Gary Poster]

On 03/05/12 10:53, Benji York wrote:
> On Mon, Mar 5, 2012 at 10:48 AM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com>  wrote:
>> Excerpts from Francesco Banconi's message of 2012-03-05 09:03:56 -0500:
>>> Hi everybody,
>>>
>>> while working on functional tests for our charms, I've seen that, having
>>> a started unit, the unit state remains "started" during charm upgrade.
>>>
>>> In my tests I ended up waiting a few seconds before checking the unit
>>> state using `juju status`. However, in my opinion, the charm upgrade
>>> could be more testable if a state transition is performed during upgrade.
>>> E.g.: the charm switch to state "pending" (or "upgrading" or something
>>> else) when `juju upgrade-charm` is invoked, and then back again to
>>> "started" if the hook completes successfully.
>>>
>>> I hope my suggestion will be of some use.
>>> Thank you!
>>
>> what's the value add? if the upgrade hook executes quickly enough its just
>> introducing a race condition around watching for an ephemeral state.
>
> I think we would need something like the charm revision exposed so the
> test can know when the upgrade is complete.  We can always sleep for
> some amount of time, but that's obviously brittle.

Right.  AIUI from Francesco, the charm revision changes immediately as 
the update starts, so we already have that information, but in a way 
that doesn't help us determine when the upgrade is done.  I asked 
Francesco if it would be reasonable to move the charm number change to 
*after* the upgrade is complete, but he said that he believed this would 
violate existing Juju patterns elsewhere: the charm revision is usually 
exposed immediately.

@Kapil: A race condition is not involved with what we want.  For our 
tests, we want to know when the upgrade is complete.  Right now, unless 
we miss something, there is no way to determine that, if it passed 
successfully.

Given the current state of things, a test that wants to look at the 
charm's state after an upgrade now has to do the following:
- start upgrade
- wait an indeterminate amount of time for the upgrade to be done, with 
no indication of its completion.  If it ever changes to "error" there 
was a problem, but if it does not, does this mean that we are still 
upgrading, or does it mean that we finished successfully?  There is no 
way to know.

With Francesco's proposed change, the test does this.
- start upgrade
- loop until the status is no longer "updating".  If we never see the 
"updating" status that's fine: it must have been a fast update, but now 
we know we are ready to test the result of the update.

It seems like a simple, reliable solution to a real (testing) problem.

Gary