21:00:25 #startmeeting swift 21:00:26 Meeting started Wed Feb 10 21:00:25 2016 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:29 The meeting name has been set to 'swift' 21:00:30 who's here for the swift meeting? 21:00:33 o/ 21:00:34 o/ 21:00:34 o/ 21:00:39 o/ 21:00:41 o/ 21:00:45 . 21:00:46 o/ 21:00:55 here 21:01:09 * onovy 21:01:23 o/ 21:01:43 o/ 21:01:45 o/ 21:01:46 o/ 21:01:51 o/ 21:01:54 hey 21:01:56 o/ 21:01:56 hi 21:02:14 welcome, everyone 21:02:19 clayg: ping 21:02:29 #link https://wiki.openstack.org/wiki/Meetings/Swift 21:02:32 agenda ^ 21:02:49 a few things to go over this week 21:03:04 a couple of general things first 21:03:09 #topic general things 21:03:22 summit talk voting is open. so do that 21:03:30 #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/ 21:03:55 also, there's been some questions about releases for swiftclient and swift-bench 21:04:17 I'll work on getting those done before the hackathon (within the next 2 weeks) 21:04:53 and lastly, I've finished my summary of responses to the "what's going on in swift" questions I asked a few weeks ago 21:05:23 I sent it out to a few people, and assuming nobody comes back real soon with a "this is totally terrible", I'll publish that for the world to see 21:05:39 hopefully later today or tomorrow 21:06:02 #topic hackathon 21:06:21 the hackathon is coming up! have you got your plane tickets and passport yet? 21:06:34 #link https://etherpad.openstack.org/p/swift-hackathon-feb-2016 21:06:58 there is an etherpad to collect ideas to talk about in bristol 21:07:13 thank you for adding stuff :-) 21:07:27 any questions about the hackathon? 21:07:54 ohai 21:08:43 gah I don't *want* to vote on summit topics - I did *every* session last time and it took ---- FOREVAR 21:09:08 the votes are advisory to the track chairs 21:09:24 lol - ORLY!? 21:09:30 so you can either say that it doesn't count or it's the way to make your voice heard. just depends on your perspective :-) 21:09:47 lol, and clayg if you don't do it, who will! 21:09:49 oh gosh i need to read the hackathon 21:10:17 clayg: I already volunteered you for a session… 21:10:25 heh 21:10:46 FWIW my only plan is to take the much needed time away from work for upstream focus to merge fast-POST (bonus points if I get to reconstructor or concurrent gets changes) 21:10:49 clayg: but only at the hackathon 21:11:43 sounds like a nice segue to talk about patches 21:11:55 #topic patches -- auditor bug 21:12:01 #link https://bugs.launchpad.net/swift/+bug/1183656 21:12:02 Launchpad bug 1183656 in OpenStack Object Storage (swift) "object auditors don't finish" [High,Confirmed] 21:12:19 what's going on here? 21:12:20 clayg: I better get concurrent gets going again then.. especially before my life turns up side down :) 21:13:04 onovy: I belive you were looking into this bug? 21:13:13 no? :) 21:13:18 joeljwright: wat? now I *really* better go read that eatherpad (thanks jrichli!) 21:13:30 onovy: honesty is the best policy - notmyname can take it 21:13:34 clayg :p 21:13:58 hmm..ok then 21:14:04 I thought it was either onovy or peterlisak 21:14:16 but it seems I misremembered 21:14:17 i think it's related to ionice 21:14:25 "related" :) 21:14:29 but the point still stands that it's a bug that needs to be squashed 21:14:47 ok, so that leaves us with... 21:15:01 who can volunteer to work on a patch for this bug this week? 21:15:14 cschwede: interested? 21:15:15 :-) 21:15:19 notmyname: wow you like went right out there for it - baller 21:15:30 notmyname: yup, just wanted to raise my hand 21:15:36 cschwede: awesome, thanks! 21:15:55 cschwede: !!!! how you been doing man! I think my schedule's been getting later - am I going to see you in bristol!? 21:16:44 clayg: :) of course, can’t wait to meeting all of you in Bristol! 21:16:54 yay 21:16:55 #topic patches -- in process functests with fast-POST 21:16:58 acoles: this is your topic 21:17:08 patch 274086 21:17:08 notmyname: https://review.openstack.org/#/c/274086/ - swift - Enable in-process func tests to optionally use fas... 21:17:23 we discussed this last week - still need another +2 on that ^^ 21:17:24 and patch 276823 21:17:24 notmyname: https://review.openstack.org/#/c/276823/ - openstack-infra/project-config - Add job gate-swift-tox-func-in-process-fast-post 21:17:34 annd here's the gate change ^^ 21:17:41 notmyname: thanks for feeding the links :) 21:18:01 I have been ultra-cautios with the gate change and made the tox-func-... job non-voting 21:18:02 I was going to look at the first one, sorry acoles. Conference had too many good talks.. will look at it today 21:18:08 mattoliverau: last week you said you'd look at it 21:18:10 mattoliverau: thanks man! 21:18:13 mattoliverau: ah. thanks :-) 21:18:48 #topic patches -- rbac 21:18:53 patch 202411 21:18:54 notmyname: https://review.openstack.org/#/c/202411/ - swift - Add functional test for access control (RBAC) with... 21:18:59 so nothing *should* fail but we'll let the gate runa few times then go back to voting, and imho we lose no coverage cos the regular func tests are still there 21:19:01 here's a quote from last week's meeting 21:19:04 "21:41:03 ok, so between torgomatic cschwede clayg and kota_, it *should* be either landed or have other patch sets by next week" 21:19:10 hrrmm.. patch 274086 has two reviewers - I can think of *one* soltuion 21:19:10 clayg: https://review.openstack.org/#/c/274086/ - swift - Enable in-process func tests to optionally use fas... 21:19:34 so torgomatic cschwede clayg kota_, what's the status of the rbac patch? doesn't look like any activity in gerrit since last week 21:19:59 welp, there's your status :| 21:20:16 well, maybe you've got something local :-) 21:20:18 * notmyname hopes 21:20:37 I can come shrug at your desk if it helps 21:20:38 sorry, I couldn't have a time to look at 21:21:04 will see 21:21:20 notmyname: i had a look, but unfortunately didn’t make much progress :/ the list of expected test result is quite long, doesn’t make it easier to read 21:21:35 notmyname: I'm *pretty* sure I have keystone working - but I honestly wasn't intending to look at the rbac tests again - I really am pretty sure if I do I'll want to push up another revision to address some of the stuff acoles already pointed out but couldn't bring himself to demand 21:21:45 cschwede: thanks 21:22:06 fwiw ho_away 's patch adds a load of time to a test run, BUT less time than patch 277465 removed 21:22:07 acoles: https://review.openstack.org/#/c/277465/ - swift - Speed up functional testing (MERGED) 21:22:19 yeah, we talked about that in tokyo. it's a complicated set of test conditions. IIRC clayg was suggesting spot-checking and pattern matching to review 21:22:34 acoles: two steps forward but only one step back sounds like progress! 21:22:42 progress! 21:22:57 cschwede: can I ping you about it at next weeks meeting? 21:23:07 (this rbac patch) 21:23:10 acoles: also I'm not sure how much I care about func test run time? It's been a long time since I was able to "wait" for a swift test run 21:23:20 i don’t feel comfortable about https://review.openstack.org/#/c/202411/20/test/functional/test_access_control.py - the list of expected returns 21:23:37 notmyname: sure, i’ll have another look at it. worst case is that i add only some comments 21:23:49 or that could be best case :-) 21:24:26 clayg: yeah, its beyond 'watch and wait' but not long enough to do much else useful 21:25:05 go grab a pint at the windchester and wait for the whole test suite to finish running 21:25:30 i might bother acoles about the patch then ;) 21:25:36 cschwede: wait which line? You just don't like the whole idea of a data driven test matrix - and would prefer explicit behavior based tests with names - or you're ok with exahaustive matrix testing but want the format somewhat different? 21:26:35 clayg: the last; data driven is fine, but the format in this patch feels not familar (yet) 21:27:31 we did discuss reformatting to something more readable, in Tokyo, IIRC 21:27:35 is ho_away here? 21:27:40 poor ho_away 21:27:48 yep 21:27:52 someone asserted that would be easy in emacs ;) 21:27:56 lol 21:27:59 yeah, using dictionaries so the fields are readable would be nice 21:28:14 I think maybe he's not clear on exactly what formatting would be most appreciated (I'm not even sure we *know* what format would be ideal) 21:28:29 he, true! 21:28:32 mattoliverau: acoles: +1 I think that was what folks said 21:29:00 clayg: yeah, exactly :-) 21:29:15 I'll bet ho_away would be interested in seeing your format bikeshed^W great ideas as a follow on ;-) 21:29:24 (was that too snarky?) 21:29:39 (it had a winky face. that makes it ok, right?) 21:30:00 notmyname: that is an EXCELLENT point 21:30:07 winky face makes everything ok 21:30:09 notmyname: winky face makes everything ok 21:30:15 mattoliverau: JINX! 21:30:25 so TBH I did not press ho_away too hard on the format because without other reviewers its maybe wasted effort, but it would be nice 21:30:28 * mattoliverau thinks damn, cause he can't talk 21:31:04 mattoliverau: you get so many cool points if you can continue the rest of the meeting by "mimeing" your input 21:31:39 I sympathize with what cschwede said. the format of the tests isn't familiar yet. not that it's inherently bad 21:31:45 #X$%^U it - let's merge it and file a bug to clean it up with an example of what we like? 21:32:03 tag it low-hanging-fruit for the faries 21:32:15 they LOVE that mechanical len/pep8/assertEqual crap anyway 21:32:16 clayg: yep, that was my idea as well, since there is already one +2 from acoles 21:32:29 cschwede: do eeeet! notmyname is right! 21:32:51 cschwede: well... think hard about what format might be better and open the bug too - then DOOOO EEEET 21:32:58 :-) 21:33:36 cool. there's a plan and expected resolution Real Soon Now 21:33:44 #topic patches -- pyeclib version migration 21:33:46 emacs will save us 21:33:54 acoles: thanks for adding this one 21:33:55 all: sorry & thanks for your help 21:34:08 ho_away: thanks for sticking with it for so long! 21:34:36 so the original pyeclib plan was this 21:35:04 update to 1.0.7 because of migration reasons (mostly with -infra reasons), then jump to 1.1.1 21:35:10 we did the first part 21:35:26 and now we're at 1.0.8 and there's an upstream 1.2.0 21:35:40 * onovy have simple question: if pyeclib is only for swift, what is reason for using older version than newest? 21:35:42 the final step in all of that was to then move the repos into the openstack namespace 21:36:26 onovy: IMO, we should go all the way (but the bump to 1.0.8 doesn't hurt anything) 21:36:50 yep. i don't have problem to package 1.2.0 in debian (already done it, not uploaded yet) 21:37:03 and it was simple, so others distro will not have any problems too 21:37:14 (imho) 21:37:15 onovy: i've been fighting liberasure packaging most of the day yesterday? 21:37:22 and I think I only got 1.1.0 21:37:25 onovy: ah! you're the one who did the bump to 1.0.8 :-) 21:37:30 notmyname: yes :) 21:37:45 oh that's liberasure tho - I don't know yet what pyeclib i'm going to package today 21:37:51 clayg: clayg liberasure 1.1.0 is newest 21:37:57 *phew* 21:38:04 clayg: you aren't packaging the latest from VCS? wow. 21:38:13 onovy: I thought zigo did all the debian openstack packaging - does he have HELP!? 21:38:19 ;-) <--- winky face makes it all ok 21:38:29 notmyname: no no i was - i think - onovy says i'm golden 21:38:32 clayg: yep, i'm doing swift packages 21:38:41 clayg: zigo isn't doing it anymore. right onovy? 21:38:43 da li ima neko ovdje iz Bosne za razgovor 21:38:53 bilo ko .neka se javi 21:38:54 ?? 21:38:58 ??? 21:39:06 notmyname: zigo is working on it too 21:39:33 adis: a ga la mo ne to vyra? 21:39:46 onovy: ah ok 21:40:04 notmyname: os packages are team maintained in debian 21:40:10 got it 21:40:12 adis: govoriti o openstack hitri ? 21:40:42 * notmyname feels like he has irc dysphasia 21:41:08 so let's continue the pyeclib upgrade with 1.2.0. sound reasonable to everyone? 21:41:08 notmyname: so... version "migration" - what was the question/notice exactly? 21:41:23 notmyname: it has a bigger number - why do we even need to discuss it ;) 21:41:30 yeah, that's exactly what I was about to ask 21:41:31 +1 for 1.2.0 version. don't see any cons here 21:41:45 lol 21:41:46 acoles: did you have something else specific on this? or just the "what's going on?" 21:42:32 and what about migration to os-infra? 21:43:01 onovy: I don't have anything there except "yup. that's the plan" 21:43:24 ok, let's do it 21:43:26 well mainly what's going on and when do we move up again? does 1.0.8 have everything required to use the liberasurecode-rs-vand? 21:43:38 "to" os-infra - or for the package/source/bitbucket 21:43:55 acoles: in my experience 1.0.8 was sufficient 21:43:55 clayg: in the openstack/* namespace (instead of bitbucket) 21:44:03 no I don't think 1.0.8 is sufficient 21:44:05 clayg: k. thanks 21:44:08 oh 21:44:12 it still has the liberasurecode bundling 21:44:24 that's why I think we need 1.2.0 (from what I see of the pyeclib changelong) 21:44:38 notmyname: it has what now? i think 1.0.8 requires liberasure-dev to install 21:44:50 what? rly? 21:44:56 exactly in debian pyeclib don't have liberasure bundling, becuase it can be disabled on "configure" 21:45:03 where is tsg he's the only one that knows how this works 21:45:25 so pyeclib package need liberasure package, it doesn't work without it 21:45:38 clayg: i know it too :) 21:45:42 onovy: the way that god intended packages to work 21:45:47 which is why the move to openstack/* is the goal. so not only tsg knows of it and can patch it :-) 21:45:58 pyeclib <1.2.0 have option "disable erasure bundling" 21:46:06 *liberasure bundling 21:46:19 1.2.0 don't have liberasure at all 21:46:23 ah ok. option to disable it. and 1.2.0 fully removes it 21:46:26 onovy: wtf is liberasure "bundling" why is that that i don't even? 21:46:27 onovy: thanks 21:46:47 clayg: it uses liberasure lib from pyeclib repo 21:47:07 clayg: that was what we didn't like about the earlier versions (we == anyone doing packaging). the pyeclib setup.py was downloading/installing the c lib 21:47:30 clayg: https://bitbucket.org/kmgreen2/pyeclib/src/b9140f9273655691812d8cc9c4e56da8a59ffd06/src/c?at=v1.1.1 21:47:33 notmyname: not anywhere anyone was packinging it wasn't - everyone worked around it 21:47:48 ok, i admit i am confused and stupid, but without liberasurecode how does liberasurecode-vs-rand work? or is the key word here "bundling"? what am i missing? 21:48:03 acoles: pyeclib have dependency 21:48:07 it needs liberasure 21:48:22 but older version had this version "distributed together" 21:48:27 *this deps 21:48:34 liberasurecode-rs-rand bundled in liberasurecode 21:49:00 kota_: liberasure-rs-rand is just one EC inside liberasurecode lib 21:49:01 http://d.not.mn/lca2016_ec_in_swift.pdf <-- 5th slide from the bottom ;-) 21:49:03 and it expected to be installed via os packaging 21:49:11 os packaging repo 21:49:12 oh, so what notmyname said "the pyeclib setup.py was downloading/installing the c lib" <- 1.2.0 stops doing this? 21:49:17 or by hand, in 1.2.0 21:49:19 acoles: yep 21:49:44 acoles: https://bitbucket.org/kmgreen2/pyeclib/src/19c99357839b0b95053632f303c1c4fab5408450/ChangeLog?fileviewer=file-view-default#ChangeLog-4 21:49:45 acoles: correct. and 1.0.7(?)->1.1.1 had an option to disable it 21:50:06 older pyeclib repo has tar ball in inside. 21:50:17 liberasurecode tar ball 21:50:24 yes, here: https://bitbucket.org/kmgreen2/pyeclib/src/b9140f9273655691812d8cc9c4e56da8a59ffd06/src/c/ 21:51:24 ok thanks everyone. so 1.0.8 brings us liberasurecode_rs_vand, 1.2.0 decouples the install 21:51:30 ya 21:51:40 this option: --install-liberasurecode=no 21:51:41 summary is pyeclib 1.2.0 is better than the earlier versions and that's what we should use in swift 21:51:49 notmyname: +1 :) 21:51:53 everyone agree? any more questions on that? 21:51:59 +1 21:52:03 onovy: where is that option? 21:52:08 so...why did we not jump to 1.2.0, why step to 1.0.8? 21:52:15 clayg: setup.py install --install-layout=deb --install-liberasurecode=no 21:52:27 WHAT? 21:52:27 +1 21:52:50 acoles: because i wanted to drop jerasure defaults 21:52:58 acoles: ah, because it was code that was written to solve a different problem. and code written to solv that other thing makes the project better. 21:52:59 acoles: a i done "smallest" step to achieve this 21:53:23 so, should i make review to bump to 1.2.0? or anyone else wants? 21:53:24 acoles: basically it comes down to the fact that onovy got the 1.0.8 change into global-requirements. 21:53:30 onovy: go for it 21:53:35 ok, i will do it 21:53:42 notmyname: ok, i get it :) 21:54:18 acoles: I've been trying to apply a "working code that is good enough but maybe not the perfect end solution is better than no code" :-) 21:54:19 #topic open discussion 21:54:29 heh, another merge master to feature/crypto on its way then :P 21:54:36 anything else to discuss in the meeting this week? 21:54:39 https://review.openstack.org/#/c/240036/ https://review.openstack.org/#/c/250022/ 21:54:44 acoles: that should be a regular thing anyway, right? 21:54:49 unit coverage boost ^^!! :) 21:54:55 moar tests! 21:55:15 waiting ~3 weeks, anyone? 21:55:18 * notmyname should make patchbot detect full gerrint urls too 21:55:26 notmyname: right 21:56:19 timburke: whats important to land in swiftclient before next release? 21:56:24 onovy: I'll add them to my list this week 21:56:26 patch 265417 is some nice cleanup on the retry-partial-downloads work 21:56:27 timburke: https://review.openstack.org/#/c/265417/ - python-swiftclient - _RetryBody doesn't need to take explicit etag/cont... 21:56:32 mattoliverau: thanks 21:56:36 timburke: joeljwright other than "everything" :) 21:56:41 along the same lines, patch 269252 21:56:41 timburke: https://review.openstack.org/#/c/269252/ - python-swiftclient - Check responses when retrying bodies 21:56:44 onovy: good to ping on those patches - you don't have to wait for a meeting 21:56:57 really want patch 252328 21:56:57 timburke: https://review.openstack.org/#/c/252328/ - python-swiftclient - Fix debug and info option parsing 21:57:09 ^^ oh yeah, must do that 21:57:15 I've been reading through the outstanding patches today 21:57:19 clayg: ok 21:57:20 patch 269359 is just stupid 21:57:20 timburke: https://review.openstack.org/#/c/269359/ - python-swiftclient - Display proper name when failing to create segment... 21:57:42 and can't forget acoles's patch 275719 21:57:43 timburke: https://review.openstack.org/#/c/275719/ - python-swiftclient - Support --os-identity-api-version option 21:57:53 timburke: so, "all of them"? ;-) 21:58:12 all low risk, but nothing critical 21:58:34 and for me this: patch 276280 is must have! :) 21:58:34 onovy: https://review.openstack.org/#/c/276280/ - swift - Script for checking sanity of manpages 21:58:34 timburke: agreed 21:58:45 the only other thing is solving the logging bug before another release 21:58:48 timburke: --debug position was annoying me again today, will try to review asap 21:58:50 or asap 21:58:51 ... 21:59:00 notmyname: hey, as long as i curate a little, you won't be *too* overwhelmed :-) 21:59:14 joeljwright: true, good point 21:59:28 I think I saw a candidate 21:59:36 for p in patches_by_author['timburke']: star(p) 21:59:43 but it's a little confusing as there are 2 bug reports that are very similar 21:59:59 we're out of time for this meeting slot 22:00:18 until next time… 22:00:18 thank you everyone for coming today. it's great to work with you on swift (and swiftclient!) 22:00:22 #endmeeting