config-changed error does not cause error state
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
High
|
Andrew Wilkins | ||
1.24 |
Fix Released
|
High
|
Tim Penhey | ||
1.25 |
Fix Released
|
High
|
Tim Penhey |
Bug Description
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://
yet juju status for the same service is not in an error state, but rather has:
$ juju status sca-app | grep agent-status -A5
current: executing
message: running commands
since: 11 Sep 2015 00:05:07Z
version: 1.24.5.1
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
summary: |
- unit does not go to error state + config-changed error does not cause error state |
description: | updated |
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 1.25-beta1 |
Changed in juju-core: | |
milestone: | 1.25-beta1 → 1.25-beta2 |
Changed in juju-core: | |
assignee: | nobody → Tim Penhey (thumper) |
milestone: | 1.25-beta2 → 1.26-alpha1 |
status: | Triaged → In Progress |
Changed in juju-core: | |
assignee: | Tim Penhey (thumper) → Andrew Wilkins (axwalk) |
tags: | added: hooks |
Changed in juju-core: | |
status: | In Progress → Fix Released |
Changed in juju-core: | |
milestone: | 1.26-alpha1 → 1.26-alpha2 |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
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.