16:00:27 <jungleboyj> #startmeeting cinder 16:00:28 <openstack> Meeting started Wed Dec 19 16:00:27 2018 UTC and is due to finish in 60 minutes. The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:31 <openstack> The meeting name has been set to 'cinder' 16:00:36 <whoami-rajat> Hi 16:00:39 <enriquetaso> o/ 16:00:44 <eharney> hi 16:00:45 <smcginnis> .o. 16:00:46 <jungleboyj> courtesy ping jungleboyj diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr thingee erlon tpsilva ganso patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut lseki _alastor_ whoami-rajat yikun rosmaita enriquetaso 16:00:53 <geguileo> hi! o/ 16:00:55 <jungleboyj> @! 16:00:56 <_pewp_> jungleboyj (¬_¬)ノ 16:00:56 <rosmaita> o/ 16:01:01 <xyang> hi 16:01:01 <LiangFang> o/ 16:01:46 * jungleboyj is leaving one meeting and needs coffee quick. 16:03:16 * jungleboyj is now properly caffinated 16:03:55 <rosmaita> that was quick 16:04:14 <jungleboyj> Yeah, just needed to walk upstairs. :-) 16:04:30 <jungleboyj> Ok, so looks like we have quorum. 16:04:37 * lbragstad walks in late 16:05:21 * jungleboyj welcomes lbragstad We are just getting started 16:05:32 <jungleboyj> #topic announcements 16:05:57 <jungleboyj> Not a lot here at the moment. 16:06:03 <jungleboyj> Well, I guess that isn't true. 16:06:35 <jungleboyj> First, we won't have a meeting on 12/26 as I am guessing a lot of people will be on vacation. I am planning to be. 16:06:44 <jungleboyj> I could host a meeting if people wanted it. 16:06:56 <jungleboyj> Anyone feel a pressing need for that though? 16:07:13 <whoami-rajat> can attend if it will happen. 16:07:43 <jungleboyj> Ok, don't see people begging to have one. 16:08:04 <jungleboyj> So, lets take a break on 12/26 and then return on 1/2/2019. 16:08:30 <whoami-rajat> Sure. 16:08:57 <smcginnis> I'll be out the 24th through the 2nd. Not sure if I'll bring my laptop with me yet, but ping me if needed. 16:08:59 <jungleboyj> I think it will be important to get back together on 1/2 as we will be coming up on milestone 2. 16:09:28 <jungleboyj> Have some drivers to look at and try to get merged. Perhaps. 16:10:12 <jungleboyj> So, that would be my other announcement. For drivers that are trying to get merged that should be our review focus right now. 16:10:47 <e0ne> hi 16:11:11 <jungleboyj> As far as my vacation I am off 12/22 to 1/2/2019 but I will be checking mail and IRC and stuff. Just may be slower responses than usual. 16:12:04 <jungleboyj> smcginnis: Any other comments around all of that? 16:12:21 <smcginnis> Just pay attention to our deadlines for milestone 2. 16:12:34 <jungleboyj> smcginnis: ++ 16:12:44 <smcginnis> Those hoping to get drivers in, make sure code is complete, CI is reporting, and you respond quickly to any review commeents. 16:12:47 <smcginnis> *comments 16:12:55 <jungleboyj> ++ 16:13:04 <jungleboyj> Ok. Moving on. 16:13:14 <smcginnis> For cores, maybe if there are minor issues to address, might be good to accept the driver if all else is good and make sure there are follow ups to fix the minor things. 16:13:36 <jungleboyj> smcginnis: Agreed. If they have their CI running and everything I would agree with that. 16:13:51 <e0ne> smcginnis: I can remove my -2 from Hedvig driver if team is OK to merge it 16:14:40 <eharney> did hedvig ever pass the expected tempest tests? 16:14:47 <jungleboyj> e0ne: So, they have had their CI running and have been responding to comments. 16:14:59 <jungleboyj> eharney: I think they just got the last test case running. 16:15:16 <jungleboyj> eharney: I thought I saw them mention that yesterday. They pinged you too. 16:15:29 <smcginnis> e0ne: If you are OK with their response. 16:15:50 <e0ne> I'm still not happy with logging errors and unit tests 16:16:01 <smcginnis> There was still an issue with shelve, but personally I'm fine with that being skipped for now. 16:16:06 <e0ne> I can -1 on it with a comment 16:16:08 <jungleboyj> e0ne: I need to take a look at their response. It isn't my favorite design. 16:16:15 <e0ne> jungleboyj: +1 16:16:22 <smcginnis> Wouldn't be surprised if the shelve issue is not on their end. 16:16:38 <jungleboyj> e0ne: Is the main concern logging? 16:17:05 <eharney> hmm, they said yesterday that they had to make a fix on their backend to pass test_volume_boot_pattern .... concerning 16:17:20 <eharney> but ok 16:17:54 <smcginnis> I'm sure if we dug into all of the storage backends, there would be a lot considered "concerning". ;) 16:18:11 <jungleboyj> smcginnis: True. 16:18:23 <e0ne> jungleboyj: they don't have unit tests for work with their rest client too 16:18:30 <jungleboyj> To some extent, this is their driver. 16:19:01 <jungleboyj> e0ne: Lets not minus two. 16:19:06 <e0ne> ok 16:19:20 <jungleboyj> Lets keep pushing to get the unit tests in and see where we are at on 1/2 and re-address. 16:19:52 <smcginnis> ++ 16:20:19 <jungleboyj> Cool. The RSD driver is going to be in the same boat. 16:20:50 <e0ne> I changed my vote to -1 16:20:58 <e0ne> feel free to ignore it and +2 :) 16:21:57 <jungleboyj> e0ne: I need to look through it again. 16:22:07 <e0ne> sure 16:22:49 <jungleboyj> Ok. Anything more on that? 16:23:14 <jungleboyj> #topic Issues with Check and Gate jobs failing 16:23:33 <jungleboyj> So, this came up last week. 16:23:58 <jungleboyj> tldr; We have gate jobs that are intermittently failing and making it hard for other projects to merge their code. 16:24:14 <jungleboyj> #link http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000868.html 16:24:50 <smcginnis> Way too many rechecks lately. 16:25:02 <jungleboyj> There was a patch to try and address this that went in middle of last week. It was hoped that adding locking around LVM commands might fix it but that didn't appear to fix things. 16:25:48 <jungleboyj> So, we need to come up with a plan to address the intermittent Cinder failures. 16:26:22 <smcginnis> We did end up switching to setting direct-io on the loopback devices, so we'll see if that makes that issue better. 16:26:25 <smcginnis> The locking did not. 16:26:43 <smcginnis> There are a bunch of other issues tagged as Cinder in elastic recheck. 16:26:46 <smcginnis> #link http://status.openstack.org/elastic-recheck/ 16:27:01 <smcginnis> Anyone with time, feel free to investigate those. 16:27:09 <jungleboyj> smcginnis: Ok. I forgot about the directio change. That is good. Hopefully that will make a difference. 16:27:56 <jungleboyj> Yeah. Argh. eharney is gone. 16:28:14 <jungleboyj> enriquetaso: You are working on Q/A testing with eharney. Right? 16:29:13 <jungleboyj> whoami-rajat: You were working on look through some of the bugs right? 16:29:35 <enriquetaso> jungleboyj:yup, I'm reviwing eric patch's and trying to add more tests 16:29:56 <whoami-rajat> jungleboyj: yes, yikun and i pushed fix for one of the gate issues. 16:30:13 <jungleboyj> Ok. So another way to help is to take a look at gate failures/elastic-recheck bugs. 16:30:18 <jungleboyj> whoami-rajat: Awesome! Thank you! 16:30:19 <whoami-rajat> jungleboyj: i didn't dig deep into the ones listed above. 16:30:47 <jungleboyj> Ok, I think if you are needing guidance focusing on the ones in the elastic-recheck list is the best place to start. 16:30:52 <enriquetaso> I'll not be on PTO next week, so I'll take a look at it jungleboyj 16:31:09 <jungleboyj> enriquetaso: Ok. Cool. Thank you! 16:32:03 <whoami-rajat> jungleboyj: sure, will look at eleastic-recheck's bugs. 16:32:23 <jungleboyj> whoami-rajat: Thank you. Is the patch you are talking about the one at the bottom of this week's agenda? 16:33:02 <whoami-rajat> jungleboyj: no, 16:33:34 <jungleboyj> whoami-rajat: Which patch is the one for the gate issue? 16:33:39 <jungleboyj> We should get review priority to that. 16:33:52 <whoami-rajat> jungleboyj: #link https://bugs.launchpad.net/cinder/+bug/1803648 16:33:53 <openstack> Launchpad bug 1803648 in Cinder "gate failure : testtools.matchers._impl.MismatchError: 'volume.retype' != 'backup.createprogress'" [Undecided,Fix released] - Assigned to Rajat Dhasmana (whoami-rajat) 16:33:53 <whoami-rajat> this one. 16:34:08 <whoami-rajat> jungleboyj: its merged now. 16:34:18 <jungleboyj> whoami-rajat: Ok. Cool. Thank you! 16:34:24 <smcginnis> I thought we merged a fix for that. 16:34:34 <jungleboyj> smcginnis: Yeah, sounds like we did. 16:34:55 <whoami-rajat> smcginnis: yes 16:35:27 <jungleboyj> Ok, so I think we can move on from that. We have raised awareness and have people will to help out there. Thank you. 16:36:12 <jungleboyj> Ok, the next topic has been addressed. 16:36:31 <jungleboyj> #topic review priority gerrit votes: 16:36:33 <jungleboyj> smcginnis: 16:36:43 <smcginnis> OK, so some folks have noticed this already. 16:36:44 <smcginnis> #link http://tiny.cc/CinderPriorities 16:37:16 <smcginnis> Following something that has been working well for designate, I've added a Review-Priority to Gerrit for Cinder projects. 16:37:26 <jungleboyj> Yeah. Nice addition. 16:37:31 <smcginnis> This allows cores to set a priority between -1 to +1. 16:37:57 <smcginnis> -1 will actually block merges, so this is a more specific or clearer way to do a procedural -2. 16:38:07 <enriquetaso> ++ 16:38:14 <lbragstad> huh TIL 16:38:18 <smcginnis> Making it obvious that it's not a code review -2 and that it's just something we want to hold on for now. 16:38:27 <geguileo> smcginnis: cool 16:38:31 <jungleboyj> smcginnis: ++ 16:38:38 <xyang> Is this a Cinder specific thing? 16:38:42 <jungleboyj> Can the -1 be overridden by other reviewers? 16:38:44 <geguileo> smcginnis: it's sticky, not like the workflow flag, right? 16:38:45 <lbragstad> is there a document describing how to set that up? 16:38:49 <smcginnis> It also allows us to set things as High Priority (+2) or just a plain priority (+1) 16:38:58 <smcginnis> jungleboyj: I don't believe so. 16:39:07 <smcginnis> xyang: We copied designate. 16:39:15 <jungleboyj> Ok, so the person who did the -1 will still have to remove it. 16:39:25 <smcginnis> lbragstad: I don't believe so, but if you want to look into it for keystone we can go over the patches to set it up. 16:39:34 <smcginnis> jungleboyj: I believe so. 16:39:38 <lbragstad> ++ 16:39:43 <lbragstad> thanks 16:39:47 <smcginnis> SO this let's us do nice things like the dashboard I linked to above. 16:40:11 <smcginnis> The hope is that in addition to or in place of the spec review tracking etherpad we've had, we can have a nice focused review dashboard for those things. 16:40:32 <jungleboyj> smcginnis: And easier to update / track /etc. 16:40:35 <smcginnis> So cores with limited time to spend reviewing can just go to that dashboard and know what is important to get eyes on. 16:40:40 <jungleboyj> Thank you so much for setting that up. 16:40:45 <smcginnis> No problem. 16:41:30 <smcginnis> jungleboyj: Up to you I guess on how you want to handle setting those, but I was thinking if cores are aware of something that is really important to get in, anyone can set a priority flag to get that marked and hopefully get things through quickly. 16:41:50 <smcginnis> So things like drivers up until the deadline, important features, or even bug fixes. 16:42:08 <jungleboyj> smcginnis: I think all of the cores should contribute there. 16:42:20 <smcginnis> I figure we can try this out for awhile. If it works, great. If it doesn't end up being useful, we can just revert the gerrit ACLs that set this up. 16:42:59 <jungleboyj> Ok. Makes sense to me. 16:43:34 <smcginnis> Unless there's questions, that's all I have on it. Ping me in the channel if there are questions that come up later. 16:43:59 <jungleboyj> smcginnis: That is a great addition. Thank you for the help there. 16:44:20 <smcginnis> I hope it helps get the important things through faster. 16:44:51 <smcginnis> That's all. 16:45:11 <jungleboyj> Cool. 16:45:19 <jungleboyj> Ok. On to our last topic: 16:45:34 <jungleboyj> Follow up on last week's bug: 16:45:38 <jungleboyj> whoami-rajat: 16:45:50 <jungleboyj> #link https://bugs.launchpad.net/python-openstackclient/+bug/1733315 16:45:52 <openstack> Launchpad bug 1733315 in python-openstackclient "cinder-backup - CLI 'VolumeBackupsRestore' object is not iterable" [Undecided,Confirmed] - Assigned to Rajat Dhasmana (whoami-rajat) 16:45:54 <smcginnis> Set topic? 16:46:14 <jungleboyj> #topic Follow up on last week's bug: 16:46:24 <jungleboyj> #link https://review.openstack.org/#/c/624860/ 16:46:49 <jungleboyj> whoami-rajat: Anything particular on this topic? 16:47:00 <enriquetaso> I'm facing the same error... if someone else could try to reproduce the bug It will help me 16:47:08 <whoami-rajat> We've had a discussion last week on the openstack client bug which should be closed or not. It reproduced in my environment and I pushed up a fix for it. Just wanted to bring it up for everyone to take a look if it got missed. 16:47:15 <smcginnis> Nit, but commit summaries should state what is being done, not what the problem is. 16:47:41 <whoami-rajat> smcginnis: ok, will do. Thanks. 16:48:02 <jungleboyj> Yeah, I think that looks ok to me. If you are able to explain the fix there that would be great. 16:48:06 <smcginnis> Not critical, but just for future reference it's best to just say what the patch does. 16:49:02 <whoami-rajat> jungleboyj: ok sure. i explained the details in the launchpad bug. will summarize it in the commit message. 16:49:10 <jungleboyj> whoami-rajat: Cool. 16:49:20 <jungleboyj> Anything else? 16:49:40 <whoami-rajat> smcginnis: ok, i will mind it from next time . 16:50:49 <smcginnis> Sorry, I didn't mean to derail any conversation there. :] 16:51:14 <jungleboyj> No worries. 16:51:21 <jungleboyj> Ok. So that covers the agenda. 16:51:29 <jungleboyj> #topic Open Discussion. 16:51:45 <smcginnis> I did want to mention python version support. 16:52:23 <smcginnis> According to our policy in the past of targeting the LTS releases at the start of a cycle, py35 is no longer our target runtime and we should be focused on 3.6 and getting ready for 3.7. 16:52:48 <smcginnis> Unless I missed it, we still have an issue with 3.7 with one of the Dell EMC drivers through its use of taskflow. 16:53:02 <smcginnis> Probably not critical until train, but still important to be aware of. 16:53:42 <lbragstad> I've noticed that cinder has been working through a bunch of changes that add more robust policy testing - which is great 16:53:46 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:policy_in_code_test 16:54:08 <lbragstad> i wanted to swing by today and see if anyone from the cinder team has questions about the approach that I can answer? 16:54:20 <lbragstad> i know rosmaita and i had a conversation the other day 16:54:50 <smcginnis> Yeah, thanks for your input on those lbragstad. 16:55:02 <smcginnis> Might be good for us to mark those as priority patches. 16:55:05 <lbragstad> yeah - no problem 16:55:13 <jungleboyj> lbragstad: ++ Thank you. 16:55:19 <lbragstad> this is going to be something a lot of other projects are going to have to do too 16:55:36 <lbragstad> so i want to get early feedback on what the complicated parts are from early adopters (cinder being the example here) 16:55:57 <smcginnis> Will be good then having these as examples that those other projects can then follow too. 16:56:34 <jungleboyj> I have set them to high priority. Glad that we have been working on adding those tests. 16:56:36 <lbragstad> ultimately, our goal with better policy testing is to be as simple as possible, so that it's super easy to see who can access the API based on their authorization (e.g., modeling a keystone token) 16:57:11 <smcginnis> I've looked at some of them and just need time to work through the rest. 16:57:13 <lbragstad> the advantage for y'all is that you'll be able to implement things like a read-only role easier by evolving the policies with a higher level of confidence 16:57:16 <smcginnis> So far so good. 16:57:22 <smcginnis> ++ 16:57:57 <jungleboyj> That is good as that has been an area of interest lately. 16:58:14 <rosmaita> i am kind of skeptical of this testing approach, though 16:58:27 <lbragstad> really, instead of having to rely on keystone (thus building functional tests), yikun is using an oslo.context object to represent what keystonemiddleware and oslo.context would parse from a keystone token 16:58:51 <lbragstad> rosmaita what are your reservations? 16:59:49 <rosmaita> i'm having trouble articulating this 17:00:00 <lbragstad> :) 17:00:01 <rosmaita> it seems that if everything is default, it's fine more or less 17:00:17 <rosmaita> but this is an area where it is unlikely you will want the default 17:00:31 <lbragstad> by everything do you mean policies? 17:00:37 <smcginnis> Times up. Let's move to -cinder? 17:00:37 <rosmaita> yes 17:00:43 <lbragstad> alright, meet you there 17:00:44 <rosmaita> sure 17:00:50 <jungleboyj> Sounds good. 17:00:55 <jungleboyj> Thanks everyone for joining. 17:01:01 <smcginnis> Thanks! 17:01:13 <whoami-rajat> Thanks. 17:01:13 <jungleboyj> Have a merry Christmas and Happy New Year! 17:01:21 <jungleboyj> #endmeeting