swift-ring-builder set_info should update replication ip/port even when not explicitly provided
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
New
|
Undecided
|
Unassigned |
Bug Description
I'm in the midst of rebuilding a Swift cluster. The old "cluster" was really just a box with a bunch of drives in it; when the CPU died, I figured I'd take the opportunity to actually spread devices around a bit. The old ring looked like
$ swift-ring-builder object.builder
object.builder, build version 46, id f7be51f1798341c
256 partitions, 3.000000 replicas, 1 regions, 1 zones, 5 devices, 1.43 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 0 (0:00:00 remaining)
The overload factor is 0.00% (0.000000)
Ring file object.ring.gz is up-to-date
Devices: id region zone ip address:port replication ip:port name weight partitions balance flags meta
0 1 1 192.168.50.30:6203 192.168.50.30:6203 d1 8000.00 161 -0.42
1 1 1 192.168.50.30:6204 192.168.50.30:6204 d2 8000.00 162 0.20
3 1 1 192.168.50.30:6206 192.168.50.30:6206 d5 8000.00 161 -0.42
4 1 1 192.168.50.30:6207 192.168.50.30:6207 d6 8000.00 161 -0.42
5 1 1 192.168.50.30:6208 192.168.50.30:6208 d8 6000.00 123 1.43
I went to move (some of) the drives to their new homes:
$ swift-ring-builder object.builder set_info /d2 192.168.
Device d1r1z1-
Device d4r1z1-
Device d5r1z1-
Device d0r1z1-
None of the replication IPs moved, which is some cruddy UX. If the old IP/port matches the old replication IP/port, and the new IP/port changes without specifying a replication IP/port, it seems like a pretty safe assumption that replication IP/port should move too.