15:00:54 <tbarron> #startmeeting manila
15:00:55 <openstack> Meeting started Thu Jul 19 15:00:54 2018 UTC and is due to finish in 60 minutes.  The chair is tbarron. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:58 <openstack> The meeting name has been set to 'manila'
15:00:58 <zhongjun__> hi
15:01:04 <bswartz> .o/
15:01:09 <ganso> o/
15:01:24 <tbarron> manila courtesy ping: gouthamr zhongjun xyang markstur toabctl bswartz ganso erlon tpsilva vkmc vgreen erlon dustins
15:01:34 <markstur> hi
15:01:54 * tbarron waits a minute
15:02:00 <gouthamr> o/
15:02:08 <bswartz> Someone needs to send gouthamr some coffee
15:02:28 <tbarron> looks like he was busy reviewing last night
15:02:35 <vkmc> o/
15:02:40 <zhongjun__> hi
15:02:41 <vgreen> o/
15:02:45 <tbarron> Hi all!
15:02:47 <gouthamr> not as fast as zhongjun__ writing code i suppose :P
15:03:12 <zhongjun__> gouthamr: coffee enjoy  :D
15:03:13 <tbarron> Agenda: https://wiki.openstack.org/wiki/Manila/Meetings
15:03:33 <tbarron> #topic announcments
15:03:52 <dustins> \o
15:03:58 <tbarron> just a reminder that we have a PTG planning etherpad on which you can indicate
15:04:08 <tbarron> 1) plans for attendance, in person or remote
15:04:15 <tbarron> 2) topics
15:04:32 <tbarron> #link https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018
15:05:22 <tbarron> That's all I have for announcements, we'll talk about M3 in a moment
15:05:32 <tbarron> Anyone else have announcemnts?
15:05:49 <erlon> hey
15:05:58 <tbarron> hey erlon
15:06:08 <tbarron> #topic review focus
15:06:17 <tbarron> M3 is upon us.
15:06:28 <tbarron> 26 July, feature freeze
15:06:45 <tbarron> we can merge bug fixes, test only changes, etc. after that but
15:06:56 <erlon> tbarron, do any of us have the gear to do the remote sharing?
15:07:03 <tbarron> even if it's marked as a bug rather than a blueprint,
15:07:16 <tbarron> we won't be doing microversion bumps
15:07:27 <tbarron> we'll be going into soft string freeze, etc.
15:08:02 <tbarron> erlon: I'm hoping that ganso will bring his camera ...
15:08:05 <ganso> erlon, tbarron: last time we had Ben's camera and microphone
15:08:08 <ganso> tbarron: I don't have a camera
15:08:22 <tbarron> ganso: ah, it was Ben's
15:08:27 <erlon> I have attended remotely once and is very hard to listen when is not possible to move the mic around
15:08:34 <bswartz> Well more acurately it belongs to Tim
15:08:55 <bswartz> And I purloined it for the PTG
15:08:56 * tbarron notes that it's be nice to Tim day
15:09:38 <tbarron> xyang and gouthamr were remote last time - how was the sound?
15:10:02 <gouthamr> i was hardly around, but it was decent i think...
15:10:12 <ganso> I need to confirm with my manager if I can take one camera that we have here, but it will not be as good as the one we had previously used
15:10:35 <ganso> tbarron: I watched the recordings and the audio and video were very good
15:10:42 <tbarron> ganso: bswartz: well it would be great then if we could use Tim's again
15:10:53 <tbarron> ganso: bswartz: would you guys check on that?
15:10:58 <bswartz> I will look into options
15:11:03 <erlon> Ill also do some tests with my speakers
15:11:13 <tbarron> erlon: great
15:11:17 <ganso> tbarron: problem is, if bswartz does not go, there will be nobody to take the camera there, as the camera is at RTP, and erlon and I are in Brazil
15:11:17 <tbarron> thanks all
15:11:33 <bswartz> #link https://www.amazon.com/Logitech-Conference-BCC950-Webcam-Speakerphone/dp/B0083I7Y8W
15:12:15 <tbarron> ah, this was in part a way of highlighting a potential first time event
15:12:32 <tbarron> bswartz: you have better things to do?
15:12:54 <bswartz> I'll attend remotely
15:12:56 * tbarron puts him on the spot
15:13:18 <bswartz> Travel is not approved
15:13:18 <tbarron> ok, back to #topic
15:13:25 <dustins> bswartz: :(
15:13:45 <tbarron> Review focus
15:13:58 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-review-focus
15:14:03 <zhongjun__> bswartz: me too:(
15:14:37 <tbarron> :(  I'll put PTG planning on the agenda for next week
15:15:08 <tbarron> The Inspur driver merged
15:15:17 <tbarron> #link https://review.openstack.org/#/c/550454/
15:16:00 <tbarron> netapp snapshot visibility feature and its dependency on
15:16:10 <tbarron> ensure-shares mod merged
15:16:41 <tbarron> json schema query validation
15:16:47 <tbarron> #link https://review.openstack.org/#/c/550454/
15:17:01 <bswartz> wrong link?
15:17:16 <tbarron> Gouthamr has suggested that we only begin schema validations at a new microversion
15:17:18 <tbarron> sorry, sec
15:17:59 <tbarron> #link https://review.openstack.org/#/c/563429/
15:18:25 <tbarron> so we'd use our old non json validation for older microversions
15:18:44 <tbarron> this will simplify the changes needed to get this off the ground and
15:18:55 <tbarron> ensure 100% backwards compatability
15:19:16 <tbarron> since otherwise we'd be returning errors for garbage that was previously ignored
15:19:34 <tbarron> We haven't heard back from the folks implementing this.
15:19:55 <tbarron> So it seems likely that this work will get moved to the Stein release.
15:20:04 <gouthamr> +1 this's been quite inconsistently dealt with in the other projects, and we can either retroactively fix our APIs, or make them strictly validate beyond a particular version
15:20:49 <gouthamr> we need more eyes on that change, and its implications..
15:21:02 <tbarron> +1
15:21:42 <tbarron> If anyone disagrees with the gouthamr view on this one please say so (and says so in the review!)
15:21:47 <ganso> can't we start strictly validating and then retroactively fix based on our needs?
15:22:08 <bswartz> Not without possibly breaking something that works today
15:22:18 <bswartz> And there's no way to know who/what might be broken
15:22:37 <bswartz> That doesn't mean there isn't room for debate
15:22:47 <tbarron> I agree with bswartz on this one.  We'll be a bit different than cinder and nova at older microversions but
15:23:02 <tbarron> we're already different from them at those microversions
15:23:16 <tbarron> And going forwards user experience will converge.
15:23:35 <tbarron> Errors will be returned when you put garbage in the request body
15:24:22 <tbarron> Now if there's a real bug in the past -- something is broken -- we can fix it, but
15:24:39 <tbarron> ignoring garbage isn't a clear case of broken functionality.
15:25:14 <ganso> maybe I didn't write it in a good way, but that's what I meant. I think we should fix it for the current microversion so the future ones are correct, and only go back if we ever need to
15:25:16 <tbarron> Anyways, unless these guys get back on this one very quickly it will get moved to Stein.
15:25:49 <tbarron> ganso: +1 now knowing we all intend "if we need to" appropriately
15:26:30 <tbarron> OK, let's talk about the access rule metadata work.
15:26:41 <tbarron> #link https://review.openstack.org/#/c/563429/
15:26:54 <tbarron> did it again, sec
15:27:09 <tbarron> #link  https://review.openstack.org/#/c/570708/
15:27:16 * gouthamr +1 coffee to East coast please
15:27:22 <tbarron> #link  https://review.openstack.org/#/c/571366/
15:27:38 <tbarron> #link   https://review.openstack.org/#/c/579534/
15:27:41 <ganso> gouthamr: lol
15:27:42 <tbarron> gouthamr: :D
15:28:01 * tbarron is getting used to mouse at new desk and office ...
15:28:23 <tbarron> gouthamr has been doing awesome review workk on this one
15:28:34 <tbarron> gouthamr: what's your sense of its status?
15:28:42 <zhongjun__> gouthamr: So many worth comments, Thank you
15:28:42 <tbarron> *work
15:28:56 <tbarron> zhongjun__: flattery will get you nowhere :D
15:29:04 <gouthamr> tbarron: i think the server-side and tests are close, i had minor-ish suggestions on the tests
15:29:39 <gouthamr> haven't looked at the client, but i have a good feeling it will be ready today/tomorrow
15:29:49 <zhongjun__> tbarron: haha ,  but It's true
15:30:24 <tbarron> zhongjun__: I had some weird results testing this in devstack but let me do fresh cherry-picks and see if
15:30:30 <tbarron> zhongjun__: there's still an issue
15:31:21 <zhongjun__> tbarron: I saw your response, sorry but I can not reproduct the error
15:31:57 <tbarron> bswartz: you had a +1 on this earlier, are you planning to review it again and perhaps try it out in devstack?
15:32:33 <tbarron> that was at PS#7 and we're at #27 now
15:32:51 <bswartz> Well it looks like there's more that needs fixing based on gouthamr's comments and zuul
15:33:01 <bswartz> I'll be happy to take another look after it's not in flux
15:33:03 <tbarron> correction, #28
15:34:00 <tbarron> I'm looking at this one too but our team diversity rules mean we need more than rubber stamp review from someone non Red Hat
15:34:30 <tbarron> So *everybody* tell your managers and product managers that if they want to get
15:34:42 <tbarron> *their* features merged in OpenStack then
15:34:53 <tbarron> there's reciprocity expected.
15:35:15 <tbarron> OpenStack only works if we have a diverse, active set of reviewers.
15:35:33 <tbarron> I'm getting concerned about this, but we can come back to it
15:35:39 <tbarron> as a topic for another meeting.
15:35:44 <bswartz> I'm not sure if holding patches hostage is the best way to encourage more reviews, but it may be worth a try
15:36:02 <tbarron> I think short of holding patches hostage we just have
15:36:13 <tbarron> to recognize that reviewer bandwidth is finite
15:36:24 <tbarron> and that the order in which we work backlogs may be
15:36:42 <tbarron> influenced by whether companies are themselves participating in
15:36:48 <tbarron> the OpenStack way.
15:37:00 <tbarron> A good bugfix is a good bugfix no matter what.
15:37:24 <tbarron> But a bell-and-whistle for a back end may not be considered that important by the community if
15:37:36 <tbarron> we don't have enough review bandwidth.
15:37:45 <tbarron> OK, moving along.
15:38:02 <tbarron> I think the access list metadata stuff is in pretty good shape.
15:38:23 <tbarron> And is likely to merge in time for this cycle.
15:38:50 <tbarron> How about access list rules priority?
15:39:11 <tbarron> #link https://review.openstack.org/#/c/572283/
15:39:46 <tbarron> #link      Reviewers:  https://review.openstack.org/#/c/574633/
15:40:12 <tbarron> This one is dependent on the metadata stuff
15:40:44 <gouthamr> looks like we've ignored this change this week
15:41:16 <tbarron> gouthamr: well Jun has I think attempted to address your major concern
15:41:27 <zhongjun__> It's a simple change based on access metadata, but it has less review than metadata patch
15:41:47 <tbarron> but I got a headache working on this one and it doesn't seem simple to me :D
15:42:07 <gouthamr> +1
15:42:08 <tbarron> zhongjun__: maybe if we get some other reviewers they'll think it's simple
15:42:31 <gouthamr> zhongjun__: don't think it is simple, wrt user/api impact.. perhaps lesser number of lines of code :)
15:43:21 <tbarron> zhongjun__: You are doing great work on this but I think b/c it depends on the other one we have some
15:43:26 <zhongjun__> It's only add one parameter :D
15:43:30 <tbarron> serialization effect and
15:43:45 <zhongjun__> Cloud we apply FFT for feature that cannot be merged before M3
15:43:46 <tbarron> this potentially has quite a bit of driver impact
15:44:01 <tbarron> FFE
15:44:03 <tbarron> I think
15:44:09 <zhongjun__> oh FFE
15:44:25 <tbarron> maybe, but the main thing is that we really need to understand the implications well
15:44:55 <tbarron> this is an area (access rules) where manila has made changes before that we later regretted
15:45:16 <tbarron> so I don't want to rush this through without thorough review and testing
15:45:16 <zhongjun__> tbarron: We already know it when we reviewing the priority spec
15:45:45 <tbarron> zhongjun__: right, and then we said we'd need to be careful with the implementation
15:46:06 <tbarron> zhongjun__: I don't think the team has vetted this one well enough yet.
15:46:11 <tbarron> That's no comment on you.
15:46:26 <tbarron> So let's see what reviewers can do.
15:46:37 <zhongjun__> tbarron: okay
15:46:43 <tbarron> I just don't want anyone to be surprised at this point.
15:47:02 <tbarron> If this work has to continue into Stein then that's not the end of the world.
15:47:19 <tbarron> OK, moving alone
15:47:22 <tbarron> along
15:47:29 <tbarron> maybe alone in my views as well :D
15:47:49 <tbarron> #topic bugs
15:48:00 <tbarron> Dustin, you are up.
15:48:15 <dustins> Sounds good
15:48:31 <dustins> Short list today
15:48:37 <dustins> #link: https://bugs.launchpad.net/manila/+bug/1781127
15:48:37 <openstack> Launchpad bug 1781127 in Manila "Share groups created from snapshot can be created with different share group type" [Undecided,New]
15:49:55 <dustins> So this looks like an issue with share group types and snapshots and that some proper validation is not occurring
15:50:01 <gouthamr> ah, this is an easy one.. the API needs a minor fix to reject setting the share group type if it isn't the same as the source
15:50:19 <tbarron> How important is this one?
15:51:00 <dustins> It doesn't seem super critical, but it does put us into an indeterministic state
15:51:07 <tbarron> Fix-when-convenient?
15:51:11 <ganso> it allows the users to do nasty things
15:51:26 <dustins> ganso: Yeah, and that worries me
15:51:29 <tbarron> Schedule to be fixed soon?
15:51:56 <dustins> I think High is a good choice, especially if it allows someone to do something nefarious
15:52:31 <tbarron> If we set it to High we need to schedule the fix which means we need someone to volunteer to fix it.
15:52:37 <tbarron> other than gouthamr
15:52:46 <tbarron> but he can advise
15:52:54 <tbarron> and review :D
15:53:10 * tbarron is partly joking but we need to balance work a bit
15:53:21 <dustins> tbarron: I can have a look at it
15:53:27 * gouthamr /me on the dark side
15:53:28 <dustins> Seems like a fairly easy fix
15:53:36 <tbarron> dustins: awesome
15:53:47 <dustins> and I can work with gouthamr as my guide
15:53:58 <gouthamr> ++
15:54:13 <dustins> Who says I can't be judge, jury, and executioner?
15:54:15 <dustins> :)
15:54:30 <dustins> Moving on...
15:54:39 <dustins> #link https://bugs.launchpad.net/manila/+bug/1782394
15:54:39 <openstack> Launchpad bug 1782394 in Manila "Share type extra specs in tempest tests should be enabled only if the tested microversion has support for them" [Undecided,New]
15:54:52 <dustins> This one is a tempest bug that vkmc found
15:55:42 <tbarron> Fix when convenient?
15:55:59 <dustins> Yeah, definitely needs fixing but not right this second
15:56:16 <dustins> done!
15:56:25 <tbarron> Then I think we can have it in our backlong unassigned atm.
15:56:31 <dustins> Yeah
15:57:06 <dustins> Hmm, we should put a link somewhere semi-prominent for new devs to look at triaged, unassigned bugs if they're looking for a way to get into development...
15:57:15 <dustins> But that might be a topic for another time
15:57:32 <tbarron> +1, +1
15:57:44 <tbarron> timecheck
15:58:17 <tbarron> dustins: do you have another quick one?
15:58:37 <dustins> Nope!
15:58:46 <tbarron> #topic open discussion
15:58:59 <tbarron> anything? we can take it to #openstack-manila
15:59:18 <tbarron> OK, thanks everybody!!
15:59:23 <tbarron> #endmeeting