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