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&section=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