Wednesday, 2022-02-09

opendevreviewAlistair Coles proposed openstack/swift master: Trim sensitive information in the logs (CVE-2017-8761)  https://review.opendev.org/c/openstack/swift/+/82258510:53
*** cschwede- is now known as cschwede11:56
afaranhahi timburke__, I'm having some issue on a patch to swift, it fails due to "The nodeset "centos-8-arm64" was not found.", this part was not touched by the patch, is this some issue currently on swift for Xena branch? https://review.opendev.org/c/openstack/swift/+/82790114:34
opendevreviewAlistair Coles proposed openstack/swift master: container-server: plumb includes down into _get_shard_range_rows  https://review.opendev.org/c/openstack/swift/+/56984715:30
opendevreviewTim Burke proposed openstack/swift stable/xena: Make arm jobs voting (but not the pipeline)  https://review.opendev.org/c/openstack/swift/+/82858416:21
opendevreviewTim Burke proposed openstack/swift stable/xena: Move CI from CentOS 8 to CentOS 8 Stream  https://review.opendev.org/c/openstack/swift/+/82858516:21
timburke__afaranha, thanks for letting me know! i *think* those two should square it, though i probably need to squash them together16:21
afaranhatimburke++ thanks!16:25
afaranhawe'll backport that to wallaby as well, do we need to backport these patches as well?16:25
opendevreviewAndre Aranha proposed openstack/swift stable/xena: Add FIPS CI jobs  https://review.opendev.org/c/openstack/swift/+/82790116:26
timburke__shouldn't be -- the arm64 jobs started with https://github.com/openstack/swift/commit/41a3e1ff which is in xena but not wallaby16:29
opendevreviewTim Burke proposed openstack/swift stable/xena: Add FIPS CI jobs  https://review.opendev.org/c/openstack/swift/+/82790116:38
opendevreviewTim Burke proposed openstack/swift stable/xena: Fix arm64 jobs on stable/xena  https://review.opendev.org/c/openstack/swift/+/82858816:38
opendevreviewTim Burke proposed openstack/swift master: CI: fix lower-constraints job  https://review.opendev.org/c/openstack/swift/+/82860419:03
timburke__almost meeting time!20:54
*** timburke__ is now known as timburke20:54
kotagood morning20:57
mattoliverMorning20:58
timburke#startmeeting swift21:00
opendevmeetMeeting started Wed Feb  9 21:00:11 2022 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:00
opendevmeetThe meeting name has been set to 'swift'21:00
timburkewho's here for the swift meeting?21:00
kotao/21:00
acoleso/21:02
timburkeas usual, the agenda's at https://wiki.openstack.org/wiki/Meetings/Swift21:03
timburke#topic PTG21:03
timburkefirst, a reminder to register21:03
timburke#link https://openinfra-ptg.eventbrite.com/21:03
timburkethe team sign-up instructions are also out21:03
timburke#link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027051.html21:04
timburkei'll put together a doodle poll by next week at the latest to help us select times21:04
mattoliverSorry im here too, just getting distracted by parenting duties. 21:04
mattoliverKk21:04
timburkethe last couple times, i had a time shift part-way through the week -- has that worked out OK for everyone, or would it be better to try to keep it consistent all week? or no real preference?21:05
mattoliverI guess I don't mind, however can't guarantee brain power at 2am  😜 21:06
mattoliverSo it worked well for me. 21:06
acolessplit times seems fairer 21:07
timburke👍21:08
timburke#topic summit21:08
timburkeit's fast approaching!21:09
timburkei hadn't realized, but the call for presentations is closing soon!21:09
timburke#link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027129.html21:09
timburke#link https://cfp.openinfra.dev/app/berlin-202221:09
timburkeif you've got ideas for swift talks, please get them submitted asap :-)21:10
timburke#topic election season21:11
timburkenominations are now open!21:11
timburke#link http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027117.html21:11
timburkei'm happy to run for swift ptl again -- though i need to write up my statement :-)21:12
mattoliver+100 for swift ptl! So long as you ok with it :) 21:12
mattoliverTim for swift ptl21:13
timburkeall right, i think that covers the general announcements...21:13
mattoliverPhone lost the Tim in thr first one21:13
timburke:-)21:13
timburke#topic 2.29.0 release21:13
timburkeif you haven't already, i'd encourage everyone to read over the proposed change log21:14
timburke#link https://review.opendev.org/c/openstack/swift/+/82694721:14
timburkethere's a lot of great stuff in there!21:14
acolestimburke: run run run for ptl!!21:14
timburkethere's still one more patch i'd like to land, and a couple more release notes, but i think i should be ready to tag later this week or early next week21:15
timburkespeaking of the patch i'd like to land...21:17
mattolivernice21:17
timburke#topic signatures in logs21:17
timburkethe new registry module has landed21:17
timburke#link https://review.opendev.org/c/openstack/swift/+/82569421:17
mattoliveroh cool! 21:17
timburkeand acoles has a +2 on the actual fix21:18
timburke#link https://review.opendev.org/c/openstack/swift/+/82258521:18
kotaregistry, cool21:19
mattoliverThanks for cleaning them up and pushing them across the line (or almost across for the last one). 21:20
timburkeacoles, i think you still had a few comments in test_proxy_logging -- is it safe to assume those could be addressed as a follow-up?21:20
mattoliverI like how in fixing the CVE we actually add a usful feature inside swift for devs. 21:21
kota+121:21
acoleswait, I think I fixed those comments today but maybe I didn't push to gerrit :O21:22
timburkethen i'll hold off on approving *right now* ;-)21:23
timburkefwiw, i was eyeing the "_sensitive_headers and _sensitive_params are not cleared at end of this test" comment in particular, though i think there was another case-sensitivity comment that looked un-addressed21:24
timburkehmm... i keep leaving "mpu expiration" on the agenda hoping that clayg will be around to give a quick run-down21:25
mattoliverits we can just skip it until he's here ;)21:25
timburkei had this memory that there were a bunch of patches, and it was tricky to see which arrow had the wood behind it... but maybe a bunch of them got abandoned?21:27
timburkei *think* this is the primary patch:21:27
timburke#link https://review.opendev.org/c/openstack/swift/+/80070121:27
timburkeat any rate, that's the one we're trying out in prod :P21:28
timburkewell, anyway21:29
timburke#topic open discussion21:29
timburkewhat else should we bring up this week?21:29
zaitcevI'm bored with vPTG.21:29
timburkeme too. not the same :(21:29
mattoliverwho knows, could be the last virtual one21:30
timburke🤞21:30
mattoliverI've been playing with encoding the device into the container db ID. As this ID is recreated after any rsyc or rsync_then_move. 21:31
mattoliverhttps://review.opendev.org/c/openstack/swift/+/82806921:31
mattoliverOr rather adding it not really encoding it.21:31
mattoliverIn an attempt to make it easier to debug replication issues because you can then go look at incoming/outgoing syncs and know where each id came from (at least at a particular timestamp).21:32
timburkeoh yeah, i'd been meaning to take a look at that...21:32
mattoliverThe db id is just text so shouldn't hurt. And the device is pulled from the broker path. 21:33
mattoliverSo long as you have unique device names across the cluster, this will allow you to do a lookup in your ring to know what node is syncing with a container. 21:33
mattoliverThis kinda came up when I was attempting to figure out which handoff was breaking / resetting the root epoch. But got the incoming_sync table and was a deadend.21:35
timburkedo we make an explicit recommendation to have unique device names across the cluster? i know it's certainly the way *i'd* recommend, but i'm not sure if we've got that written down anywhere...21:35
mattoliverno we don't. But I could add some text to the doc to recommend it. 21:36
timburkemattoliver, speaking of, have we seen that root epoch thing come up any more recently? if memory serves, there was some patch to at least detect the situation better...21:36
acolestimburke: re https://review.opendev.org/c/openstack/swift/+/822585, it's all good, I got confused by the gerrit comments, I think I did address my own concerns in patchset 1221:36
timburke👍21:37
mattoliverI'd love to add something more, like device ID, but I can grab the device from the path for free as it all happens inside the broker classes. And anything else might involve having access to the ring. 21:37
timburke*cough, cough* https://review.opendev.org/c/openstack/swift/+/67067421:38
timburke;-)21:38
mattoliverOn another note, I have a "new" version of serialiaztion V2 based on the discussions from the last vPTG: https://review.opendev.org/c/openstack/swift/+/82727621:38
timburkei ought to rebase that and try it out again21:39
mattoliveroh yeah. 21:39
mattoliverthat would change things :)21:39
mattoliveron the ring V2 ptg front, managed to get it to know behave in both Py2 and Py321:40
timburke\o/21:40
mattoliverpy2 has seeking backward issues. So turns out I just always seek forwards and now V2 will work for both versions. 21:40
timburkethanks for pushing on that. i keep meaning to look at it again21:41
mattolivernps21:41
mattoliverjust wanted to get something up before the next PTG :P21:42
acolesI revived an old patch of timburke 's this week https://review.opendev.org/c/openstack/swift/+/56984721:43
acolesit's a change to the way we lookup shard ranges in container backend21:43
acolesdelegates more filtering to the sql query rather than python21:44
acolesturns out it makes a big difference to the lookup time i.e. faster21:45
acolesespecially when there are larger numbers of shard ranges in the table (like, 1000's)21:45
mattoliverbrilliant! 21:46
acolesI benchmarked it with a copy of one of our production db's and it's 20x faster!21:47
mattoliver\o/21:47
mattoliverdoing it down in SQL land would be far more efficient. Nice. I wonder if there are other areas we could push things down to SQL land. 21:47
timburketheeeee change itself is pretty targetted... i wonder if it's the sort of thing where it's worth running an experiment in prod...21:49
timburkeall right21:50
timburkethank you all for coming, and thank you for working on swift!21:50
timburke#endmeeting21:50
opendevmeetMeeting ended Wed Feb  9 21:50:37 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:50
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2022/swift.2022-02-09-21.00.html21:50
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2022/swift.2022-02-09-21.00.txt21:50
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2022/swift.2022-02-09-21.00.log.html21:50
opendevreviewTim Burke proposed openstack/swift master: read-only: Only act on Swift paths  https://review.opendev.org/c/openstack/swift/+/82861222:01

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