opendevreview | kim nuri proposed openstack/swift master: WIP: Display host as both hostname and IP in swift-recon https://review.opendev.org/c/openstack/swift/+/893583 | 00:14 |
---|---|---|
opendevreview | Tim Burke proposed openstack/swift master: tests: boto is always <3.0 https://review.opendev.org/c/openstack/swift/+/896471 | 01:34 |
opendevreview | Tim Burke proposed openstack/swift master: tests: Stop using distutils.dir_util.mkpath https://review.opendev.org/c/openstack/swift/+/896472 | 01:34 |
opendevreview | Tim Burke proposed openstack/swift master: Swap find_executable for which https://review.opendev.org/c/openstack/swift/+/896473 | 01:34 |
opendevreview | Tim Burke proposed openstack/swift master: Swap find_executable for which https://review.opendev.org/c/openstack/swift/+/896473 | 01:58 |
reid_g | Hello, QQ. Somebody put the wrong zone information in to the rings and started rebalancing. I need to fix the zones but the question is, should we finish the iterations on rebalancing before fixing the zones or just fix the zones now and complete new rebalances?? | 15:10 |
reid_g | We probably need to do like 8 more rebalances on some rings ATM. | 15:10 |
timburke | reid_g, how many rebalances along are you already? how capacity constrained were you before all this came along? if it's early enough and you had space enough before, i might be inclined to try rolling back to an earlier version of the ring/builder (before the nodes with the wrong zones were ever added), give the cluster a while to get back to that state, then move forward from there | 15:44 |
timburke | if you're nervous about either of those points, i'd say fix the zone in the builder before the next rebalance (so we're moving parts around in the right directions), but otherwise stick with the normal, slow-and-steady approach for rebalances | 15:45 |
timburke | short of a pretty severe capacity crunch, the biggest risk in rebalances is moving too quickly, causing availability issues because there's no longer enough overlap between the ring saying where data *should* be and the actual disks reflecting where data *is* | 15:45 |
opendevreview | Clay Gerrard proposed openstack/swift master: WIP: Refactor SLO tests https://review.opendev.org/c/openstack/swift/+/896466 | 15:52 |
opendevreview | Clay Gerrard proposed openstack/swift master: slo: refactor GET/HEAD response handling https://review.opendev.org/c/openstack/swift/+/893578 | 15:52 |
opendevreview | Clay Gerrard proposed openstack/swift master: slo: part-number=N query paramater support https://review.opendev.org/c/openstack/swift/+/894570 | 15:52 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: slo: part-number=N query paramater support https://review.opendev.org/c/openstack/swift/+/894570 | 17:27 |
reid_g | Thanks timeburke! I will check with my team about how they want to proceed. I'm going to be moving on to a new company next week. | 17:27 |
reid_g | I mean timburke! | 17:28 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: s3api: Support GET/HEAD request with PartNumber https://review.opendev.org/c/openstack/swift/+/894580 | 17:35 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: slo: part-number=N query paramater support https://review.opendev.org/c/openstack/swift/+/894570 | 17:42 |
opendevreview | ASHWIN A NAIR proposed openstack/swift master: s3api: Support GET/HEAD request with PartNumber https://review.opendev.org/c/openstack/swift/+/894580 | 17:42 |
opendevreview | Alistair Coles proposed openstack/swift master: wip: s3 mixed policy multipart uploads https://review.opendev.org/c/openstack/swift/+/896588 | 19:48 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!