21:01:13 #startmeeting swift 21:01:14 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:17 The meeting name has been set to 'swift' 21:01:21 who's here for the swift team meeting? 21:01:23 o/ 21:01:29 o/ 21:01:33 o/ 21:01:38 hello 21:02:04 welcome, everyone 21:02:13 hello 21:02:13 o/ 21:02:22 looks like we figured out the american time zone change 21:02:27 o/ 21:02:35 we've got a few things to go over this week... 21:02:36 #link https://wiki.openstack.org/wiki/Meetings/Swift 21:02:55 but I'm guessing we should be able to be done quickly :-) 21:02:59 o7 21:03:15 Hopefully 21:03:22 kota_: I saw that you got the gate jobs working on feature/losf. that's great! 21:03:28 are they all working? anything else to do? 21:03:33 yey 21:03:45 for the dsvm gate, it's done 21:04:12 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 I'll work the next thing in the rest of week and the next week 21:04:51 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 was it a zuul v3 change? maybe we haven't done a feature branch since then 21:05:10 ah, I can. 21:05:41 it seems like that happens since we migrated to zuul v3 from legacy jobs. 21:05:47 ah ok 21:05:54 interesting. and unfortunate 21:06:11 then, basically zuul v3 assumes the required project has same branch name to checkout the repo 21:06:26 that is why stable branch works as expected without change. 21:06:32 unfortunate in that it more strongly discourages using feature branches because it requires more boilerplate to set up 21:07:18 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 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 timburke: kota_: rledisez: does my fear of the testing gap make sense to you? 21:07:58 yup 21:08:33 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 notmyname: yes (i think i understood) 21:08:48 Do we need to raise a zuul bug or feature request? 21:09:04 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 it is an open infrastructure project, can we get it improved? 21:09:14 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 can always ask :) 21:09:35 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 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 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 timburke: I feel like that used to be what happened 21:10:43 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 mattoliverau: if you could ask the infra/zuul team about it, that would be helpful 21:11:31 is there notes on the problem, /me is suffering from lack of sleep (baby). But yeah I can chase it down 21:11:58 though re-reading these meeting notes after coffee would probably help :P 21:12:03 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 ahh cool 21:12:14 *zuul 21:12:31 mattoliverau: I asked about the issue to AJeager in infra channel so I'll point out the log for you too. 21:12:52 kota_: thanks :) 21:12:58 mattoliverau: patch is aslo at https://review.openstack.org/#/c/642645/ 21:12:59 patch 642645 - swift (feature/losf) - Enable swift-dsvm-functional tests at losf feature... (MERGED) - 11 patch sets 21:13:18 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 so, i created the bug report and answered to the one who raised the point 21:13:45 #link https://bugs.launchpad.net/swift/+bug/1817966 21:13:46 Launchpad bug 1817966 in OpenStack Object Storage (swift) "Encourage the use of static device names in fstab" [Undecided,New] 21:13:55 i'll try to propose a doc patch this week 21:14:25 rledisez: nice. thanks 21:14:29 nice 21:15:04 alexlecuyer: back to losf... I seem to remember soemthing about removing grpc? what's up with that? tell us more 21:15:25 So I had false hopes with the newer grpc versions, 21:15:39 it really wants to run a thread from its C core which does not work with eventlet 21:15:45 Hah! I studied grpc for nothing :-) 21:15:56 zaitcev, sorry ! :/ 21:16:11 alexlecuyer: the patch for Gorka doesn't help ? 21:16:22 alexlecuyer: sounds like the problem is eventlet, amiright? ;-) 21:16:42 tdasilva: not for our case directly, maybe we could try to adapt it but I still feel it would be brittle 21:17:07 notmyname: yes but I didn't feel I should bring up eventlet removal (from the object server) in that context 21:17:11 lol 21:17:14 happy to be told I am wrong, tho :) 21:17:14 alexlecuyer: so what's the next idea? 21:17:17 heh 21:17:20 notmyname: (I may be less than fully available just now, just ask timburke about py3, sorry) 21:17:30 zaitcev: ok, thanks 21:17:31 So I wrote a quick and dirty patch to replace grpc with http 21:17:32 notmyname: I tried to convince him to do it, but he's saying it a "too big requirement" for losf :) 21:17:34 keeping protobuf 21:17:51 rledisez: it's something we all want, but don't want to work on :-) 21:18:07 alexlecuyer: interesting. so protobuf-over-http? is that a thing? 21:18:13 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 well I just write serialized protobuf as the body 21:18:54 and the URL is the rpc call name 21:19:20 what verb to you use? (probably too close to bikeshedding for right now) 21:19:50 I did POST for everything (I always expect a reply, similar to grpc, even if an empty one) 21:20:01 ok 21:20:03 and I used HTTP code to emulate grpc error codes (FAILED_PRECONDITION, etc) 21:20:11 so the rest of the code need not change 21:20:27 is that functionality on losf yet? is it in prod at ovh yet? (I think you've got it backwards there ;-) 21:20:56 So, I posted a PR, I will put the link in a moment, so that kota could take a look 21:21:04 it passes functest, but it's quick and dirty) 21:21:11 It's not in prod at OVH, it needs work 21:21:26 is that what you're currently working on until it's better? 21:21:47 I should go to look as the next thing 21:21:56 I need to work on grpc replacemnt yes.(I have had to work on other things the past few days) 21:22:11 ok, thanks for the update :-) 21:22:14 and for now I think 'im happy with HTTP but, I can consider other options, if you have ideas 21:22:23 anything else to share on losf for this week's meeting? 21:22:29 not from me 21:22:32 kk 21:22:42 let's move to py3 21:22:46 that also has some good news this week 21:22:52 timburke: want to share? 21:23:19 i can get some replicated func tests to pass on py37! https://review.openstack.org/#/c/642520/ 21:23:20 patch 642520 - swift - Get functional/tests.py running under py3 - 6 patch sets 21:23:32 that's wonderful! 21:23:50 wow 21:24:05 awww yeah! you've even got a py3 ratchet in there 21:24:39 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 patch 640552 - swift - Stop monkey-patching mimetools - 5 patch sets 21:24:42 patch 642520 - swift - Get functional/tests.py running under py3 - 6 patch sets 21:25:17 that mimetools patch is already approved (thanks tdasilva, thanks zaitcev!) 21:25:26 just waiting on the gate 21:25:44 i'll try to keep https://wiki.openstack.org/wiki/Swift/PriorityReviews up-to-date with patches in progress 21:25:50 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 does it? i don't think it actually matter there much... *shrug* 21:26:39 next main things are https://review.openstack.org/#/c/638019/ so i can get EC func tests 21:26:39 patch 638019 - swift - Clean up how we walk through ranges in ECAppIter - 1 patch set 21:27:05 and figuring out how i want to get the func tests actually running in the gate 21:27:10 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 or was it http headers? or both? 21:28:57 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 that was in the py3-func-tests patch 21:29:25 right, that's the thing. it's all very exciting 21:29:36 i also got around to writing up https://bugs.python.org/issue36274 21:29:47 (http.client cannot send non-ASCII request lines) 21:30:26 and i'm working on putting up two PRs so CPython can decide which path they want to take on it 21:30:36 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 nice work timburke 21:30:49 lol 21:30:49 meanwhile, i'm probably gonna have swift_test_client patch out putrequest() 21:31:21 nothing like discovering bugs as old as notmyname's kids... 21:31:26 lol 21:31:52 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 a misbehaving kid who wont run on py3 :P 21:32:35 what a slacker! 21:32:43 lol 21:33:08 timburke: zaitcev: great work on py3 this week 21:33:18 anything else to report on that, or things to call out for help on? 21:33:36 this probably won't come as any great surprise, but what i need most is reviewer bandwidth 21:33:58 wait, who replaced timburke with zaitcev? 21:34:09 zaitcev has been saying that for a really long time 21:34:41 you know, that's a really good segue to the next topic, actually.... 21:34:48 the priority reviews page 21:34:51 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 #link https://wiki.openstack.org/wiki/Swift/PriorityReviews 21:35:12 timburke: is the py3 section up to date? 21:35:22 i think so? mostly. 21:35:25 great 21:35:48 so here's the thing abotu open reviews... we need to tag a swift release soon 21:36:12 based on the openstack release schedule, we need to tag a swift release the week of march 25 21:36:22 #link https://releases.openstack.org/stein/schedule.html 21:36:52 on that schedule, we're currently in R-4. the cycle release projects (nova) will do an RC next week 21:37:05 and the final tag is requires by the week of april 1 21:37:17 so close 21:37:20 yep 21:37:25 we can tag at any time 21:37:34 an april fools release :P 21:38:06 we ported to py3 :) 21:38:09 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 the release is the lie! :P 21:38:18 tdasilva, i was just thinking that :-) 21:38:19 lol 21:38:24 so I think we can tag at any time 21:38:47 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 if we wait until the last moment, then we're at risk of getting delayed by the gate 21:39:12 which is why I said "week of march 25" 21:39:33 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 patch 641855 - swift - Fix how we UTF-8-ify func tests - 1 patch set 21:39:35 sounds like a reasonable target date 21:39:46 I think I should work with timburke on getting the priority review page up to date for the next release 21:40:05 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 kota_: yeah, me too :-) 21:40:22 oh, said same thing with notmyname 21:40:40 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 notmyname, you've never had to worry about these sorts of things before ;-) 21:40:45 I know! 21:41:33 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 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 +100 21:41:57 mattoliverau, yep, just wed-sat 21:41:58 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 though at the same time, sad to see notmyname not PTLing 21:42:34 great! 21:42:48 just didn't want it to slip through the cracks :) 21:42:56 I'll be in denver sunday-saturday 21:43:13 * mattoliverau will be there from Friday - Saturday 21:43:16 I heard a rumor (nothing official) that the swift update may be on monday. if so, I'll do it 21:43:42 "everything's great. if it's not, go talk to timburke. updated done" 21:43:44 ;-) 21:43:51 :P 21:44:03 lol 21:44:19 ok, anything else to bring up in the meeting thins week? 21:44:28 any questions, concerns, or help-needed? 21:44:29 notmyname will be playing https://en.wikipedia.org/wiki/One_Last_Time_(Hamilton_song) on repeat while he makes his slides ;-) 21:45:22 rledisez: ok, the meeting wasn't as quite as short as I expected :-) 21:45:31 thanks everyone for coming this week 21:45:38 and thank you for your work on swift 21:45:41 #endmeeting