21:01:13 <notmyname> #startmeeting swift
21:01:14 <openstack> Meeting started Wed Mar 13 21:01:13 2019 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:17 <openstack> The meeting name has been set to 'swift'
21:01:21 <notmyname> who's here for the swift team meeting?
21:01:23 <timburke> o/
21:01:29 <kota_> o/
21:01:33 <alexlecuyer> o/
21:01:38 <tdasilva> hello
21:02:04 <notmyname> welcome, everyone
21:02:13 <m_kazuhiro> hello
21:02:13 <rledisez> o/
21:02:22 <notmyname> looks like we figured out the american time zone change
21:02:27 <mattoliverau> o/
21:02:35 <notmyname> we've got a few things to go over this week...
21:02:36 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:55 <notmyname> but I'm guessing we should be able to be done quickly :-)
21:02:59 <zaitcev> o7
21:03:15 <zaitcev> Hopefully
21:03:22 <notmyname> kota_: I saw that you got the gate jobs working on feature/losf. that's great!
21:03:28 <notmyname> are they all working? anything else to do?
21:03:33 <kota_> yey
21:03:45 <kota_> for the dsvm gate, it's done
21:04:12 <notmyname> kota_: rledisez: timburke: note especially that the changes to the zuul config that enabled the gate will need to be *excluded* from the final review branch and merge to master
21:04:16 <kota_> I'll work the next thing in the rest of week and the next week
21:04:51 <notmyname> the mechanics of that sortof make sense when I see the change, but I don't really understand why it didn't work (when it's worked for all the other feature branches we've done)
21:05:08 <notmyname> was it a zuul v3 change? maybe we haven't done a feature branch since then
21:05:10 <kota_> ah, I can.
21:05:41 <kota_> it seems like that happens since we migrated to zuul v3 from legacy jobs.
21:05:47 <notmyname> ah ok
21:05:54 <notmyname> interesting. and unfortunate
21:06:11 <kota_> then, basically zuul v3 assumes the required project has same branch name to checkout the repo
21:06:26 <kota_> that is why stable branch works as expected without change.
21:06:32 <notmyname> unfortunate in that it more strongly discourages using feature branches because it requires more boilerplate to set up
21:07:18 <notmyname> also, it means there's a problem when we pull it out of the eventual review branch. it means that while we're reviewing the final change, those tests won't be gating the patch. which is kinda the most important time to have them...
21:07:23 <kota_> absolutely other projects (devstack, keystone, etc) doesn't have feature/losf branch so that we should set to checkout from the master explicitly
21:07:45 <notmyname> timburke: kota_: rledisez: does my fear of the testing gap make sense to you?
21:07:58 <kota_> yup
21:08:33 <notmyname> ok, good. just want to make sure (1) I'm not crazy and (2) I'm not the only one thinking of it :-)
21:08:33 <rledisez> notmyname: yes (i think i understood)
21:08:48 <mattoliverau> Do we need to raise a zuul bug or feature request?
21:09:04 <timburke> yeah -- i'm thinking that we should probably keep the change on the review branch, but at the very end. merge everything else to the feature/review-losf branch, but never +A that last one. then merge to master
21:09:10 <mattoliverau> it is an open infrastructure project, can we get it improved?
21:09:14 <notmyname> mattoliverau: I'm not sure. it's a definite change from zuul v2, and in our use case it's a regression. but zuul team may not feel that way
21:09:32 <mattoliverau> can always ask :)
21:09:35 <kota_> it seems like sort of implied-branch might helps, https://zuul-ci.org/docs/zuul/user/config.html#attr-pragma.implied-branches but it was difficult to me to understand how it works.
21:09:53 <notmyname> timburke: yeah, something like that. kinda depends on what the zuul team says about it or what existing mechanisms exist that we don't know about yet
21:10:11 <timburke> i feel like there's certainly some room for improvement... like if a branch of the same name exists in the other repo, great! use that! but if not, fall back to master
21:10:29 <notmyname> timburke: I feel like that used to be what happened
21:10:43 <notmyname> it's not a looming problem--it's not like losf will be landing in the next few weeks--but good to start thinking about if there are changes we'll ask other people to land
21:11:03 <notmyname> mattoliverau: if you could ask the infra/zuul team about it, that would be helpful
21:11:31 <mattoliverau> is there notes on the problem, /me is suffering from lack of sleep (baby). But yeah I can chase it down
21:11:58 <mattoliverau> though re-reading these meeting notes after coffee would probably help :P
21:12:03 <notmyname> mattoliverau: nope. no notes. just what I gathered in my head from kota_'s patch (see the comments in swift's suul file)
21:12:13 <mattoliverau> ahh cool
21:12:14 <notmyname> *zuul
21:12:31 <kota_> mattoliverau: I asked about the issue to AJeager in infra channel so I'll point out the log for you too.
21:12:52 <mattoliverau> kota_: thanks :)
21:12:58 <kota_> mattoliverau: patch is aslo at https://review.openstack.org/#/c/642645/
21:12:59 <patchbot> patch 642645 - swift (feature/losf) - Enable swift-dsvm-functional tests at losf feature... (MERGED) - 11 patch sets
21:13:18 <notmyname> rledisez: looks like I had a question on the agenda about device names/labels/uuids in our docs. what was I supposed to ask you about it? :-)
21:13:42 <rledisez> so, i created the bug report and answered to the one who raised the point
21:13:45 <rledisez> #link https://bugs.launchpad.net/swift/+bug/1817966
21:13:46 <openstack> Launchpad bug 1817966 in OpenStack Object Storage (swift) "Encourage the use of static device names in fstab" [Undecided,New]
21:13:55 <rledisez> i'll try to propose a doc patch this week
21:14:25 <notmyname> rledisez: nice. thanks
21:14:29 <kota_> nice
21:15:04 <notmyname> alexlecuyer: back to losf... I seem to remember soemthing about removing grpc? what's up with that? tell us more
21:15:25 <alexlecuyer> So I had false hopes with the newer grpc versions,
21:15:39 <alexlecuyer> it really wants to run a thread from its C core which does not work with eventlet
21:15:45 <zaitcev> Hah! I studied grpc for nothing :-)
21:15:56 <alexlecuyer> zaitcev, sorry ! :/
21:16:11 <tdasilva> alexlecuyer: the patch for Gorka doesn't help ?
21:16:22 <notmyname> alexlecuyer: sounds like the problem is eventlet, amiright? ;-)
21:16:42 <alexlecuyer> tdasilva: not for our case directly, maybe we could try to adapt it but I still feel it would be brittle
21:17:07 <alexlecuyer> notmyname: yes but I didn't feel I should bring up eventlet removal (from the object server) in that context
21:17:11 <notmyname> lol
21:17:14 <alexlecuyer> happy to be told I am wrong, tho :)
21:17:14 <notmyname> alexlecuyer: so what's the next idea?
21:17:17 <tdasilva> heh
21:17:20 <zaitcev> notmyname: (I may be less than fully available just now, just ask timburke about py3, sorry)
21:17:30 <notmyname> zaitcev: ok, thanks
21:17:31 <alexlecuyer> So I wrote a quick and dirty patch to replace grpc with http
21:17:32 <rledisez> notmyname: I tried to convince him to do it, but he's saying it a "too big requirement" for losf :)
21:17:34 <alexlecuyer> keeping protobuf
21:17:51 <notmyname> rledisez: it's something we all want, but don't want to work on :-)
21:18:07 <notmyname> alexlecuyer: interesting. so protobuf-over-http? is that a thing?
21:18:13 <alexlecuyer> and it works well enough that I'm quite confident it would work. the latency is worse, but I think we don't care (the actual RPC calls still take time, so)
21:18:27 <alexlecuyer> well I just write serialized protobuf as the body
21:18:54 <alexlecuyer> and the URL is the rpc call name
21:19:20 <notmyname> what verb to you use? (probably too close to bikeshedding for right now)
21:19:50 <alexlecuyer> I did POST for everything (I always expect a reply, similar to grpc, even if an empty one)
21:20:01 <notmyname> ok
21:20:03 <alexlecuyer> and I used HTTP code to emulate grpc error codes (FAILED_PRECONDITION, etc)
21:20:11 <alexlecuyer> so the rest of the code need not change
21:20:27 <notmyname> is that functionality on losf yet? is it in prod at ovh yet? (I think you've got it backwards there ;-)
21:20:56 <alexlecuyer> So, I posted a PR, I will put the link in a moment, so that kota could take a look
21:21:04 <alexlecuyer> it passes functest, but it's quick and dirty)
21:21:11 <alexlecuyer> It's not in prod at OVH, it needs work
21:21:26 <notmyname> is that what you're currently working on until it's better?
21:21:47 <kota_> I should go to look as the next thing
21:21:56 <alexlecuyer> I need to work on grpc replacemnt yes.(I have had to work on other things the past few days)
21:22:11 <notmyname> ok, thanks for the update :-)
21:22:14 <alexlecuyer> and for now I think 'im happy with HTTP but, I can consider other options, if you have ideas
21:22:23 <notmyname> anything else to share on losf for this week's meeting?
21:22:29 <alexlecuyer> not from me
21:22:32 <notmyname> kk
21:22:42 <notmyname> let's move to py3
21:22:46 <notmyname> that also has some good news this week
21:22:52 <notmyname> timburke: want to share?
21:23:19 <timburke> i can get some replicated func tests to pass on py37! https://review.openstack.org/#/c/642520/
21:23:20 <patchbot> patch 642520 - swift - Get functional/tests.py running under py3 - 6 patch sets
21:23:32 <notmyname> that's wonderful!
21:23:50 <kota_> wow
21:24:05 <notmyname> awww yeah! you've even got a py3 ratchet in there
21:24:39 <timburke> it needed us to stop monkeypatching mimetools (see https://review.openstack.org/#/c/640552/) and it has its own crazy stuff going on in https://review.openstack.org/#/c/642520/6/swift/common/wsgi.py but... hey! py3 func tests!
21:24:40 <patchbot> patch 640552 - swift - Stop monkey-patching mimetools - 5 patch sets
21:24:42 <patchbot> patch 642520 - swift - Get functional/tests.py running under py3 - 6 patch sets
21:25:17 <timburke> that mimetools patch is already approved (thanks tdasilva, thanks zaitcev!)
21:25:26 <timburke> just waiting on the gate
21:25:44 <timburke> i'll try to keep https://wiki.openstack.org/wiki/Swift/PriorityReviews up-to-date with patches in progress
21:25:50 <notmyname> the monkeypatching-ectomy (appologies for anyone who's a non-native english speaker for that) is nice because it also introduces the mechanism for fixing historic metadata stored in clusters. it gives a migration path!
21:26:33 <timburke> does it? i don't think it actually matter there much... *shrug*
21:26:39 <timburke> next main things are https://review.openstack.org/#/c/638019/ so i can get EC func tests
21:26:39 <patchbot> patch 638019 - swift - Clean up how we walk through ranges in ECAppIter - 1 patch set
21:27:05 <timburke> and figuring out how i want to get the func tests actually running in the gate
21:27:10 <notmyname> timburke: I thought it did becuase you use the same protocol class to read older metadata without needing to patch stdlib (and/or wait for py38)
21:27:49 <notmyname> or was it http headers? or both?
21:28:57 <timburke> so the wsgi parse_request() change makes it so we don't have to wait on https://github.com/python/cpython/pull/7932, which is very much a good thing
21:29:10 <timburke> that was in the py3-func-tests patch
21:29:25 <notmyname> right, that's the thing. it's all very exciting
21:29:36 <timburke> i also got around to writing up https://bugs.python.org/issue36274
21:29:47 <timburke> (http.client cannot send non-ASCII request lines)
21:30:26 <timburke> and i'm working on putting up two PRs so CPython can decide which path they want to take on it
21:30:36 <notmyname> I love the implication here. "Why hasn't swift completely ported to py3 yet?!?!" and tim is like, "well, I've been filing bugs in cpython and waiting for them to land my patches" ;-)
21:30:47 <mattoliverau> nice work timburke
21:30:49 <mattoliverau> lol
21:30:49 <timburke> meanwhile, i'm probably gonna have swift_test_client patch out putrequest()
21:31:21 <timburke> nothing like discovering bugs as old as notmyname's kids...
21:31:26 <notmyname> lol
21:31:52 <notmyname> I have 3. one's 11, and two that are 9. we're in a meeting about one of those younger kids right now
21:32:27 <mattoliverau> a misbehaving kid who wont run on py3 :P
21:32:35 <notmyname> what a slacker!
21:32:43 <kota_> lol
21:33:08 <notmyname> timburke: zaitcev: great work on py3 this week
21:33:18 <notmyname> anything else to report on that, or things to call out for help on?
21:33:36 <timburke> this probably won't come as any great surprise, but what i need most is reviewer bandwidth
21:33:58 <notmyname> wait, who replaced timburke with zaitcev?
21:34:09 <notmyname> zaitcev has been saying that for a really long time
21:34:41 <notmyname> you know, that's a really good segue to the next topic, actually....
21:34:48 <notmyname> the priority reviews page
21:34:51 <timburke> if you can, look at the patches. if there's something that seems weird, ask about it. make me explain what's going on in my head, so i'm not the only one with a model of how to do this polyglot thing
21:34:52 * mattoliverau will try and spend more time with py3 reviews.
21:34:54 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:35:12 <notmyname> timburke: is the py3 section up to date?
21:35:22 <timburke> i think so? mostly.
21:35:25 <notmyname> great
21:35:48 <notmyname> so here's the thing abotu open reviews... we need to tag a swift release soon
21:36:12 <notmyname> based on the openstack release schedule, we need to tag a swift release the week of march 25
21:36:22 <notmyname> #link https://releases.openstack.org/stein/schedule.html
21:36:52 <notmyname> on that schedule, we're currently in R-4. the cycle release projects (nova) will do an RC next week
21:37:05 <notmyname> and the final tag is requires by the week of april 1
21:37:17 <kota_> so close
21:37:20 <notmyname> yep
21:37:25 <notmyname> we can tag at any time
21:37:34 <mattoliverau> an april fools release :P
21:38:06 <tdasilva> we ported to py3 :)
21:38:09 <notmyname> I do not know of any major outstanding patches or issues. that is, I don't think we're waiting on some patch to land that would otherwise block a release
21:38:11 <kota_> the release is the lie! :P
21:38:18 <timburke> tdasilva, i was just thinking that :-)
21:38:19 <tdasilva> lol
21:38:24 <notmyname> so I think we can tag at any time
21:38:47 <notmyname> if we do it right now (wont' happen), that may be ok, but there may be a few things otherwise that would be nice to land
21:39:02 <notmyname> if we wait until the last moment, then we're at risk of getting delayed by the gate
21:39:12 <notmyname> which is why I said "week of march 25"
21:39:33 <timburke> not really a release blocker, but landing https://review.openstack.org/#/c/641855/ would make me feel *much* better about our unicode support
21:39:34 <patchbot> patch 641855 - swift - Fix how we UTF-8-ify func tests - 1 patch set
21:39:35 <mattoliverau> sounds like a reasonable target date
21:39:46 <notmyname> I think I should work with timburke on getting the priority review page up to date for the next release
21:40:05 <notmyname> because timburke is the new ptl, starting whenever new ptls start. april? now? IDK
21:40:06 * kota_ is wondering if it's the last work for notmyname as the PTL? when timburke will start to cheer the meeting?
21:40:14 <notmyname> kota_: yeah, me too :-)
21:40:22 <kota_> oh, said same thing with notmyname
21:40:40 <notmyname> I'm trying to get him to do all the things, starting yesterday, but I don't think he's on the hook to do it until after the release :-)
21:40:40 <timburke> notmyname, you've never had to worry about these sorts of things before ;-)
21:40:45 <notmyname> I know!
21:41:33 <notmyname> speaking of which, I'd like to say, on the record here in the meeting, that timburke will do a great job as PTL for swift and I'm very happy he's volunteered to take the role
21:41:37 <mattoliverau> timburke: are you still only coming to the PTG part of the summit? do we need to think about the project update?
21:41:45 <mattoliverau> +100
21:41:57 <timburke> mattoliverau, yep, just wed-sat
21:41:58 <notmyname> mattoliverau: depending on when the update is scheduled, either he or I will do it. if timburke can't, then I'll do it
21:42:00 <mattoliverau> though at the same time, sad to see notmyname not PTLing
21:42:34 <mattoliverau> great!
21:42:48 <mattoliverau> just didn't want it to slip through the cracks :)
21:42:56 <notmyname> I'll be in denver sunday-saturday
21:43:13 * mattoliverau will be there from Friday - Saturday
21:43:16 <notmyname> I heard a rumor (nothing official) that the swift update may be on monday. if so, I'll do it
21:43:42 <notmyname> "everything's great. if it's not, go talk to timburke. updated done"
21:43:44 <notmyname> ;-)
21:43:51 <mattoliverau> :P
21:44:03 <kota_> lol
21:44:19 <notmyname> ok, anything else to bring up in the meeting thins week?
21:44:28 <notmyname> any questions, concerns, or help-needed?
21:44:29 <timburke> notmyname will be playing https://en.wikipedia.org/wiki/One_Last_Time_(Hamilton_song) on repeat while he makes his slides ;-)
21:45:22 <notmyname> rledisez: ok, the meeting wasn't as quite as short as I expected :-)
21:45:31 <notmyname> thanks everyone for coming this week
21:45:38 <notmyname> and thank you for your work on swift
21:45:41 <notmyname> #endmeeting