21:00:27 <timburke> #startmeeting swift
21:00:27 <opendevmeet> Meeting started Wed Oct 12 21:00:27 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:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:27 <opendevmeet> The meeting name has been set to 'swift'
21:00:36 <timburke> who's here for the swift team meeting?
21:00:59 <kota> o/
21:01:03 <cschwede> o/
21:01:22 <timburke> whoa! a cschwede!
21:01:50 <cschwede> :)
21:02:10 <zaitcev> A rare meeting indeed.
21:02:14 <mattoliver> o/
21:02:57 <mattoliver> cschwede is here too!
21:03:31 <timburke> not sure if acoles or clayg are around -- i think clay's kind of busy trying to get an nvidia release lined up
21:03:41 <timburke> first up
21:03:48 <timburke> #topic PTG
21:04:20 <timburke> i've booked time slots and updated the etherpad list to point to the right place!
21:04:31 <mattoliver> oh nice!
21:04:35 <kota> good
21:05:24 <timburke> i went with 2100-2300 M-Th (though i wonder if we could get away with starting a little earlier to get more of acoles's (and cschwede's?) time
21:05:32 <cschwede> great, happy to meet all of you at least virtually :)
21:06:10 <timburke> though it wouldn't help kota -- timezones are hard :-(
21:06:24 <kota> in UTC?
21:06:37 <timburke> yes -- so i know it'd be a bit of an early start
21:06:48 <kota> seems like just morning not so matter
21:08:18 <mattoliver> if earlier makes it easier for Al and cschwede then I'm ok with it.
21:08:19 <timburke> if we try for an hour earlier, it's 5am -- might be "just morning" for you, but that doesn't match my experience ;-)
21:08:44 <mattoliver> lol
21:09:43 <kota> it's still ok, i think
21:09:46 <kota> :)
21:09:52 <timburke> i went with just M-Th to make sure we don't run into kota and mattoliver's weekend, and kept shorter slots to try to keep everyone well rested
21:10:21 <timburke> if you've got topics for the PTG, please add them to the etherpad!
21:10:23 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-antelope
21:11:00 <timburke> and if we feel like we need more time, we can always book more slots
21:12:17 <timburke> that's all i've got for ptg logistics -- any questions or comments?
21:12:30 <mattoliver> cool, I'll go through it. And add stuff I can think of.
21:12:42 <timburke> 👍
21:13:10 <mattoliver> Do we want to book a "normal" time for a ops feedback?
21:13:27 <mattoliver> happy to do it in my timezone though (makes it much easier for me) ;)
21:13:55 <timburke> i don't know what "normal" means :P
21:14:11 <timburke> but yeah, an ops feedback session is probably a good idea
21:14:50 <mattoliver> a time that have more overlap with the attendees of PTG. Although it probably be just mostly us.
21:16:14 <timburke> ah, yeah -- looks like a lot of the rest of the ptg is in the 1300-1700 UTC slot
21:17:01 <timburke> i think i'll let mattoliver schedule that one then :-)
21:17:26 <mattoliver> lol, shouldn't have opened my big mouth :P kk :)
21:19:27 <timburke> all right -- i don't have much else to bring up
21:19:32 <timburke> #topic open discussion
21:19:41 <timburke> what else should we talk about this week?
21:21:48 <timburke> cschwede, i figured you'd have something, after making the effort to attend ;-)
21:21:58 <clarkb> oh I hav esomething
21:22:12 <clarkb> we're (opendev) looking to bump our default base job node to ubuntu jammy on the 25th
21:22:14 <cschwede> timburke: not really, i just wanted to ensure I get all the important PTG infos :)
21:22:29 <timburke> :-)
21:22:42 <clarkb> email has been sent about it, but I know ya'll bindep file doesn't work with jammy currently so wanted to call it out (I suspect that your jobs are probably fine since they probably specify a specific node type already)
21:22:57 <timburke> clarkb, oh! i bet that's part of the recent interest in https://review.opendev.org/c/openstack/swift/+/850947
21:23:01 <clarkb> timburke: I left a comment on the bindep file in your py310 change with a note about correcting that
21:23:13 <clarkb> ya that change
21:23:40 <mattoliver> oh good thing I moved the vagrant swift all in one environment over to jammy then :P
21:24:23 <timburke> thanks -- the bigger issue right now is the parent change -- our continued reliance on nosetests is definitely a problem now :-(
21:24:29 <clarkb> I have no idea if this will be the case for swift due to all the IO but in Zuul there is a distinct difference in test runtimes between 3.8 and 3.10 with 3.10 being noticeably quicker which is nice
21:25:29 <mattoliver> I've heard there is a performance boost in later py3's. nice
21:25:37 <timburke> i've noticed similar sorts of performance benefits when benchmarking some ring v2 work -- going py27 -> py37 -> py39 -> py310 kept making things better and better :-)
21:25:58 <mattoliver> down with nose, time to move everything to pytest.
21:26:14 <timburke> now if only i could get that first jump done in the clusters i run
21:28:37 <clarkb> re pytest one thing I've encouraged others to do is use ostestr for CI because it does parallelized testing without hacks (thought maybe pytest has made this better over time) and it is a standard test runner which means you can run pytest locally to get the more interactive tracebacks and code context output
21:28:59 <clarkb> but if you use pytest in CI you very quickly end up being pytest specific and running with standard runners is much more difficult
21:29:22 <mattoliver> great tip thanks clarkb
21:30:27 <clarkb> looks like your test jobs don't take a ton of time. But for a lot of projects not running in parallel would make them run for hours
21:32:57 <timburke> our tests (unfortunately) generally can't take advantage of parallelized tests -- unit *might* be able to (though i've got concerns about some of the more func-test-like tests), but func and probe are right out
21:35:41 <timburke> all right, i think i'll call it
21:35:54 <timburke> thank you all for coming, and thank you for working on swift!
21:36:01 <timburke> see you next week for the PTG!
21:36:05 <timburke> #endmeeting