swift-proxy does not allow storage nodes to resync rings if they don't get rebalanced
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| swift-proxy (Juju Charms Collection) |
Fix Released
|
High
|
Edward Hope-Morley | ||
Bug Description
We need to decide what, semantically, we want to allow. Currently if I start 1 proxy and 3 storage units with replicas and zones == 3, the rings will be built, balanced and synced once the third storage unit is related with the proxy. For every subsequent storage unit added, we will have to wait until min_part_hours has elapsed before the rings will again be rebalanced and distributed which would actually require an new relation to be added in order to trigger the process.
The way things are right now is in part to protect against large data rebalancing when storage units are added but, it also provides a very easy way for storage units to be added and never used so not so good. A better way IMO would be to have a default min_part_hours of 0 thus allowing unconstrained rebalancing and syncing at cluster build time. As a safety measure the value could then be set higher once cluster has formed.
Related branches
- Liam Young (community): Approve
-
Diff: 2054 lines (+1204/-341)7 files modifiedconfig.yaml (+21/-4)
hooks/swift_context.py (+15/-15)
hooks/swift_hooks.py (+252/-240)
hooks/swift_utils.py (+625/-82)
unit_tests/test_swift_context.py (+56/-0)
unit_tests/test_swift_hooks.py (+39/-0)
unit_tests/test_swift_utils.py (+196/-0)
| Edward Hope-Morley (hopem) wrote | #1 |
| Changed in swift-proxy (Juju Charms Collection): | |
| assignee: | nobody → Edward Hope-Morley (hopem) |
| status: | New → In Progress |
| Changed in swift-proxy (Juju Charms Collection): | |
| status: | In Progress → Fix Committed |
| Changed in swift-proxy (Juju Charms Collection): | |
| milestone: | none → 15.01 |
| Changed in swift-proxy (Juju Charms Collection): | |
| status: | Fix Committed → Fix Released |
I suppose this bug can replace https:/