21:00:26 #startmeeting swift 21:00:27 Meeting started Wed Feb 13 21:00:26 2019 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:30 The meeting name has been set to 'swift' 21:00:32 who's here for the swift team meeting? 21:00:34 o/ 21:00:36 o/ 21:00:38 hi 21:00:41 o/ 21:00:46 o/ 21:00:51 o/ 21:00:57 o/ 21:01:07 lol 21:01:14 all right, let's get started 21:01:20 updates from last week... 21:01:33 losf branch has been created. I saw some patches proposed to it 21:02:09 nice 21:02:31 I've proposed stable backport changelog updates. I would have landed them, but timburke reminded me to reno-ify them. so I reproprosed with that today. assuming the gate is happy with it, i'll land them in a few hours and put in the tag requests 21:02:40 And the Go is baaaack. 21:02:44 lol 21:03:31 also, I want to collect all the backport changelog updates (from ever) and aggregate them and propose them to master. TBH I don't know yet what structure they'll take (eg at the top or inline), but it makes sense to me to have all the changelog updates on master 21:03:46 any other updates from last week? 21:04:01 timburke: you were just looking at some libec/pyeclib stuff 21:04:09 can you give an update? 21:05:00 yup... i was trying to do some weird things, installing libec just for my user instead of the whole system, so i proposed https://review.openstack.org/#/c/636501/ 21:05:01 patch 636501 - pyeclib - Try harder to find liberasurecode - 6 patch sets 21:05:18 which led me to realize that pyeclib gate was broken 21:05:36 but tdasilva already landed https://review.openstack.org/#/c/636668/ so we're good! 21:05:37 patch 636668 - pyeclib - Fix gate (MERGED) - 3 patch sets 21:06:07 yay! 21:06:18 wtg timburke & tdasilva - libec masters! 21:06:23 i was hoping that my LD_LIBRARY_PATH change would address https://bugs.launchpad.net/pyeclib/+bug/1780320 as a drive-by 21:06:24 Launchpad bug 1780320 in PyECLib "If find_library('erasurecode') in setup.py does not return a library version, try to append it " [Undecided,New] 21:07:18 but it didn't. so now i kinda want to bump up our minimum-supported libec to 1.4.0 (released back in ocata, i think?) and do https://review.openstack.org/#/c/636748/ 21:07:19 patch 636748 - pyeclib - Use liberasurecode_get_version() - 1 patch set 21:07:48 I think it's totally reasonable to bump the min version supported 21:08:09 anyone else have strong feelings on that? 21:08:12 it would mean you can't use xenial system packages for libec though 21:08:13 that means we throw the binary supports in xenial? 21:08:13 +1 and theres a bug we can use as a reason 21:09:07 timburke: yeah, that's an issue. why does it break? 21:09:12 * mattoliverau +1 was to raise the minimum. /me doesnt use ubuntu anymore :P 21:09:25 i think i might be able to make it work without it... the more i think about it, some combination of my patch and https://review.openstack.org/#/c/580754/ seems reasonable -- we don't have a libec2 yet, so... 21:09:26 patch 580754 - pyeclib - Adds support for systems that report library witho... - 1 patch set 21:09:38 notmyname: xenial ships 1.1.0 21:09:52 see https://packages.ubuntu.com/xenial/liberasurecode1 21:09:56 that's demonstrably terrible. 21:10:05 bionic's better: https://packages.ubuntu.com/bionic/liberasurecode1 21:10:16 maybe we should figure out how to get xenial to update to a newer version 21:10:18 * kota_ knows it's terrible tho 21:10:37 I sortof doubt the version of swift in xenial supports <1.3.1 21:10:54 well, hopefully if xenial uprevs their pyeclib they uprev their libec to a supported version 21:11:03 notmyname: almost certainly a good idea -- 1.3.1 would be the bare minimum of what they should even think about shipping 21:11:05 If you're going to tag 1.7, don't forget https://review.openstack.org/636556 21:11:06 patch 636556 - liberasurecode - Make our alt crc32 more portable - 1 patch set 21:11:14 and if you install the latest pyeclib on your xenial maybe you can figure out how to build a new enough libec 21:11:43 like ... use packages or don't 21:11:59 oh yeah that crc thing was a mess 21:12:01 is? 21:12:02 ok, so to sum up it sounds like we want to raise the supported version, but we should probably check with whoever maintains that ubuntu package to see how to get it updated too 21:12:18 oh yeah, and while we're talking libec, vr42 pushed up p 635603 p 635604 and p 635605 ! 21:12:19 https://review.openstack.org/#/c/635603/ - liberasurecode - fix: data access when having non-zero metadata size - 1 patch set 21:12:21 https://review.openstack.org/#/c/635604/ - liberasurecode - fix: proper support of more than 32 fragments - 1 patch set 21:12:22 https://review.openstack.org/#/c/635605/ - liberasurecode - feature: quadiron backend and tests - 1 patch set 21:12:51 nice 21:12:59 that's really good to hear 21:13:36 oh, that's new thing proposed at the last meeting 21:13:51 timburke: between you and me, let's work on getting libec/pyeclib patches updated on the priority reviews page 21:13:56 zaitcev: i'mmm....gonna have to think about that.... 21:14:45 sounds like there's a bit of work to do that is bigger than a short conversation here plus 30 minutes in gerrit 21:14:45 i really really wanna just cordon off that busted alt-crc and never have to think about it again 21:15:21 it was horribly broken and i worry that any attempt to make it not-horribly-broken is missing the point of why we kept it around 21:15:45 i'm not sure id' seen that phrase before... "cordon off" - sounds like quarantine or sequester... 21:16:14 No, you don't get it. On s390 it was NOT horribly broken. This patch DOES make it horribly broken, so that our tests pass. 21:16:15 yeah, maybe "quarantine" would be better. w/e 21:16:26 timburke: sound good to you? ie you and I track it on the wiki and that way we can track it a little better without it slipping through the cracks? 21:16:28 lol 21:17:52 anything else to bring up from anyone? any updates from last week or other stuff going on? 21:19:50 rledisez: kota_: anythign to bring up about losf? 21:20:28 I started work on losf feature branch, just pushed alex's github version. 21:20:30 notmyname: not from my side. alecuyer is off this week and i'll be off next week, so not a lot of movements these days 21:21:04 everyone, please remember to register for the PTG in denver asap 21:21:08 I did 21:21:10 but it seems like, we need to fix some tests and it's the thing alex worried about, that would be affected by design. 21:21:14 you should have an email with a discount code in it 21:21:16 BTW, can you guys review py3 stuff 21:21:26 There's like no time left 21:21:30 zaitcev: thanks for bringing that up 21:21:36 so that I should take a review on design docs too to fix up. 21:21:42 zaitcev: what is your timeframe. the only one I've heard is the openstack one of "end of T" 21:21:42 discount code? 21:22:03 https://review.openstack.org/570320 this is most annoying 21:22:04 patch 570320 - swift - py3: port the container sharder - 14 patch sets 21:22:20 oh yeah, i should register ptg, just got internal approval yesteday. 21:22:30 mattoliverau: were you going to look into that sharder py3 patch? 21:22:40 zaitcev: what do you mean "there's no time left"? 21:22:41 * mattoliverau still hasn't got a approval to go yet 21:22:45 It started like "oh, I'm just gonna fix up some sharder CLI real quick", and it turned out that container everything depends on this, and in addition it touches py2 21:22:46 notmyname: that was the plan 21:23:01 oh indeed, i have a discount 21:23:02 GTK 21:23:24 sorry I've been at sleep school with the baby (friday - Tuesday). I had my laptop but not really very productive (work wise). so now playing catch up 21:23:40 notmyname: we have 39% of tests passing right now and we've been on it since November if not earlier. Even if we ship in late April, there's NO WAY to get there in time. 21:23:44 babies are aawesome :P 21:24:56 November, December, January - that's 3 months. February, March, April - seriously we're underperforming. And don't forget that once unit tests are done, we have to do some kind of function and migration tests. 21:24:58 zaitcev: ok, but what's the april date? the only official date I've heard from anyone is "end of T" which will be towards the end of this calendar year 21:25:13 Oh 21:25:34 RH OSP 14 is based on Stein 21:25:42 I'm sure distros have some date in mind, but I just don't think it's ever been shared outside their respective companies 21:27:07 The Stein is the release that comes on top of RHEL 8 for us 21:28:03 ok 21:28:10 My problem is, RHEL 8 does not have py2 in the core, therefore other core products like OpenStack cannot depend on it (else they pull in the extra distro with py2). 21:28:31 RHEL 8 - best RHEL EVAR - IBMEL even 21:28:36 If we bump Swift out, whole OpenStack comes crashing down because our Heat-based director uses it :-) 21:28:54 lol 21:29:15 sounds like some explicit tracking of the py3 work would be warranted. I'll add that to priority reviews too. (but after I do, please update or clarify anything I miss or get wrong) 21:29:53 why is everything so hard... sigh 21:30:18 zaitcev: I think the work you've done for py3 in swift is both admirable and impressive 21:31:14 my gut reaction is one of frustration at distros in general though. everyone is wanting a thing, yet zaitcev is the *only* one who's been asked to work on it. but, you know, "open source" so I'm sure it will get done... 21:31:32 Cyril was helping, but he has work in Glance 21:31:43 Christian has gone manager 21:32:37 * clayg pours one out 21:32:52 yeah. I'm not blaming anyone or second-guessing work that's been done. just venting about it. 21:33:29 anyway, we'll keep working, as a team. we'll bug our respective managers to prioritize py3 work (that's the real issue, TBH). and it'll be done when it's done. hopefully sooner than later 21:33:31 zaitcev is great - I'm kinda almost a little bit sort of kinda starting to think maybe it would be less annoying if swift supported py3 21:33:56 clayg: whoa... hold on. such strong feelings there ;-) 21:34:36 buuut... we won't get anything done about it by complaining in here 21:34:50 anything else that someone would like to bring up here in this meeting? 21:34:53 how long after we support py3 can we drop py2 support? 21:34:58 like... immediately? 21:35:24 clayg: likely very very soon, seeing as the py community deadline is soon too 21:35:27 well, we aren't going to be able to drop py2 *before* we support py3, so... 21:35:27 as long as `swift-init restart` works right? 21:35:54 timburke: stick hasn't worked - so maybe the carrot? 21:36:21 idk, i just keep seeing bigger and bigger sticks :-/ 21:36:31 ROFL 21:36:44 * clayg hugs timburke 21:37:20 I think we've covered everything this week 21:37:29 thanks for coming, and thank you for your work on Swift 21:37:32 #endmeeting