Tuesday, 2023-09-26

opendevreviewkim nuri proposed openstack/swift master: WIP: Display host as both hostname and IP in swift-recon  https://review.opendev.org/c/openstack/swift/+/89358300:14
opendevreviewTim Burke proposed openstack/swift master: tests: boto is always <3.0  https://review.opendev.org/c/openstack/swift/+/89647101:34
opendevreviewTim Burke proposed openstack/swift master: tests: Stop using distutils.dir_util.mkpath  https://review.opendev.org/c/openstack/swift/+/89647201:34
opendevreviewTim Burke proposed openstack/swift master: Swap find_executable for which  https://review.opendev.org/c/openstack/swift/+/89647301:34
opendevreviewTim Burke proposed openstack/swift master: Swap find_executable for which  https://review.opendev.org/c/openstack/swift/+/89647301:58
reid_gHello, 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_gWe probably need to do like 8 more rebalances on some rings ATM.15:10
timburkereid_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 there15:44
timburkeif 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 rebalances15:45
timburkeshort 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
opendevreviewClay Gerrard proposed openstack/swift master: WIP: Refactor SLO tests  https://review.opendev.org/c/openstack/swift/+/89646615:52
opendevreviewClay Gerrard proposed openstack/swift master: slo: refactor GET/HEAD response handling  https://review.opendev.org/c/openstack/swift/+/89357815:52
opendevreviewClay Gerrard proposed openstack/swift master: slo: part-number=N query paramater support  https://review.opendev.org/c/openstack/swift/+/89457015:52
opendevreviewASHWIN A NAIR proposed openstack/swift master: slo: part-number=N query paramater support  https://review.opendev.org/c/openstack/swift/+/89457017:27
reid_gThanks 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_gI mean timburke!17:28
opendevreviewASHWIN A NAIR proposed openstack/swift master: s3api: Support GET/HEAD request with PartNumber  https://review.opendev.org/c/openstack/swift/+/89458017:35
opendevreviewASHWIN A NAIR proposed openstack/swift master: slo: part-number=N query paramater support  https://review.opendev.org/c/openstack/swift/+/89457017:42
opendevreviewASHWIN A NAIR proposed openstack/swift master: s3api: Support GET/HEAD request with PartNumber  https://review.opendev.org/c/openstack/swift/+/89458017:42
opendevreviewAlistair Coles proposed openstack/swift master: wip: s3 mixed policy multipart uploads  https://review.opendev.org/c/openstack/swift/+/89658819:48

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!