15:01:21 <tbarron> #startmeeting manila
15:01:22 <openstack> Meeting started Thu Oct  4 15:01:21 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <openstack> The meeting name has been set to 'manila'
15:01:28 <bswartz> .o/
15:01:36 <ganso> hello
15:01:37 <gouthamr> o/
15:01:52 * gouthamr comes in with trout shield
15:02:21 <dustins> \o
15:02:36 <tbarron> ping xyang erlon
15:02:43 <tbarron> ping tpsilva vkmc
15:02:44 <amito> hey!
15:02:57 * dustins sees if attack roll beats gouthamr's AC on the trout shield
15:03:01 <_erlon_> Hey
15:03:01 <tbarron> amito: through with your drive already?
15:03:06 <jgrosso> hi
15:03:10 <vkmc> o/
15:03:14 <tbarron> Hi Jason!
15:03:26 <amito> tbarron my girlfriend is driving ;)
15:03:45 <jgrosso> Hey Tom!
15:03:50 <tbarron> Everyone meet jgrosso - Jason - a new addition on our team.
15:03:59 <tbarron> Hi all!
15:04:06 <tbarron> #topic agenda
15:04:13 <ganso> welcome to manila jgrosso! =)
15:04:22 <_erlon_> Nice, hey Jason
15:04:22 <jgrosso> Thanks!!
15:04:25 <tbarron> #link https://wiki.openstack.org/wiki/Manila/Meetings
15:04:26 <jgrosso> Hey
15:04:27 <amito> Welcome jgrosso
15:04:35 <jgrosso> :)
15:04:39 <tbarron> #topic Announcements
15:05:11 <tbarron> I nominated amito for manila core.  Thanks to those who have already voted.
15:05:39 <_erlon_> Congrats amito
15:05:43 <amito> Thanks for all the upvotes and trust :)
15:05:45 <tbarron> We'll give it till next Wednesday (a week after the nomination) and if there are no reservations we'll add him.
15:06:08 <gouthamr> amito: who said anything about trust :D
15:06:21 <tbarron> I don't have any more announcements today.  Anyone else?
15:06:29 <tbarron> Trust but verify.
15:06:35 * amito puts on a sinister smile
15:06:49 <bswartz> jgrosso from RedHat?
15:07:10 <tbarron> bswartz: now he is, was Evil Machine Company
15:07:15 <jgrosso> EMC
15:07:16 <jgrosso> :)
15:07:32 <bswartz> !!!
15:07:33 <openstack> bswartz: Error: "!!" is not a valid command.
15:07:33 <ganso> tbarron: lol
15:07:48 <bswartz> I didn't know anyone remembered that acryonym
15:07:59 * bswartz slaps openstack around a bit with a large trout
15:08:06 <tbarron> he's going to be developing tests, breaking  manila.
15:08:12 <tbarron> easy work.
15:08:13 <jgrosso> Endless Meeting Company was my fav
15:08:17 <bswartz> welcome jgrosso!
15:08:18 <vkmc> EMC lol
15:08:39 <jgrosso> Thanks bswartz!
15:08:47 <tbarron> #topic Formalizing and changeing review guidelines.
15:08:50 * dustins should really keep a d20 on his desk for all the trout slapping
15:09:00 <tbarron> #link https://etherpad.openstack.org/p/manila-review-guidelines
15:09:02 * gouthamr did i misspell that too? :(
15:09:08 <tbarron> gouthamr you are up
15:09:19 <gouthamr> ty tbarron
15:09:36 <gouthamr> alright, this is a follow up on a short-discussion at the PTG
15:09:38 <tbarron> gouthamr: I did a cut and paste but I think somehow introduced that extra 'e' myself
15:09:54 <gouthamr> tbarron: no worries, you were imitating me
15:10:12 <xyang> hi
15:10:16 <gouthamr> there's some content over in the etherpad
15:10:19 * tbarron knows he meant *irritating*
15:10:23 <gouthamr> hi xyang!
15:10:42 <tbarron> all that orange is really annoying
15:10:57 <tbarron> xyang: greetings
15:11:04 * gouthamr slaps ganso with a trout
15:11:10 <gouthamr> oops, meant tbarron
15:11:14 <ganso> gouthamr: hey!
15:11:15 <tbarron> ouch
15:11:26 <gouthamr> hehe, okay.. i can tl;dr a bit
15:11:46 <gouthamr> please look at the proposal, we're all aware of the lack of reviewer attention in manila for a while now
15:12:02 <vkmc> we need reviewers for the reviewers guide
15:12:29 <gouthamr> i'm proposing some new changes, and would like buy-in before formalizing them into a devref (there's your answer ganso, missed that point on the proposal, added now)
15:12:50 * tbarron sees what vkmc did
15:13:18 <bswartz> I'm confused
15:13:49 <_erlon_> Good stuff, I was just wondering if allowing 1 +2 approvals for drivers bug fixes woundnt be a good case
15:13:50 <bswartz> I thought the +2s from different organizations was meant to satisfy the organizational diversity goal from the TC
15:14:31 <gouthamr> vkmc: i do this, a couple of releases ago I proposed this: https://review.openstack.org/#/c/321334/
15:14:35 <gouthamr> :D
15:15:12 <tbarron> bswartz: that was one of the goals but I think that isn't really being tracked in the same way any more?
15:15:15 <gouthamr> tbarron: do we mind discussing each point right here?
15:15:29 <vkmc> bswartz, apart from that, I think it's a good practice
15:15:32 <bswartz> Well either it's something we care about or something we don't care about
15:15:35 <tbarron> gouthamr: I don't mind spending some time if we can drive general agreement
15:15:37 <gouthamr> tbarron bswartz: the short take on that is on lines 37 and beyond
15:16:00 <bswartz> If we don't care about it (it seems the proposal says we shouldn't) then let's be explicit about that
15:16:03 <gouthamr> TC changed the definition of what it meant to be organizationally diverse
15:16:09 <bswartz> I don't think the TC would be upset
15:16:17 <bswartz> gouthamr: they did? do you have a link?
15:16:19 <vkmc> encouraging reviews from people with different affiliations aims to reduce bias
15:16:21 <gouthamr> and we no longer have a tag on each project
15:16:23 <vkmc> it's fair
15:16:46 <gouthamr> #LINK https://review.openstack.org/#/c/579870/
15:16:57 * gouthamr finds link to ML thread
15:17:29 <vkmc> gouthamr, you like meta-planning stuff lol
15:17:34 <bswartz> The commit message here is fine
15:17:46 <bswartz> ttx lays out a good case for why the tag is harmful
15:17:48 <tbarron> vkmc: I still want to encourage diversity, the question is whether we need a rule that requires this on every review
15:18:21 <tbarron> even when e.g. we're just fixing stuff and there's no particular organizational interest at stake
15:18:22 <vkmc> tbarron, imho this should be mandatory for new features, not mandatory for bug fixes
15:18:27 <gouthamr> #LINK http://lists.openstack.org/pipermail/openstack-dev/2018-June/131029.html
15:18:28 <bswartz> tbarron: if you think reviews add value beyond just a rubber stamp, then keep them
15:18:29 <vkmc> there is no bias in trying to fix something that is broken
15:18:53 <gouthamr> bswartz: +1
15:18:57 <gouthamr> tbarron: +1
15:19:14 <gouthamr> i'm only seeking dropping the need for rubber-stamp reviews
15:20:09 <tbarron> do we leave it to the workflow+1 person's judgment whether an additional review would be rubber-stamp or real review?
15:20:16 <bswartz> I don't think it's possible to know if a review will be a rubber stamp or not
15:20:50 <bswartz> If you want a review, ask for it. If you want a rubber stamp, then don't ask for it and ninja merge instead
15:21:13 <gouthamr> bswartz: nooo
15:21:15 <bswartz> I don't see what the problem with ninja merges is
15:21:27 * gouthamr , points to line on Ninja Merges: #52
15:22:00 <gouthamr> bswartz: i am uncomfortable doing it, and i've added a couple of links with specific cases when ninja-merges may be useful
15:22:19 <bswartz> What's the case against ninja merges?
15:22:31 <gouthamr> bswartz: it's anti-community?
15:22:47 <bswartz> It's something the tools let us do -- the prohibition on them is something we enforce socially
15:23:12 <bswartz> I would only be upset if someone exercised poor judgement with a ninja merge
15:23:37 <gouthamr> +1, so i think we should retain our current policy on it - don't do it if you can help it
15:23:45 <ganso> I think reviews are important everywhere except trivial changes, gate fixes and version upgrades
15:23:50 <gouthamr> instead of relying on our judgements
15:24:16 <gouthamr> ganso: absolutely +1
15:24:46 <bswartz> ganso: are you in favor of dropping the review requirements in some cases then?
15:24:50 <ganso> yea, people's judgements vary, in a way that it may seem like another reviewer feedback is not needed but actually is
15:25:01 <ganso> bswartz: just some cases
15:25:02 <vkmc> ganso++
15:25:39 <vkmc> ninja merging should be the last resource
15:25:39 <amito> ganso: i agree, moreover, this is the way to improve code quality
15:25:54 <bswartz> I think we need to trust eachother on this kind of thing. If you don't feel like you could trust someone to exercise judgement, then don't nominate them to be a core reviewer
15:26:11 <vkmc> because we need to fix something urgently (due to time constrains) and it's safe to do it
15:26:19 <vkmc> bswartz++
15:27:13 <dustins> If you abuse your powers, we'll know :)
15:27:31 <bswartz> Yes we have audit trails of what people do
15:27:46 <bswartz> I don't think we've had big problems with people abusing trust
15:28:09 <bswartz> So I don't see a need to change anything
15:28:44 <gouthamr> bswartz: can you clarify, anything, as in any of the problems in the proposal, or a specific one?
15:28:48 <ganso> bswartz: in the end of the day we are humans and we do some mistakes, we overlook some problems in the code, having 2 reviewers is good for code quality and because we have diverse opinion on how to implement something or fix a bug. Our history has shown us many times that we had code almost merging and somebody shows up with a -1 and a valid point on something to fix or improve
15:29:26 <tbarron> bswartz: are you saying that we don't need a doc that writes down expecations?  I think that would be helpful as guidelines even
15:29:34 <bswartz> gouthamr: I don't understand your dislike for ninja merging -- it's an important tool, and using it would solve some of the problems you seem to be complaining about
15:29:41 <tbarron> though I don't think a set of formal rules may make sense.
15:29:57 <gouthamr> bswartz: hey, let me remind you of your ninja merge history :)
15:29:59 <gouthamr> bswartz
15:30:05 <gouthamr> bswartz: it's really short :P
15:30:17 <bswartz> And I'm still not clear on what specific problem we're trying to solve
15:30:24 <gouthamr> bswartz: i.e, we don't really have a dire-need for writing teh code and merging it ourselves
15:30:38 <gouthamr> before anyone else has a say in it
15:30:48 <tbarron> note two difft kinds of ninja merges !
15:30:49 <bswartz> gouthamr: are you arguing that's a good thing or a bad thing?
15:30:58 <tbarron> one reviewer different coder
15:31:00 <gouthamr> bswartz: a good thing
15:31:08 <tbarron> one reviewer coded change themselves
15:31:21 <tbarron> the latter should be exceptional for sure
15:31:34 <bswartz> Yeah I was able to avoid ninja merges for the most part
15:31:37 <gouthamr> tbarron: there's only ONE kind of ninja merge - I am the author of the change, and i merge it myself (usually before anyone else has to weigh in)
15:32:01 <bswartz> But that's not because I was afraid to do it, I was just able to find people quickly enough when I needed them
15:32:16 <ganso> ninja merge = I code the fix, I merge it myself. This is not what we want. What we want: one person codes an urgent gate fix, another person from the same company solely merges it
15:32:18 <tbarron> gouthamr: ok if that's the definition but we were also talking about more general issues
15:32:45 <bswartz> ganso: we can achieve that by dropping our explicit diversity goal
15:32:46 <gouthamr> bswartz: +1, i managed to dig through the team's history and see why we did it when we did it
15:32:47 <gouthamr> and put out a couple of fine examples
15:32:55 <tbarron> ganso: I have no problem with a ninja merge fixing gate if no one else is around
15:33:21 <ganso> tbarron: yes, we do it excepcionally, we don't want to make it the norm
15:33:25 <gouthamr> +1
15:33:32 <tpsilva> I think Valeriy used to that a lot, and it was always helpful
15:33:35 <tbarron> or if we already agreed in the community meeting to do the change and it's trivial to execute
15:33:41 <tpsilva> for gate fixes
15:33:41 <ganso> tbarron: if there are 2 people are there is no need to ninja merge
15:33:53 <gouthamr> +1
15:33:55 <tbarron> ganso: ditr
15:33:59 <ganso> s/are there/around, there
15:34:02 <tbarron> s/ditr/sure/
15:34:48 <tbarron> So do we have a problem with people ninja merging now or is this a matter of writing down our expectations?
15:35:23 <bswartz> Writing down the current expectations makes sense
15:35:40 <bswartz> I don't see a need to change any longstanding policy
15:35:48 <bswartz> Although I'd be open to changing policies for good reasons
15:36:00 <bswartz> I just feel like I'm missing something
15:36:05 * bswartz goes to read etherpad one more time
15:36:10 <gouthamr> that's good clarification, ty - can i ask about specific proposals? or do you want to discuss this on a review?
15:36:33 <ganso> gouthamr: we could consolidate it on a doc page through gerrit review
15:36:39 <gouthamr> i see some good points on the etherpad, ty ganso, tbarron, tpsilva (?)
15:37:17 <tbarron> We've taken a bit of time today but it's been a healthy discussion.
15:37:43 <tbarron> gouthamr: why don't you post this in review.  Then let's have another meeting topic after everyone
15:37:58 <gouthamr> tbarron: ack, will do
15:38:00 <tbarron> has had a chance to digest it again, have sidebar conversations, etc.
15:38:29 <gouthamr> absolutely, thanks everyone!
15:38:40 <tbarron> I think it was good to have the etherpad and open discussion rather than just a bare review.
15:39:03 <tbarron> #topic Planning Our work
15:39:20 <tbarron> #link https://wiki.openstack.org/wiki/Manila/SteinCycle
15:39:46 <tbarron> We introduced this wiki page last week and it's still WIP but
15:40:17 <tbarron> I want to spend a few minutes discussing how to maintain and use it.
15:40:36 <tbarron> Let's look at the python3 topic as an example.
15:40:51 <tbarron> vkmc is the lead on this story.
15:41:02 <tbarron> Doesn't mean that she does all the work.
15:41:29 <tbarron> But she is responsible for defining the tasks and for ensuring that
15:41:34 <tbarron> the status is up to date.
15:42:01 <tbarron> She can do that by editing the wiki or by emailing me since I'm going to do at least a weekly sweep.
15:42:25 <tbarron> other people doing work on this project -- like gouthamr -- can do the same.
15:42:33 <tbarron> No strict hierarchy.
15:42:39 <tbarron> Make sense?
15:42:51 <dustins> +1
15:42:56 <gouthamr> +1
15:43:03 <vkmc> +1
15:43:12 * tbarron notes that he filled this one out and vkmc and gouthamr should slap him with trout and ensure that it's corrected after the meeting
15:43:14 <bswartz> Makes sense
15:43:29 <amito> +1
15:43:29 <tbarron> ok, moving down the list
15:43:55 <tbarron> Jun isn't here today so we'll skip Priority for Access rules.
15:44:19 <tbarron> gouthamr: check that what I said on the json schema validation is correct
15:44:27 <gouthamr> tbarron: it is
15:44:53 <gouthamr> we sent an email to the spec owners asking if they want to continue working on JSON schema validation for Stein, no response yet
15:45:07 <tbarron> ganso: on manage/unmaage dhss=true please update or send me mail and I will
15:45:47 <ganso> tbarron: thanks for reminding me, I'll update
15:45:49 <tbarron> ganso: same for replicatin/dhss=True and share from snapshot in different pool/back end
15:46:20 <tbarron> vkmc: please check manila ui plugin (also dustins )
15:46:32 <dustins> tbarron: wilco
15:46:57 <tbarron> on manila CSI gouthamr is scheduling a meeting with the CERN folks who are proposing same
15:47:26 <gouthamr> +1, forgot to add it to this meeting, we just have confirmation of availability from the CERN folks
15:47:51 <tbarron> and we're working with hodgepodge on standing sig-k8s meetings on manila and cinder CSI
15:47:58 <tbarron> all early stuff
15:48:13 <gouthamr> if we have anyone here that would like to know what's going on right now with Manila/CSI/dynamic-provisioner/*, please let me know i'll forward you an invite
15:48:13 <tbarron> vkmc: you own the uwsgi project
15:48:31 <vkmc> yes
15:48:45 <tbarron> gouthamr: you are driving osc integration
15:48:57 <gouthamr> tbarron: ack, status coming soon-ish
15:49:10 <tbarron> note that this should be a project to which we can have lots of contributors once it's underway
15:49:33 <gouthamr> +1
15:49:33 <tbarron> amito: you are going to lead the sdk integration I think?
15:49:45 <amito> tbarron: yep
15:50:04 <tbarron> another one that once framed we should be able to have people sign up for chunks  of work
15:50:15 <gouthamr> tbarron amito: storyboard: https://storyboard.openstack.org/#!/story/2003752
15:50:25 <gouthamr> for the OS-SDK work
15:50:35 <amito> tbarron: some of it has already been implemented in the PTG, I don't think it should be a lot of work
15:50:44 <tbarron> vkmc: are you planning a spec for the next telemetry work ?
15:51:15 <vkmc> tbarron, I don't think is needed since it was mostly finish work we had planned in the previous spec and documentation
15:51:28 <vkmc> tbarron, but if we need it, I'll submit it by the end of the week
15:51:34 <tbarron> vkmc: k, makes sense, that's kinda what I was thinking.
15:51:40 <vkmc> :)
15:52:19 <tbarron> Any more on this topic today?  Going forwards I'm hoping most of keeping this up to date will be *outside* this meeting.
15:52:43 <tbarron> #topic Bugs
15:52:52 <tbarron> dustins: got any for us today?
15:53:09 <dustins> Just one today, since the other was already squashed by gouthamr
15:53:12 <tbarron> #link https://wiki.openstack.org/wiki/Manila/SteinCycle#Bug_Triage
15:53:15 <dustins> #link https://etherpad.openstack.org/p/manila-bug-triage-pad
15:53:22 <tbarron> jinx
15:53:35 <dustins> #link: https://bugs.launchpad.net/manila/+bug/1795463
15:53:35 <openstack> Launchpad bug 1795463 in Manila "pagination limit not enforced on db" [Undecided,New]
15:53:57 <bswartz> Is this just a missing optimization?
15:54:00 <gouthamr> tech debt :(
15:54:23 <bswartz> Doing pagination right is hard work
15:55:12 <bswartz> I think the bug description should read "pagination doesn't speed up list queries"
15:55:21 <gouthamr> true
15:55:43 <bswartz> Because speeding up the operation is the whole point
15:56:21 <tbarron> so this one is confirmed, right?
15:56:29 <gouthamr> currently, we're using some python methods to do the limit and the offset, but as maurice notes, this should be done in the DB to get some speedup
15:56:39 <tbarron> how serious?
15:56:52 <gouthamr> we've some examples in the newer APIs
15:56:55 <tbarron> do we want maurice if he wants to fix it?
15:57:08 <bswartz> It's a performance bug, so that lowers the priority somewhat
15:57:21 <tbarron> gouthamr: examples of doing it right?
15:57:25 <gouthamr> tbarron: we want maurice :D
15:57:32 <tbarron> bswartz: +1
15:58:01 <gouthamr> tbarron: yes, i think, i can point it out on the bug, he points to an old manila commit that dropped it in the /shares APO
15:58:04 <gouthamr> API*
15:59:39 <tbarron> #action gouthamr will update the bug with pointers and ask maurice if he wants to work on it
15:59:48 <tbarron> I did the other updates
16:00:03 <gouthamr> ack
16:00:22 <tbarron> #action dustins put this on in your keep-track-of list on the etherpad please
16:00:30 <tbarron> out of  time
16:00:31 * bswartz glances at the clock
16:00:37 <tbarron> Thanks everyone!!!
16:00:41 <bswartz> thx!
16:00:42 <tbarron> #endmeeting