peer relation disappears during upgrade of juju
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
High
|
William Reade | ||
1.18 |
Fix Released
|
Critical
|
William Reade | ||
juju-core (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Trusty |
Fix Released
|
Critical
|
Unassigned |
Bug Description
Upgrading a running environment from 1.17.7 to 1.18.0, I noticed that the peer relation of a service disappears during the upgrade process (at least I think it does).
The keystone charm uses the peer relation for storage and propagation of usernames/passwords between units; however when the config-changed hook fires as part of the upgrade-juju process (which I'm assuming its mean't to), the peer relation is not accessible:
2014-04-07 09:49:10 INFO juju-log Creating service credentials for 's3_ec2_nova'
2014-04-07 09:49:10 INFO config-changed Traceback (most recent call last):
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed main()
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed hooks.execute(
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed self._hooks[
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed f(*args)
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed remote_unit=unit)
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed add_service_
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed service_password = get_service_
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed passwd = peer_retrieve(
2014-04-07 09:49:10 INFO config-changed File "/var/lib/
2014-04-07 09:49:10 INFO config-changed 'peer relation {}'.format(
2014-04-07 09:49:10 INFO config-changed ValueError: Unable to detectpeer relation cluster
I resolved the config-changed failure and then used juju run to check that the cluster relation has re-appeared:
jenkins@test-01:~$ juju run --unit keystone/0 "relation-ids cluster"
and then after resolving another config-changed error;
jenkins@test-01:~$ juju run --unit keystone/0 "relation-ids cluster"
cluster:2
it re-appears; this behaviour is not desirable as it means that all services don't know they have peers during an juju upgrade.
Related branches
- Juju Engineering: Pending requested
-
Diff: 1184 lines (+411/-116)29 files modifiedstate/api/agent/state.go (+1/-1)
state/api/common/life.go (+1/-1)
state/api/deployer/machine.go (+1/-1)
state/api/firewaller/machine.go (+2/-2)
state/api/firewaller/service.go (+2/-2)
state/api/firewaller/unit.go (+3/-3)
state/api/keyupdater/authorisedkeys.go (+2/-2)
state/api/logger/logger.go (+2/-2)
state/api/machiner/machine.go (+1/-1)
state/api/params/params.go (+1/-1)
state/api/provisioner/machine.go (+9/-9)
state/api/provisioner/provisioner.go (+1/-1)
state/api/uniter/charm.go (+2/-2)
state/api/uniter/relationunit.go (+3/-3)
state/api/uniter/service.go (+3/-3)
state/api/uniter/unit.go (+29/-9)
state/api/uniter/unit_test.go (+19/-0)
state/api/uniter/uniter.go (+3/-3)
state/api/upgrader/upgrader.go (+3/-3)
state/apiserver/uniter/uniter.go (+38/-0)
state/apiserver/uniter/uniter_test.go (+31/-0)
state/unit.go (+21/-0)
state/unit_test.go (+41/-0)
testing/filetesting/filetesting_test.go (+2/-0)
worker/uniter/modes.go (+0/-10)
worker/uniter/relationer.go (+6/-4)
worker/uniter/relationer_test.go (+28/-13)
worker/uniter/uniter.go (+83/-38)
worker/uniter/uniter_test.go (+73/-2)
- Juju Engineering: Pending requested
-
Diff: 1727 lines (+941/-114)34 files modifiedstate/api/agent/state.go (+1/-1)
state/api/common/life.go (+1/-1)
state/api/deployer/machine.go (+1/-1)
state/api/firewaller/machine.go (+2/-2)
state/api/firewaller/service.go (+2/-2)
state/api/firewaller/unit.go (+3/-3)
state/api/keyupdater/authorisedkeys.go (+2/-2)
state/api/logger/logger.go (+2/-2)
state/api/machiner/machine.go (+1/-1)
state/api/params/params.go (+1/-1)
state/api/provisioner/machine.go (+7/-7)
state/api/provisioner/provisioner.go (+1/-1)
state/api/uniter/charm.go (+2/-2)
state/api/uniter/relationunit.go (+3/-3)
state/api/uniter/service.go (+3/-3)
state/api/uniter/unit.go (+29/-9)
state/api/uniter/unit_test.go (+19/-0)
state/api/uniter/uniter.go (+3/-3)
state/api/upgrader/upgrader.go (+3/-3)
state/apiserver/uniter/uniter.go (+38/-0)
state/apiserver/uniter/uniter_test.go (+31/-0)
state/unit.go (+21/-0)
state/unit_test.go (+41/-0)
testing/filetesting/filetesting.go (+198/-0)
testing/filetesting/filetesting_test.go (+285/-0)
testing/filetesting/package_test.go (+14/-0)
utils/file_test.go (+13/-0)
utils/file_unix.go (+18/-0)
utils/file_windows.go (+6/-0)
worker/uniter/modes.go (+0/-10)
worker/uniter/relationer.go (+6/-4)
worker/uniter/relationer_test.go (+28/-13)
worker/uniter/uniter.go (+83/-38)
worker/uniter/uniter_test.go (+73/-2)
Changed in juju-core: | |
status: | New → Triaged |
importance: | Undecided → Critical |
milestone: | none → 1.19.0 |
Changed in juju-core: | |
assignee: | nobody → William Reade (fwereade) |
Changed in juju-core: | |
status: | Triaged → In Progress |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core (Ubuntu Trusty): | |
status: | New → Triaged |
importance: | Undecided → Critical |
Changed in juju-core: | |
importance: | Critical → High |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
This bug was fixed in the package juju-core - 1.18.1-0ubuntu1
---------------
juju-core (1.18.1-0ubuntu1) trusty; urgency=medium
* New upstream point release, including fixes for:
- Upgrading juju 1.16.6 -> 1.18.x fails (LP: #1299802).
- Peer relation disappears during juju-upgrade (LP: #1303697).
- public-address of units changes to internal bridge post upgrade
(LP: #1303735).
- Unable to deploy local charms without series (LP: #1303880).
- juju scp no longer allows multiple extra arguments to be passed
(LP: #1306208).
- juju cannot downgrade to same major.minor version with earlier
patch number (LP: #1306296).
-- James Page <email address hidden> Sat, 12 Apr 2014 07:04:37 +0100