21:00:08 <timburke> #startmeeting swift
21:00:08 <opendevmeet> Meeting started Wed Dec  1 21:00:08 2021 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:08 <opendevmeet> The meeting name has been set to 'swift'
21:00:15 <timburke> who's here for the swift meeting?
21:00:21 <zaitcev> o/
21:00:59 <kota> o/
21:01:41 <acoles> o/
21:01:44 <timburke> i know mattoliver is unavailable right now, but clayg and acoles may still be around
21:01:49 <timburke> first up, a couple discussions i saw on the ML that i thought were worth pointing out
21:01:56 <timburke> #topic release cadence
21:02:04 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025684.html
21:02:10 <clayg> 👋
21:02:52 <timburke> i don't think this will really impact us much, but thought it was worth highlighting that the larger openstack community seems interested in adjusting to a longer release cycle
21:03:42 <timburke> we'll continue to release as often as we figure is necessary, though i might need to remember to actually take advantage of that "with intermediary" more often ;-)
21:04:00 <timburke> #topic minimum python version
21:04:05 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025988.html
21:05:02 <timburke> for the yoga cycle, openstack as a whole is committed to testing under py38 and py39
21:05:05 <timburke> #link https://governance.openstack.org/tc/reference/runtimes/yoga.html
21:06:17 <clayg> RC cadence was interesting; I hadn’t seen that.
21:07:07 <timburke> people are understandably skittish of trying to support untested pythoin versions -- i wouldn't be surprised if there were constructions in py38 that would SyntaxError on py36. so they're debating about proposing python_requires='>=3.8' all over the place
21:07:51 <timburke> it doesn't immediately impact us -- i figure as long as we're supporting py27, keeping support for py36 seems trivial
21:08:25 <timburke> but it got me wonder: can we finally commit to dropping py27 support in some forseeable time frame?
21:09:18 <timburke> this might largely be a question for acoles, clayg, and i -- i *think* we're the main stragglers that haven't made the jump yet
21:09:51 <timburke> (though it'd probably be worth checking in with someone at OVH to see how they're doing)
21:11:31 <timburke> more directly: is anyone actively *opposed* to dropping py27 support following the yoga release (~end of March)?
21:11:54 <clayg> timburke: you know me - as soon as we're off py27 I don't care how fast we drop it - I think we could even make the case that it should be dropped in spite of us (and we may not even find that to agreeable if it becomes too difficult to support py27 on zuul/openstack)
21:12:31 <clayg> timburke: that might be a reasonable timeline to put down as the plan of record; but if we agree here we could ask the same question on the ML
21:14:31 <timburke> yes -- i'll definitely do so. send out something like "we're finally getting off py2, yoga will be the last to support it, and backports to yoga may become difficult -- is there anyone who actively still *wants* py2? speak now or forever hold your peace"
21:15:12 <acoles> +1
21:15:30 <timburke> so -- assuming we drop py2 -- what *should* our minimum supported python be at that point?
21:16:09 <kota> it sounds reasonable, i think my older costumers is still running on py2 but they won't to bump Swift version as well as python version...
21:16:11 <zaitcev> I'm okay with anything. I'll have to find issues when I backport to py36, but I can live with it.
21:16:19 <kota> s/is/are/
21:16:36 <kota> so i can recommend to use py3 definately
21:17:05 <zaitcev> If we drop py2, we can finally merge Romain's parting gift, the elimination of queues.
21:17:29 <timburke> oh yeah -- i'd forgotten that only had trouble on py2...
21:19:17 <timburke> fwiw, py36 eol is scheduled for around the end of the year -- but i know redhat will continue to service it for a while after
21:20:03 <zaitcev> For many years.
21:20:40 <timburke> zaitcev, fwiw i'm not opposed to keeping py36 testing -- might be the sort of thing where we drop py2 first, then see how much we're actually itching to use the newest features
21:21:00 <zaitcev> timburke: Sounds good to me.
21:21:47 <timburke> all right, i'll plan on sending out a message to the ML about finally dropping py2 support then
21:22:02 <timburke> #topic ptg action items
21:22:23 <timburke> it's been a bit since we last checked in -- let's see how we're doing on these ;-)
21:23:35 <timburke> i never did give feedback on the interop change :-(
21:23:41 <zaitcev> What's "(timburke) abandon old patches"
21:23:48 <timburke> though now it's abandoned, so... *shrug*
21:24:26 <timburke> zaitcev, i haven't done much with it recently, but earlier i'd abandoned all the outstanding hummingbird and losf patches, for example
21:24:36 <zaitcev> I see, thanks.
21:25:04 <zaitcev> Ethercalc throws 503
21:26:31 <timburke> wowza -- we've still got a patch open from 2013... https://review.opendev.org/q/p:openstack/swift+is:open,500
21:27:36 <timburke> zaitcev, i noticed that, too -- unfortunate that mattoliver isn't around to update us on that
21:28:01 <timburke> but i did at least make some progress on dropping logging translations!
21:28:34 <timburke> acoles, ever get a chance to think more about the dark data watcher? https://review.opendev.org/c/openstack/swift/+/787656
21:29:00 <acoles> :( to my shame no. I mean, I have thought but not acted.
21:29:34 <acoles> it is on my radar though. apologies zaitcev , we've had a busy time internally recently
21:29:39 <timburke> no worries -- we've had some other fires to deal with :-)
21:29:54 <zaitcev> well I worry... a little bit... :-)
21:30:24 <timburke> all right -- there's been *some* progress on these, and we'll continue to try to do better ;-)
21:31:02 <timburke> next up, i noticed a few items that have mostyly already been resolved, but seem worth calling out
21:31:18 <timburke> #topic reconstructor not cleaning up handoffs
21:32:07 <timburke> we saw an issue in our big cluster recently when we were doing a (relatively small) expansion
21:32:49 <timburke> even though we were running with handoffs_only, a bunch of handoff partitions wouldn't get cleaned up even after several reconstructor cycles
21:33:50 <timburke> the crux seemed to be that we weren't cleaning up non-durable data properly, even though we *did* revert it -- which should be addressed by https://review.opendev.org/c/openstack/swift/+/818558
21:34:23 <acoles> my bad, we fixed it once then broke it so now we fixed it again
21:34:50 <timburke> i think i may want to backport it to xena...
21:35:09 <acoles> yes
21:36:07 <timburke> having the partition hang around led to us noticing another bug: .meta files weren't getting cleaned up as part of a revert
21:36:29 <timburke> which should be fixed by https://review.opendev.org/c/openstack/swift/+/818544
21:36:50 <timburke> (i'm less certain that one needs to be backported)
21:38:32 <acoles> I think we concluded that in the absence of the lingering non-durable, the meta files would be cleaned up eventually. The patch just does it 'deliberately and properly'.
21:38:52 <timburke> but one thing *that* investigation led to was the discovery that a lone .meta doesn't get reflected in hashes.pkl and no attempt is made to send that bit of information to peers (at least, for ec policies)
21:39:16 <timburke> i'm not sure whether that ought to be considered a bug or not, but it seemed like something worth calling out
21:40:26 <timburke> acoles, yeah -- i think i'm leaning toward *not* backporting the second one
21:40:36 <acoles> +1
21:40:59 <timburke> fwiw, we just upgraded production with those patches today, and our handoff counts are looking *way* better :-)
21:41:19 <timburke> #topic arm jobs now voting
21:42:02 <timburke> acoles fixed something that had been bugging me for a bit -- when the arm jobs would fail, zuul would still send a comment saying the build succeeded
21:42:39 <acoles> ...and worse...I had been believing zuul! :)
21:43:23 <timburke> trouble was that i'd marked them non-voting in the definition, because i was worried that it'd make zuul vote -1 when they failed. but the pipeline wasn't set up to leave +1/-1, so my concern was unwarranted
21:43:44 <timburke> #topic tempurl signature logging
21:43:52 <acoles> to be fair, clarkb shared the wisdom and I merely pressed keys
21:44:04 <timburke> :-)
21:44:06 <timburke> #link https://bugs.launchpad.net/swift/+bug/1685798
21:44:14 <timburke> #link https://review.opendev.org/c/openstack/swift/+/817476
21:44:42 <timburke> has anyone had a chance to review this?
21:45:53 <timburke> i'm not seeing much activity since the patch was proposed ~3 weeks ago, just want to make sure it doesn't fall off our radars
21:47:05 <zaitcev> I'm looking.
21:47:57 <timburke> i'll try to do another pass on it this week, maybe experiment with moving the redaction into proxy-logging (which already does something similar with auth tokens)
21:48:17 <acoles> timburke: where did your thinking end up re moving the fix to the proxy-logging?
21:48:22 <zaitcev> env.setdefault('obsucre_map', {}) -- mattoliver: I do think the tests would catch this :-)
21:49:02 <timburke> acoles, mainly that i wanted to try it out and see how it looked before committing to it ;-)
21:49:15 <acoles> kk
21:49:23 <timburke> we'll check in on it again next week
21:49:45 <timburke> #topic small tasks suitable for a term project
21:50:10 <acoles> zaitcev: lol. "obsucre" may be some kind of hidden sugar?! (a terrible play on my school boy french)
21:50:31 <timburke> zaitcev, i think this was your topic?
21:51:01 <acoles> zaitcev: we do have https://bugs.launchpad.net/swift/+bugs?field.tag=low-hanging-fruit
21:51:21 <zaitcev> They are dsariel's students. I forgot to ask what year or level they are at.
21:52:17 <zaitcev> acoles: thanks, I'll pass that along and then we'll review the list.
21:53:21 <acoles> be sure to alert us if/when a student joins the community so we can do our best to help
21:53:35 <timburke> i think my main question is: what do we expect the student to want to get out of it? just looking to work on their python? an opportunity to interact with an open source community? a chance to think hard about distributed systems? there's probably a bit of a spectrum
21:54:02 <timburke> and different tasks would suit different goals
21:54:27 <zaitcev> Thinking hard may be a little early. Or, rather, it's never too early, but we cannot expect anything to come out.
21:54:42 <zaitcev> So, the first two.
21:54:56 <timburke> 👍
21:55:55 <zaitcev> Allright, this is good enough for now. I was hoping if you had a pet project or fix, but the list is good.
21:56:01 <timburke> those low-hanging-fruit bugs seem like good choices, then. i'll try to write up a few more of them if i think of anything new
21:56:39 <timburke> all right -- we're pretty close to time. i'll save the other topics for next week
21:56:43 <timburke> #topic open discussion
21:57:04 <timburke> it's been a long time since our last meeting -- is there anything else we should bring up before the end?
22:01:05 <timburke> all right then. thank you all for coming, and thank you for working on swift!
22:01:09 <timburke> #endmeeting