ring sync needs leader-switch tolerance
Bug #1448884 reported by
Edward Hope-Morley
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
swift-proxy (Juju Charms Collection) |
Fix Released
|
High
|
Edward Hope-Morley |
Bug Description
Currently if the cluster leader switches during a ring/builder sync across peers, the sync will fail unless the original leader can be restored and the process restarted. This is not yet supported by the charm and while leader switch is hopefully low probability with Juju leadership support, we should be able to recover from this if it happens.
Related branches
lp:~hopem/charms/trusty/swift-proxy/lp1448884
On hold
for merging
into
lp:~openstack-charmers-archive/charms/trusty/swift-proxy/next
- OpenStack Charmers: Pending requested
-
Diff: 941 lines (+380/-140)5 files modifiedREADME.Swift_ring_management (+28/-0)
hooks/swift_hooks.py (+128/-45)
lib/swift_utils.py (+133/-65)
unit_tests/test_swift_hooks.py (+11/-9)
unit_tests/test_swift_utils.py (+80/-21)
description: | updated |
Changed in swift-proxy (Juju Charms Collection): | |
milestone: | 15.07 → 15.10 |
Changed in swift-proxy (Juju Charms Collection): | |
milestone: | 15.10 → 16.01 |
description: | updated |
Changed in swift-proxy (Juju Charms Collection): | |
milestone: | 16.01 → 16.04 |
Changed in swift-proxy (Juju Charms Collection): | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
With leadership-election support arriving in the 15.07 charm release the idea of autorecovering in the charm makes less sense. This patch will be more of a refactor of the ring sync code to make it clearer what the sync flow is and with a view to adding in some juju actions to recover the cluster should things go wrong during ring syncing.