config-changed error does not cause error state

[Michael Nelson]

I'm testing a deploy in which, due to an error in a charm, the config-change hook failed, as I can verify by tailing the juju log:

http://paste.ubuntu.com/12332911/

yet juju status for the same service is not in an error state, but rather has:

$ juju status sca-app | grep agent-status -A5
        agent-status:
          current: executing
          message: running commands
          since: 11 Sep 2015 00:05:07Z
          version: 1.24.5.1
        agent-state: started

This leaves the unit in the 'started' state, but I can't do anything like debug-hooks (unit not in error state), upgrade-charm (seems to get queued, but not executed because of the running commands), as juju seems to be convinced that the unit is currently running commands.

$ juju --version
1.24.5-trusty-amd64

[Michael Nelson (michael.nelson)]

I reproduced this using the same mojo spec and application code revisions, and have uploaded the machine-0.log and unit log to chinstrap.canonical.com:/home/michaeln/bug-1494542-logs.tgz . I can't see any credentials in there, but it does have exact configurations of our app servers etc. - not sure if that's something to put public on the bug.

[Tim Penhey (thumper)]

The problem is that the 'juju run' command that is executed immediately after the hook goes into an error state bumps the unit out of the error state and it says it is now running commands.

However when it has finished, it never sets the unit status back to what it was.

The fix is to return it to the previous state when the juju run command has completed.

[Andrew Wilkins (axwalk)]

This has not been done for master yet.

[Andrew Wilkins (axwalk)]

Proposed fix for master: https://github.com/juju/juju/pull/3537