15:00:28 <tbarron> #startmeeting manila
15:00:33 <openstack> Meeting started Thu Jul 12 15:00:28 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:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <openstack> The meeting name has been set to 'manila'
15:01:07 <tbarron> manila courtesy ping: gouthamr zhongjun xyang markstur toabctl bswartz ganso erlon tpsilva vkmc vgreen erlon dustins
15:01:13 <bswartz> .o/
15:01:14 <gouthamr> o/
15:01:14 <ganso> hello
15:01:15 <zhongjun__> hi
15:01:45 * tbarron waits a minute
15:02:15 <tbarron> Hi all!
15:02:19 <erlon_> Hey
15:02:26 <tbarron> Looks like we have a pretty small group today
15:02:30 <tbarron> Hey erlon_
15:02:48 <tbarron> Agenda: https://wiki.openstack.org/wiki/Manila/Meetings
15:02:59 <tbarron> #topic Announcements
15:03:16 <vgreen> hey
15:03:18 <tbarron> I set up a PTG planning etherpad here
15:03:20 <amito> o/
15:03:24 <tbarron> Hi vince, amit!
15:03:37 <dustins> \o
15:04:00 <tbarron> #link https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018
15:04:29 <tbarron> It's time to lobby your employers and start adding your names to the attendees or remote attendees links there
15:04:39 <tbarron> s/links/lines/
15:04:59 <vgreen> submitted my ptg request, cross fingers
15:05:02 <tbarron> And as you think of subjects we should discuss, please take a minute to add them to the etherpad
15:05:11 <tbarron> vgreen++
15:05:26 * gouthamr you're doing great work vgreen
15:05:43 <tbarron> I think physical presence in Dublin was really useful.  And we should have less snow.
15:05:45 * gouthamr fails at imitating awesome cephalobot
15:06:05 * tbarron thinks gouthamr lacks a few necessary arms for that role
15:06:15 <gouthamr> :P
15:06:35 <xyang> hi
15:06:35 <tbarron> OK, that's all I have for announcments, anyone else?
15:06:40 <tbarron> xyang !!
15:06:47 <xyang> :)
15:06:48 <tbarron> nice to "see" you.
15:07:04 <xyang> nice to "see" you too:)
15:07:10 <zhongjun__> xyang: long time no see :P
15:07:18 <xyang> :)
15:07:26 <tbarron> be sure to come to Denver and attend manila PTG Mon & Tuesday, lots of cool cinder and SDS people will be there
15:07:44 <tbarron> #topic Review Focus
15:07:57 <tbarron> #link https://etherpad.openstack.org/p/manila-rocky-review-focus
15:08:07 <tbarron> Please take a look
15:08:46 <tbarron> M3 is approaching
15:09:18 <tbarron> #link https://releases.openstack.org/rocky/schedule.html
15:09:38 <tbarron> We really need reviewers, otherwise we're sure to slip work to the next cycle
15:09:55 <bswartz> Can I ask about https://review.openstack.org/#/c/579534/
15:10:08 <tbarron> bswartz: of course
15:10:21 <bswartz> Zuul keeps voting -1
15:10:29 <bswartz> But I haven't looked into why
15:10:50 <bswartz> zhongjun__: Are the problems easy to fix or is it something more serious?
15:11:13 <tbarron> This is for the metadata for access rules work
15:12:47 <gouthamr> we have a recurring issue with migration tests on the voting LVM job for one.. but this patch doesn't seem to have failed because of that
15:13:06 <zhongjun__> It passed before
15:13:58 <zhongjun__> I updated it because I have to fix gouthamr ‘s comments
15:14:29 <tbarron> it passed on PS#10, right?
15:15:27 <zhongjun__> bswartz: Zuul voted +1 in patch 3
15:15:35 <bswartz> Ok I see it
15:15:41 <bswartz> That was just last night
15:15:46 <bswartz> I haven't looked since yesterday
15:15:48 <bswartz> THanks
15:16:12 <zhongjun__> patch 10
15:16:30 <tbarron> the failure in the current patch seems to be in the access rules though, on dummy driver
15:16:38 <zhongjun__> thank you to care about that
15:16:54 <tbarron> NameError: global name 'CONF' is not defined
15:17:10 <zhongjun__> tbarron: yes, and it already fixed now
15:17:12 <tbarron> seems like an incidental issue
15:17:22 <bswartz> I'm cool
15:17:36 <bswartz> I'll vote after I see another pass
15:17:48 <tbarron> gouthamr: did your main concerns on this one get addressed?
15:18:29 <gouthamr> tbarron: just woke up to zhongjun's new patchsets :D
15:18:49 <tbarron> gouthamr: ok, thanks for reviewing this one, we'll stay tuned
15:18:55 <tbarron> moving along then
15:18:59 <tbarron> Inspur driver
15:19:04 <zhongjun__> gouthamr: haha thank you
15:19:07 <tbarron> #link https://review.openstack.org/#/c/550454/
15:19:12 * bswartz pokes gouthamr with a stick
15:19:24 <tbarron> Has one +2, needs eyes other than Red Hat
15:19:50 <tbarron> someone want to sign up for this one?
15:19:56 <gouthamr> zhongjun__: your previous comments seem to have been addressed
15:19:57 <gouthamr> on ^
15:20:06 <bswartz> Wow, working CI
15:20:13 <bswartz> Congrats inspur
15:20:24 * bswartz notices the 3 hour run time o_O
15:20:43 <tbarron> Yeah they have followed infinidat's good example from the last cycle
15:20:59 <zhongjun__> gouthamr: yeah, I will check again asap
15:21:14 * tbarron wasn't talking about run time, just being timely and responding to reviews, etc.
15:21:46 <tbarron> zhongjun__: I see you are signed up, thanks!
15:21:50 <tbarron> moving along
15:22:06 <tbarron> json query validation
15:22:17 <tbarron> #link https://review.openstack.org/#/c/550454/
15:22:26 <tbarron> And there may be some others at this point
15:22:49 <tbarron> They've have posted the basic framework and substance for share-type validation
15:23:06 <tbarron> This could well trickle into the next release
15:23:17 <tbarron> which in my view is fine, we can do this incrementally
15:23:27 <tbarron> But we need some non Red Hat reviewers
15:23:29 <gouthamr> +1, i see this happening with other projects as well
15:23:53 * tbarron thanks gouthamr for his API expertise in joining review team for this one though
15:24:44 <bswartz> fwiw zhongjun is signed up on the etherpad for this one
15:25:04 <tbarron> bswartz: for the inspur driver, right?
15:25:10 <zhongjun__> right?
15:25:14 <zhongjun__> oh ,yes
15:25:19 <tbarron> bswartz: I don't see her for the json query
15:25:32 <tbarron> and I know she is doing lots of work
15:26:05 <tbarron> Reviewers at this point seem to be mostly zhongjun, gouthamr, bswartz and myself
15:26:09 <tbarron> mostly
15:26:10 <bswartz> Oh sorry I lost context
15:26:40 <tbarron> So we have limited bandwidth when (as happened to me this last week with some hot customer issues) we have to do other work.
15:26:53 <ganso> sorry for not being able to dedicate much time reviewing :(
15:27:01 <tbarron> It is possible that some work will have to roll to the next release for this reason.
15:27:22 <tbarron> But if so, then that's just the way it will be.  We'll keep a backlog and keep working.
15:27:28 <tbarron> OK, moving along.
15:27:37 <tbarron> Priority for access rules
15:27:50 <tbarron> #link https://review.openstack.org/#/c/572283/
15:28:04 <tbarron> #link https://review.openstack.org/#/c/572283/
15:28:23 <gouthamr> tbarron: did we finish talking about the "metadata for access rules" bp?
15:28:26 <tbarron> I personally think this is a tricky one to implement but let's see
15:28:56 <tbarron> gouthamr: well, you said you were just waking up and I said ok, let's discuss matters in the review
15:29:08 <tbarron> gouthamr: or that's what I *thought* we said
15:29:17 <tbarron> gouthamr: should I reset the topic?
15:29:20 <gouthamr> oh, my bad - i meant the tempest patch
15:29:39 <tbarron> gouthamr: ok, #topic is review focus anyways
15:29:54 <tbarron> gouthamr: do you have things to say on the access rule work?
15:29:56 <gouthamr> no, just wanted to note that that there is a dependency here - metadata precedes priority
15:30:09 <tbarron> I mean the metadata for access rule work
15:30:29 <tbarron> zhongjun__: bswartz - note ^^^, agree?
15:30:50 <bswartz> Yes
15:31:06 <tbarron> +1 from me
15:31:08 <zhongjun__> gouthamr: Thanks for mention that, The priority patch depend on  access metadata patch
15:31:44 <tbarron> OK, I noted that in the etherpad
15:31:57 <zhongjun__> +1
15:32:25 <tbarron> gouthamr: did you have other stuff about these two access rule items that you want to bring up?
15:32:32 <gouthamr> good stuff... i see the spec is mostly implemented in the metadata patches, i haven't tested it yet - will do
15:32:58 <gouthamr> the consensus on the spec was that there will be no share manager or driver changes
15:33:42 <gouthamr> tbarron: so this is fine for you i think, please take a look
15:34:17 <tbarron> ok, I hope to get back to these later today
15:34:22 <gouthamr> i.e, *_squash options will not be implemented via the metadata API
15:34:43 <tbarron> ack
15:35:29 <gouthamr> that's all i had.. thanks for the quick turnaround zhongjun__
15:36:07 <tbarron> Anything else on review focus for today?
15:36:09 <zhongjun__> gouthamr: Thank you for review all day
15:36:43 <tbarron> Note that Manila Feature Proposal Freeze is this week so
15:36:55 <gouthamr> tbarron: with the priority for access-rules, i'm not convinced it's doing the right thing with respect to access rule updates
15:37:09 <tbarron> gouthamr: ah, you mentioned that!
15:37:25 <tbarron> pls. explain for the larger group
15:38:09 <gouthamr> i see you can set access rule priority while creating the rules, but you can't update the priority of existing rules and get the share manager to apply them on the backend
15:38:45 <tbarron> so it will *look* like priority has been set but actually no change has been made?
15:39:25 <gouthamr> yes
15:39:42 <zhongjun__> gouthamr: even current code?
15:39:44 <tbarron> that seems more than an incidental issue with the implementation
15:41:02 <gouthamr> zhongjun__: i'll test it today and revert, but i don't know how drivers will react to reapplying existing rules
15:41:51 <tbarron> zhongjun__: gouthamr - ok, let's check this thoroughly, we've had (with benefit of hindsight) a fair amount of
15:41:58 <tbarron> oscillation with access rules
15:42:05 <gouthamr> +1
15:42:08 <tbarron> wishing we had done things differently
15:42:22 <tbarron> so thank you zhongjun__ for taking on this important issue!
15:42:36 <tbarron> and let's review carefully and deliberately!
15:42:48 <zhongjun__> ok
15:43:07 <gouthamr> for some reason that just reminded me of dolores umbridge
15:43:20 <tbarron> OK, as I mentioned, we are at Feature Proposal freeze so I will be looking at blueprints and perhaps retargeting
15:43:22 <ganso> gouthamr: lol
15:43:38 <tbarron> if I think we can't reasonably think the work will get done by M3
15:43:58 <tbarron> if you disagree with anything being pushed out just ping me
15:44:05 <tbarron> and we'll talk
15:44:15 <tbarron> you might have to do an FFE
15:44:34 <tbarron> in any case the issue may be more about reviewer bandwidth than anything else
15:44:43 <tbarron> questions? comments?
15:45:03 <tbarron> I'm talking about regular blueprints atm, not the stuff we speced.
15:45:29 <tbarron> ok, next topic
15:45:46 <tbarron> #topic special casing of API schema validation - gouthamr
15:46:13 <gouthamr> thanks tbarron
15:46:14 <gouthamr> #LINK https://review.openstack.org/#/c/473464/11/manila/api/v2/quota_sets.py@94
15:46:14 <gouthamr> #LINK https://review.openstack.org/#/c/572283/3/manila/api/common.py@406
15:46:14 <gouthamr> #LINK http://eavesdrop.openstack.org/meetings/manila/2017/manila.2017-07-13-15.00.log.txt
15:46:52 <gouthamr> this is a prior discussion, i wanted to bring it back alive because of the two access rules changes
15:47:35 <gouthamr> our APIs aren't perfect and we don't perform strict validation - i.e, many APIs ignore any garbage they don't care about
15:48:16 <gouthamr> every time a new key is added in a new version, we seem to be resorting to special case that and respond with 400 to prior API versions
15:48:42 <gouthamr> we discussed this in the past and agreed that we ought to fix the schema validation for all keys and not special-case it
15:49:16 <gouthamr> for example, 'priority' is allowed on access-rule create for API v 2.46
15:49:31 <gouthamr> but if you use it on API v 2.45, you get BadRequest
15:50:17 <bswartz> There's no argument against the schema validation right?
15:50:21 <tbarron> gouthamr: have you looked at what the proposed json query validation will do for these?
15:50:24 <gouthamr> this also relates to the JSON schema validation change
15:50:24 <bswartz> What is the issue?
15:50:26 <gouthamr> #LINK https://review.openstack.org/#/c/563429/
15:50:35 <gouthamr> yep, so that change does this the right way
15:50:35 <tbarron> jinx
15:50:49 <gouthamr> preserve API behavior and strictly validate from a particular version
15:51:04 <gouthamr> no special casing, you just can't send unrecognized keys
15:52:29 <gouthamr> so i'd like some agreement on this issue, is anyone opposed to this idea? i.e, older APIs will ignore garbage
15:52:38 <gouthamr> newer APIs will strictly validate
15:53:41 <tbarron> by older and newer apis you mean older and newer microversions?
15:53:44 <gouthamr> yes
15:54:13 <gouthamr> JSON schema validation will not all land in one microversion
15:54:20 <gouthamr> we'll have to do it iteratively
15:54:45 <gouthamr> the API ref will reflect that validation is added at a particular microversion and garbage will be ignored
15:54:57 <gouthamr> in the prior versions
15:55:44 <tbarron> but once it is implemented, say in 2.46, then if 2.45 comes in with "priority" and that is junk you'll get BAD REQUEST
15:55:56 <bswartz> For perfect backwards compatibility you kind of have to not do schema validation below some version
15:56:01 <gouthamr> tbarron: no, it will be ignored
15:56:19 <tbarron> gouthamr: I am confused though b/c above you said
15:56:21 <bswartz> But there's not reason not to turn it on across the board at whatever microversion it's introduced at
15:56:37 <gouthamr> bswartz: that code needs to be written though
15:56:58 <tbarron> "but if you use it on API v 2.45, you get BadRequest" - were you
15:57:15 <tbarron> illustrating the kind of thing you object to?
15:57:25 <gouthamr> tbarron: yep, i was talking about the code in flight right now that i have a problem with
15:57:31 <tbarron> gouthamr: ack
15:57:50 <bswartz> Is it so hard to have a universal schema validator?
15:58:12 <gouthamr> tbarron: zhongjun__ referred me to the  earlier (ward cleaver) case where we had a similar discussion at the end of last cycle
15:58:18 <bswartz> All you need is a schema document and a validator that runs when microversion >= X
15:58:55 <gouthamr> bswartz: that is true, https://review.openstack.org/#/c/563429/ proposes the validators and all that
15:59:15 <gouthamr> bswartz: but it only implements it against one API suite: share types
15:59:45 <gouthamr> bswartz: so if we can get the rest between now and M3 deadline, we can do it all in one version
16:00:01 <gouthamr> time check
16:00:02 <tbarron> unlikely
16:00:08 <bswartz> So the challenge is that the schema isn't written down anywhere, and writing it is a lot of work?
16:00:21 <tbarron> let's continue in #openstack-manila
16:00:27 <tbarron> Thanks everyone!
16:00:40 <gouthamr> bswartz: yep, we've not written the schema outside of the api-ref
16:00:45 <gouthamr> yep thanks tbarron
16:00:45 <tbarron> dustins_: we'll talk about share-type-quota test bugs next week!
16:00:56 <dustins_> Sounds good!
16:00:59 <tbarron> #endmeeting