15:00:39 <tbarron> #startmeeting manila 15:00:40 <openstack> Meeting started Thu Jan 24 15:00:39 2019 UTC and is due to finish in 60 minutes. The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:44 <openstack> The meeting name has been set to 'manila' 15:00:45 <vkmc> o/ 15:00:47 <tbarron> ping ganso 15:00:52 <tbarron> ping xyang 15:00:55 <tbarron> vkmc hi 15:01:01 <tbarron> ping gouthamr 15:01:04 <toabctl> o/ 15:01:05 <tbarron> ping jgrosso 15:01:09 <tbarron> hi toabctl 15:01:15 <jgrosso> hi tbarron 15:01:16 <tbarron> ping bswartz 15:01:21 <tbarron> ping erlon 15:01:27 <tbarron> pint tpsilva :) 15:01:32 <tbarron> ping amito 15:02:10 <tbarron> if anyone else wants to be added to the ping list you can do it yourself at https://wiki.openstack.org/w/index.php?title=Manila/Meetings&action=edit§ion=1 15:02:13 <tbarron> oe AK MW RO SO IR 15:02:23 <tbarron> :) 15:02:26 <tbarron> or ask me to do it 15:02:34 <xyang> hi 15:02:39 <tbarron> that was rot something on querty with caps :) 15:02:53 <tbarron> hi xyang 15:03:08 <ganso> hello 15:03:22 <tbarron> let's wait a couple more minutes 15:03:34 <gouthamr> o/ 15:03:39 <tbarron> hi gouthamr 15:04:01 <gouthamr> hi tbarron! 15:04:15 * tbarron wonders if bswartz is around 15:04:36 <tbarron> OK, we've got quorum, let's start. 15:04:41 <tbarron> hi everyone! 15:05:00 <tbarron> #topic agenda 15:05:06 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings 15:05:26 <tbarron> if you update it give me a nudge so i can refresh my browser 15:05:34 <tbarron> #topic announcements 15:05:44 <tbarron> I don't have any. Anyone else? 15:06:05 <tbarron> ok, hearing none ... 15:06:35 <tbarron> we've got a fair number of topics but let's try to move right along, i want to have time for the bugs topic 15:06:48 <tbarron> #topic scheduler speedup 15:07:11 <tbarron> #link https://review.openstack.org/#/c/619576/ 15:07:26 <tbarron> carthaca: you around? 15:07:31 <ganso> there is something wrong with the numbering on the agenda 15:07:58 <tbarron> ganso, yeah I see that now :) 15:08:20 <tbarron> We'll go top to bottom and I'll fix it after unless you want to do it now :) 15:08:24 <tbarron> feel free 15:09:10 <tbarron> So review 619576 has two plus 2s but it touches some important code so I haven't workflowed it yet 15:09:30 <tbarron> I plan to do that tomorrow if there aren't any downvotes 15:09:43 <ganso> tbarron: done 15:09:44 <tbarron> Please take a look if you care about the manila scheduler 15:09:50 <tbarron> ganso: ty 15:10:49 <tbarron> #topic AZ work 15:10:58 <gouthamr> ack, was looking if we can automate testing it somehow 15:11:09 <tbarron> There are three patches listed in the agenda 15:11:38 <tbarron> They are pretty significant -- exercise AZs in a way we haven't done before 15:11:58 <tbarron> We agreed in principle to the approach at spec time and I think it makes sense. 15:12:12 <tbarron> But expect that there may be some fallout. 15:12:23 <tbarron> Third party folks please look as well. 15:12:39 <tbarron> gouthamr: do you have something you want to share on these? 15:12:46 <gouthamr> ty tbarron 15:13:11 <gouthamr> yes, one more set of patches is due: Share type AZ support - i'm still working on the tests for these 15:13:38 <gouthamr> but the others listed: 15:13:38 <gouthamr> #LINK: https://review.openstack.org/#/c/629958/ 15:13:38 <gouthamr> #LINK: https://review.openstack.org/#/c/630886/ 15:13:38 <gouthamr> #LINK: https://review.openstack.org/#/c/630039/ 15:13:54 <gouthamr> are complete and needy for attention, thanks for teh reviews tbarron toabctl 15:13:58 <toabctl> only the last one is not merged yet 15:14:29 <toabctl> I already workflowed 629958 and 630886 and both are already merged. 15:14:34 <gouthamr> ooh, thanks! 15:14:52 <tbarron> i think we can merge them but want people to be aware of the changes in case there's any unanticipated fallout we need to repair 15:15:00 <gouthamr> ++ 15:15:05 <toabctl> yeah. sure. 15:15:08 <tbarron> it's hard to test all this fully I think 15:15:29 <tbarron> like what happens to netapp replication 15:15:32 <gouthamr> all third party CIs that use: ENABLED_BACKENDS should automatically have an AZ assigned to each of their enabled backends 15:15:34 <tbarron> etc 15:15:53 <tbarron> so heads up 15:16:14 <toabctl> and imo https://review.openstack.org/#/c/630039/ can be merged, too. just somebody needs to press the workflow button :) 15:16:14 <tbarron> It's good stuff, just have your eyes open. 15:16:26 <tbarron> toabctl: yup 15:16:42 <tbarron> OK, anything else on this topic? 15:16:53 <gouthamr> yes 15:17:07 <gouthamr> while we're here, please help by reviewing 15:17:10 <gouthamr> #LINK: https://review.openstack.org/#/q/topic:bp/export-locations-az+(status:open+OR+status:merged) 15:17:25 <gouthamr> :) 15:17:46 <gouthamr> that's trying to introduce new experimental APIs and clean up the export locations API a bit 15:17:47 <tbarron> gouthamr: plug .... 15:17:51 <gouthamr> :D 15:18:00 <tbarron> gouthamr: thanks for your work in this important area and toabctl thanks for your quality reviews. 15:18:15 <tbarron> #topic pylint 15:18:19 <tbarron> ganso you're up 15:18:41 <ganso> okay 15:18:42 <ganso> thanks 15:19:01 <ganso> so, I am not sure if everyone has noticed, but lately our pylint job has been broken 15:19:15 <ganso> here is one example: #LINK http://logs.openstack.org/58/629958/2/check/openstack-tox-pylint/d3056f6/job-output.txt.gz#_2019-01-23_19_20_57_403442 15:20:01 <ganso> hold on I am trying to get the gerrit link for the patch that broke it 15:20:34 <tbarron> So we used to run with a very old version of pylint but had a "ratchet" - the job only failed if there were *new* pylint warnings introduced by your patch 15:20:50 <ganso> there we go https://review.openstack.org/#/c/609791/ 15:20:52 <ganso> #LINK https://review.openstack.org/#/c/609791/ 15:20:54 <tbarron> we ported over changes from cinder to support newer pyling 15:20:57 <tbarron> pylint 15:21:20 <tbarron> and there's no longer a "ratchet" 15:21:40 <tbarron> the (nonvoting) job will say "FAIL" if you touched a file that has warnings 15:22:06 <tbarron> Talking to the cinder folks, the idea is to over time address the backlog of warnings. 15:22:10 <gouthamr> seesh: https://review.openstack.org/#/c/609791/1/tools/coding-checks.sh@7 15:22:29 <gouthamr> we can't run cinder's checks - they'll fail of course :P 15:22:34 <ganso> tbarron: there are multiple problems, 1) if fails to import some dependencies. tbarron fixed it this morning. #LINK https://review.openstack.org/632992 and 2) it will fail if you add code, complaining about the way we mock and assert code in unit tests 15:22:43 <tbarron> If you get "FAIL" look at the report and see if you can fix some of the issues or fix pylint if it's doing the wrong thing. 15:22:45 * gouthamr was kidding :P 15:23:10 <tbarron> gouthamr: yeah my patch changes that too :) 15:23:26 <gouthamr> ah: https://review.openstack.org/#/c/632992/1/tools/coding-checks.sh 15:23:43 <ganso> tbarron: so, I'll give one practical example and raise some questions 15:23:44 <tbarron> I noticed that cinder's .pylintrc and ours don't exactly match 15:23:57 <tbarron> we may be able to make some mods there to reduce noise 15:24:02 <tbarron> ganso: +1 15:24:34 <ganso> I am working on Manage/Unmanage of Share servers. And as I finished coding, along with unit tests, and everything is working, pylint is printing hundreds of warnings 15:24:56 <ganso> there is really nothing wrong with the code, because it is exactly as we used to do, the mocks and asserts 15:25:04 <ganso> but pylint doesn't like it that way 15:25:30 <ganso> our previous version of pylint didn't complain about mocks and asserts 15:25:55 <ganso> so, it would be good to get agreement here as to: 15:26:05 <tbarron> ganso: I'd like to filter those out, this issue seems to be https://github.com/PyCQA/pylint/issues/697 15:26:18 <gouthamr> ganso: installing test_requirements should have gotten rid of those specific errors? or do the errors not appear always? 15:26:40 <ganso> tbarron: yea that's the error 15:26:43 <tbarron> gouthamr: this is a different issue I think 15:27:05 <ganso> tbarron: so, looking at the git discussion 15:27:09 <ganso> tbarron: they don't plan on fixing it 15:27:14 <ganso> tbarron: so we would need to filter those out 15:27:33 <ganso> tbarron: although, filtering those, could potentially filter real problem 15:27:41 <ganso> tbarron: s/problem/problems 15:27:41 <tbarron> ganso: right, we'd need to post-process. Cause in general that kind of thing is worth catching. 15:28:00 <ganso> so what I would like to ask is how we would approach: 15:28:00 <tbarron> We'd need a smart filter that just exempts mock 15:28:21 <ganso> 1) would we keep pylint as a non-voting job, look at its warning and decide if it is relevant or not 15:28:33 <ganso> or 2) would we enforce that people submit code that does not generatet pylint warnings 15:28:49 <tbarron> well #1 for now I think 15:29:10 * ganso needs to increase the keyboard repeat interval 15:29:17 <tbarron> it's criteria for pass/fail isn't good enough yet 15:29:38 <tbarron> its 15:29:56 <tbarron> (possesive, not the contraction) 15:30:29 <ganso> #1 requires more work, if we intend to do it in the long term 15:30:37 <tbarron> ganso: I think we've raised awareness and maybe people will seize the day and make improvements as we go forwards. 15:30:48 <ganso> as we need to check the job result 15:30:53 <tbarron> #2 is great but it assumes we know how to achieve it. 15:31:03 <ganso> and validate if the code being proposed is good or not 15:31:53 <tbarron> ganso: if you know how to achieve #2 please propose a patch; otherwise we are stuck making incremental improvements and reminding people to look at the output and think about the results 15:31:59 <ganso> tbarron: we kinda do. Pylint is only checking the changes, so let's say, if we start coding it in a way that does not generate warnings as soon as Train cycle starts, we will not have problems 15:32:27 <tbarron> ganso: we'll still have warnings about asserts in mocks 15:32:29 <ganso> tbarron: at least on my changes, I can just mock it in a different way and the warnings go away 15:32:33 <tbarron> for one example 15:32:54 <ganso> tbarron: but I don't want to rewrite all my 1000 lines of unit tests before Stein's feature freeze 15:33:01 <tbarron> ganso: well I suspect there are things we don't know how to code around yet 15:33:04 <tbarron> ganso: agree 15:33:20 <ganso> tbarron: the main problem I see is: people will get confused because of those warnings 15:33:52 <tbarron> ganso if you change one line in Train it will report on the whole file 15:34:01 <ganso> tbarron: as I was when I saw then, and the thing it is complaining about is everywhere in the code, but I can't just code in a similar way to what's already there 15:34:09 <tbarron> so yes, there is danger of confusion but I don't see a fix yet 15:34:25 <ganso> tbarron: oh yea I forgot about that 15:34:50 <ganso> tbarron: if someone changes one line in test_manager, that person will never be able to get pylint job to pass haha 15:35:07 <tbarron> OK, unless there's a slam dunk solution now let's settle for raised awareness now. 15:35:09 <gouthamr> is it sane for us to revert the pylint change, and re-introduce it after fixing such issues? 15:35:34 <ganso> gouthamr: it will take us a very long time and a lot of effort to fix all those issues... 15:35:42 <gouthamr> once we revert, we can run it on the whole tree instead of one commit and catch these errors and fix them 15:35:56 <tbarron> gouthamr: who is "we" that is going to do the fix? 15:36:13 <tbarron> gouthamr: whoever that is can propose the revert and fix patches together 15:36:26 <tbarron> in the mean time we live with this imperfection 15:36:36 <ganso> tbarron: whoever that is will need to rewrite thousands of lines in test_manager :P 15:36:39 <gouthamr> ganso: yes, but what was once nearly okay is now failing 15:36:45 <tbarron> it's not the only imperfect thing in our world, nor IMO the most important 15:37:14 <tbarron> gouthamr: well IMO it's not a matter of RED or GREEN but of degreee 15:37:24 <ganso> we could revert the change and and stick to old pylint? 15:37:42 <gouthamr> ack, but i was under the impression we deleted a bunch of checks/ignores and this was incremental work 15:37:55 <tbarron> ok, you guys propose it and we'll see 15:37:59 <gouthamr> but OP is probably busy and didn't follow up on the patches 15:38:26 <tbarron> well he's busy in cinder, we *asked* him to bring the change over here 15:38:36 <tbarron> ok, moving on 15:38:46 <tbarron> #toppic gate issues 15:39:03 <ganso> *topic 15:39:15 <tbarron> #topic gate issues 15:39:18 <tbarron> ganso: ty 15:39:28 * gouthamr is guilty - thanks for raising awareness tbarron ganso 15:39:45 <tbarron> here's a fix for the failure to publish the service images when we change them 15:40:01 <tbarron> it also will bring capability to ssh w/o password 15:40:19 <tbarron> #link https://review.openstack.org/#/c/631846/ 15:40:30 <tbarron> please review 15:40:43 <tbarron> any questions on this one? 15:41:01 <tbarron> kk 15:41:06 <tbarron> #topic bugs 15:41:20 <jgrosso> Hi all 15:41:26 <gouthamr> o/ jgrosso 15:41:26 <tbarron> jgrosso has been working to systematize our bug backlog 15:41:31 <tbarron> and here he is! 15:41:36 <tbarron> to tell us about it. 15:42:05 <jgrosso> ok well let me start byt saying I spent a few days looking at the upstream bus 15:42:08 <jgrosso> bugs :) 15:42:23 <jgrosso> my goal is to make the bugs more visible and organize them in a way that makes it easier for the upstream manila community to process and fix bugs more efficiently. 15:42:57 <jgrosso> I have read bugs that need to be fixed because they were working on a master thesis :) , to high bugs that are not assigned 15:43:06 * ganso wants to catch a ride in the upstream bus 15:43:31 <jgrosso> so basically I think the upstream bus needs a driver :) 15:43:39 <jgrosso> I first kept the same triage pad the same https://etherpad.openstack.org/p/manila-bug-triage-pad 15:43:59 <jgrosso> for now and added high lights to show the existing bugs 15:44:24 <jgrosso> On a side note I was able to go through about 100 manila bugs and create a google sheet 15:44:56 <jgrosso> My question is do we have an order to how bugs are triaged, confirmed and assigned? 15:45:14 <jgrosso> I am seeing high bugs that are not assigned, some high status bug that were fix committed and not assigned 15:45:33 <tbarron> jgrosso: we lack systematic process :) 15:45:57 <tbarron> and welcome your approach 15:46:33 <jgrosso> I know OpenStack releases hang a long time in some cases, but I would like a plan a system for dealing with bugs so I need some input...I would also like some email so I can send a google doc sheet for people to look at 15:47:15 <tbarron> jgrosso: i can get you the emails of cores and active reviewers 15:47:24 <jgrosso> that would be great 15:47:40 <tbarron> jgrosso: but there's nothing secret so you can also share your sheet here and I can put it in the agenda 15:47:53 <jgrosso> sounds good 15:48:23 <jgrosso> so are there any defects from the triage pad that can be talkerd about I would like to understand why we have so many unassigned 15:48:38 <jgrosso> is it we just dont have the time to work on them? 15:48:40 <tbarron> jgrosso: there is no manager, there are no employees 15:48:50 <tbarron> bugs are "assigned" by people taking them 15:49:17 <tbarron> I think your presenting a fresh, systematic view will help a lot 15:49:48 <tbarron> but I should shut up 15:50:02 <jgrosso> ok so are there any bugs that need to be addressed in https://etherpad.openstack.org/p/manila-bug-triage-pad 15:50:11 <tbarron> ganso: xyang: toabctl: etc may have other or better answers to your questions 15:50:28 <jgrosso> no that is fine Tom like I said just learning the ropes 15:51:32 <gouthamr> tremendous work jgrosso! 15:51:51 <jgrosso> I think organizing this into an easier way to choose bugs may be a better solution, I think taking some of the bugs that have been sitting for years need to be archived some how 15:52:24 <tbarron> jgrosso: let's have a meeting to go over your sheet and do some clean up of stale bugs 15:52:24 <jgrosso> I think seeing 300 + bugs makes it hard to choose what bugs to work on. I want to keep going try to organize 15:52:30 <jgrosso> thanks Gouthamr 15:52:56 <tbarron> jgrosso: when you are ready I'll get you a list of emails for invitees :) 15:53:24 <jgrosso> tbarron: thanks that would be helpful 15:53:27 <gouthamr> we welcome new/sporadic contributions/fixes to these bugs, and when we pick up the bugs ourselves we tend to prioritize and fix stuff on a distributed manner - i've let stuff fall through the cracks over time as you'll notice :D 15:53:35 <gouthamr> tbarron: +1 15:53:50 * gouthamr uses wrong smiley 15:53:51 <jgrosso> :) 15:54:05 <tbarron> We'll close most of the bugs older than ocata with a note that if the issue is reproducible in supported releases please re-open. 15:54:07 <jgrosso> Oh yeah I also want to look at Storyboard :) 15:54:25 <tbarron> but we need to look and see if there are old serious issues that we know are still valid. 15:54:26 <jgrosso> I like that tbarron 15:54:36 <jgrosso> agreed 15:54:37 <tbarron> divide and conquer 15:54:45 <jgrosso> :) 15:55:04 <jgrosso> Thanks so much all 15:55:11 <tbarron> jgrosso: thank you! 15:55:20 <tbarron> #topic open discussion 15:55:30 <tbarron> anything else for today? 15:55:44 <toabctl> I wanted to ask what we want to do with the open reviews for the netapp driver 15:55:57 <toabctl> who is the maintainer for that driver? 15:56:05 <ganso> toabctl: I am 15:56:31 <toabctl> ganso, could you have a look at https://review.openstack.org/#/c/558465/ and https://review.openstack.org/#/c/619573/ then please? 15:56:54 <ganso> toabctl: I will as soon as I have some time 15:57:48 <toabctl> ok. theses are already month old and not to complicated. thanks! 15:57:59 <carthaca> ganso: thanks :) 15:58:29 <tbarron> carthaca: thanks for your work, you guys should get a discount from netapp :) 15:58:47 <gouthamr> #freeONTAP 15:58:55 <gouthamr> heh, #freeBeer 15:58:58 <toabctl> lol 15:59:32 <tbarron> Well let's end smiling today. 15:59:51 <tbarron> Thanks everyone! See you in #openstack-manila .... 15:59:55 <tbarron> #endmeeting