14:00:48 <rosmaita> #startmeeting cinder 14:00:52 <openstack> Meeting started Wed Dec 16 14:00:48 2020 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:55 <openstack> The meeting name has been set to 'cinder' 14:01:07 <rosmaita> #topic roll call 14:01:18 <michael-mcaleer> hi 14:01:21 <walshh_> hi 14:01:23 <eharney> howdy 14:01:29 <rafaelweingartne> \o 14:01:32 <TusharTgite> hi 14:01:44 <e0ne> hi 14:01:45 <enriquetaso> hi 14:01:54 <jungleboyj> o/ 14:02:07 <tosky> o/ 14:02:50 <felipe_rodrigues> o/ 14:02:51 <rosmaita> ok, let's get started 14:02:54 <rosmaita> hello everyone 14:03:01 <rosmaita> #link https://etherpad.openstack.org/p/cinder-wallaby-meetings 14:03:06 <rosmaita> #topic announcements 14:03:29 <rosmaita> lseki wishes to announce that he has moved to Red Hat 14:03:48 <rosmaita> if you have NetApp questions, the person to contact from now on is sfernand 14:04:17 <sfernand> yep 14:04:18 <rosmaita> deadlines update 14:04:31 <rosmaita> the spec freeze is on Friday this week 14:04:40 <jungleboyj> lseki: Congratulations. 14:04:41 <rosmaita> #link https://releases.openstack.org/wallaby/schedule.html#w-cinder-spec-freeze 14:04:53 <rosmaita> we'll look at some specs later in the meeting 14:05:06 <rosmaita> there will NOT be a cinder meeting on 30 December 14:05:25 <rosmaita> so, next week's meeting on 23 December will be the last meeting of the month, so we will hold it in videoconf 14:05:42 <rosmaita> connection info will be on the agenda etherpad 14:05:49 <michael-mcaleer> I wont be present, ill be on leave already, but I will have the bug report ready for you all to look at 14:05:54 <rosmaita> great, ty 14:06:01 <rosmaita> last announcement: 14:06:03 <jungleboyj> I will be on vacation. :-) 14:06:09 <rosmaita> slacker 14:06:11 <rosmaita> :) 14:06:14 <jungleboyj> Hey now! 14:06:18 <jungleboyj> :-) 14:06:31 <rosmaita> we have one community goal on the verge of completion 14:06:41 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/763917 14:06:54 <rosmaita> please review this patch so we can get it out of the way 14:07:08 <rosmaita> i can't approve it because i am co-author 14:07:20 * jungleboyj will look 14:07:30 <rosmaita> thank you, i withdraw my "slacker" comment 14:07:39 <jungleboyj> :-) 14:07:46 <rosmaita> that's all from me, anyone else have an announcement? 14:07:50 * lseki sneaks in, but also in another meeting 14:08:03 <lseki> jungleboyj: thanks 14:08:12 <rosmaita> #topic New meeting time proposal 14:08:22 <rosmaita> lseki: that's you if you can multitask 14:08:34 <lseki> I'll try 14:08:43 <jungleboyj> :-) Good topic. I have the same problem. 14:08:59 <rosmaita> ok, we used to have the cinder meeting at 1500 UTC 14:09:03 <lseki> so now I have a conflicting daily meeting at 14:00-14:30 UTC 14:09:15 <rosmaita> we moved it to be more friendly to APAC people 14:09:29 <rosmaita> but i haven't seen evidence that it has helped 14:10:08 <rosmaita> so we may have to think of another way to encourage APAC participation 14:10:37 <rosmaita> unfortunately, if we move to 1500 then it conflicts with the horizon meeting 14:10:59 * jungleboyj liked it when it was 1600 :-) 14:11:23 <rosmaita> well, that would solve the horizon problem 14:11:49 <lseki> 1600 works for me as well 14:12:04 <lseki> but might be even worse for APAC folks 14:12:12 <rosmaita> ok, i guess the thing to do is to take a poll 14:12:22 <jungleboyj> Works for me as it moves it out beyond all my APAC meetings. 14:12:38 <rosmaita> which could result in 1300 for all i know 14:12:43 <rosmaita> :D 14:13:11 <rosmaita> ok, to be clear, next week's meeting will be at 1400 UTC as usual 14:13:36 <rosmaita> i'll get a poll out today 14:13:49 <rosmaita> #action rosmaita - poll for meeting time change 14:14:09 <rosmaita> does anyone have any radical change suggestions, like changing the day of week? 14:15:09 <rosmaita> hearing none, i'll go with some conservative suggestions and an open space for suggestions 14:15:26 <jungleboyj> ++ 14:15:45 <lseki> ++ 14:15:51 <e0ne> rosmaita: another day of week works for me 14:16:12 <rosmaita> e0ne: would it be possible to swap time slots with horizon? 14:16:22 <rosmaita> or would that be bad for the horizon team? 14:16:36 <e0ne> rosmaita I need to ask for the team 14:16:46 <e0ne> rosmaita it should not be an issue 14:17:07 <rosmaita> ok, thanks, i definitely don't want to schedule a meeting that has a conflict for you 14:17:24 <rosmaita> #topic bug report 14:17:29 <michael-mcaleer> thanks rosmaita 14:17:37 <michael-mcaleer> we had quite a few opened this week, 11 to be exact 14:17:52 <michael-mcaleer> I will save time by not including the summary here, they are all in the bug report #link https://etherpad.opendev.org/p/cinder-wallaby-r18-bug-review 14:18:13 <michael-mcaleer> if anyone has any comments just reply after I link the bug, I will go through them in the same order as the etherpad 14:18:18 <michael-mcaleer> Cinder bug #1: Target volume type is still in use #link https://bugs.launchpad.net/cinder/+bug/1907157 14:18:22 <openstack> Launchpad bug 1907157 in Cinder "Target volume type is still in use" [Medium,Triaged] 14:18:23 <openstack> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 - Assigned to MFauzilkamil Zainuddin (apogee) 14:18:58 <michael-mcaleer> never mind the second part about ubuntu malaysia, thats my improper formatting 14:19:08 <rosmaita> yeah, that is not cinder's fault 14:19:29 <michael-mcaleer> ok, we were added to it by submitter because they thought we might have some input or suggestions 14:19:59 <rosmaita> i will look 14:20:10 <michael-mcaleer> np 14:20:14 <michael-mcaleer> Cinder bug 2: Attachment update API returns 500 when it should return 400 #link https://bugs.launchpad.net/cinder/+bug/1907295 14:20:16 <openstack> Launchpad bug 1907295 in Cinder "attachment update API returns 500 when it should return 400" [Medium,Triaged] - Assigned to Eric Harney (eharney) 14:20:19 <rosmaita> it may be the image cache 14:20:23 <eharney> i ran into this while chasing a different issue 14:20:35 <eharney> the log basically said "HTTP 500" with no useful context about why 14:20:44 <eharney> i'll either chase it down or just close this if i can't reproduce it 14:21:11 <eharney> (also seems like a bug in itself that we can log HTTP 500 with no info, but that's probably a whole different can of worms) 14:22:49 <michael-mcaleer> np thanks eharney 14:22:54 <michael-mcaleer> Cinder bug 3: py38 ReplicationTestCase unit test failure #link https://bugs.launchpad.net/cinder/+bug/1907672 14:22:57 <openstack> Launchpad bug 1907672 in Cinder "py38 ReplicationTestCase unit test failure" [Low,Triaged] 14:22:58 <openstack> bug 3 in mono (Ubuntu) "Custom information for each translation team" [Undecided,Fix committed] https://launchpad.net/bugs/3 14:23:12 <eharney> this is just a flaky unit test that needs some work 14:23:23 <michael-mcaleer> yeah it looked fairly simple 14:23:37 <michael-mcaleer> Cinder bug_ 4: Cannot set quota for volume type #link https://bugs.launchpad.net/cinder/+bug/1907750 14:23:38 <openstack> Launchpad bug 1907750 in Cinder "Cannot set quota for volume type" [Low,Triaged] - Assigned to haobing1 (haobing1) 14:25:21 <michael-mcaleer> this is limited to cases where second attempt at quota uses explicitly upper case variation of the first volume-type name 14:25:28 <michael-mcaleer> submitter confirmed in a follow up comment 14:26:23 <michael-mcaleer> any insights/comments or will we move on? 14:27:03 <michael-mcaleer> Cinder bug_ 5: cinder-backup does not allow to enable 'fast-diff' feature for backup images stored in ceph #link https://bugs.launchpad.net/cinder/+bug/1907964 14:27:05 <openstack> Launchpad bug 1907964 in Cinder "cinder-backup does not allow to enable 'fast-diff' feature for backup images stored in ceph" [Low,In progress] - Assigned to Christian Rohmann (christian-rohmann) 14:27:10 <rosmaita> the suggestion that when you delete a volume type, all the associated stuff should also be deledte sounds correct 14:27:22 <michael-mcaleer> yeah it is a fair assumption 14:27:39 <michael-mcaleer> if there is no vols associated it should be fine to delete 14:28:34 <eharney> fast-diff looks like an improvement we should investigate for rbd, more a perf enhancement than a bug 14:29:27 <michael-mcaleer> eharney will I change this to importance: wishlist? it is already in progress by user and changes have been proposed 14:29:38 <eharney> makes sense 14:29:57 <michael-mcaleer> no problem, I will reply to submitters latest comment 14:30:15 <michael-mcaleer> Cinder bug_ 6: use md5 to check volume metadata #link https://bugs.launchpad.net/cinder/+bug/1908040 14:30:16 <openstack> Launchpad bug 1908040 in Cinder "use md5 to check volume metadata" [Undecided,Invalid] 14:30:39 <michael-mcaleer> subsequently marked as invalid after response from eharney 14:31:04 <michael-mcaleer> Cinder bug_ 7: "publish_service_capabilities" periodic task blocks cinder-volume #link 14:31:20 <michael-mcaleer> this one may be of higher importance than medium because it references environments at scale issues 14:31:25 <eharney> i just marked this one as a duplicate, it's a known ceph issue that we fixed 14:31:31 <michael-mcaleer> ty 14:32:01 <michael-mcaleer> last cinder bug is a driver one 14:32:06 <michael-mcaleer> Cinder bug_ 8: ibm_storage driver: the "OSvol:" prefix should be optional in the volume name #link https://bugs.launchpad.net/cinder/+bug/1908181 14:32:07 <openstack> Launchpad bug 1908181 in Cinder "ibm_storage driver: the "OSvol:" prefix should be optional in the volume name" [Low,Triaged] 14:32:18 <michael-mcaleer> this is a customer request for a driver change 14:32:30 <michael-mcaleer> it has been tagged correctly so hopefully IBM driver team see it and pick it up 14:32:32 <rosmaita> anyone from ibm here? 14:33:12 <rosmaita> well, hopefully they are watching launchpad 14:33:20 <rosmaita> ok, thanks, michael-mcaleer 14:33:34 <michael-mcaleer> os-brick next 14:33:35 <rosmaita> #topic specs 14:33:38 <rosmaita> oops 14:33:40 <michael-mcaleer> haha 14:33:44 <rosmaita> #topic bugs continued 14:33:45 <michael-mcaleer> pulled the trigger a bit quick 14:33:54 <michael-mcaleer> only three left, one is a duplicate 14:33:59 <michael-mcaleer> os-brick bug_ 1: Evacuation results in multipath residue when use fc #link https://bugs.launchpad.net/os-brick/+bug/1906768 14:34:01 <openstack> Launchpad bug 1906768 in os-brick "Evacuation results in multipath residue when use fc" [Undecided,New] 14:34:10 <michael-mcaleer> and this one is a duplicate of the first ... 14:34:11 <michael-mcaleer> os-brick bug_ 2: fibre channel driver can not disconnet volume when VM to be evacuated #link https://bugs.launchpad.net/os-brick/+bug/1907442 14:34:13 <openstack> Launchpad bug 1907442 in os-brick " fibre channel driver can not disconnet volume when VM to be evacuated" [Undecided,Invalid] 14:34:15 <eharney> pretty sure a lot of multipath fixes made it back to queens 14:34:20 <eharney> the answer is probably: upgrade from pike :/ 14:34:58 <michael-mcaleer> should the same be relayed to the submitter? 14:35:28 <rosmaita> i'll leave a note 14:35:34 <michael-mcaleer> ty rosmaita 14:35:38 <rosmaita> pike is EOL 14:35:46 <michael-mcaleer> and the last bug for this week... 14:35:47 <michael-mcaleer> python-cinderclient bug_ 1: backup delete fail #link https://bugs.launchpad.net/python-cinderclient/+bug/1907542 14:35:50 <openstack> Launchpad bug 1907542 in python-cinderclient "backup delete fail" [Low,Triaged] - Assigned to FengJiankui (fengjiankui) 14:36:45 <enriquetaso> mmm 14:36:45 <eharney> seems unlikely to be a client bug 14:37:14 <michael-mcaleer> are you thinking more cinder? 14:37:44 <e0ne> it sounds like and API bug 14:37:52 <eharney> yeah but unless we have a backup-delete cascade option (i think we don't?) it's probably not actually a bug 14:38:12 <eharney> don't users have to delete dependent backups first? 14:38:24 <eharney> i forget 14:38:52 <rosmaita> yes, but the issue is that it's reporting that there isn't a dependent backup 14:38:53 <michael-mcaleer> from my own work with our own driver yes that was my experience 14:38:58 <rosmaita> when there is one in error state 14:39:11 <michael-mcaleer> yeah the CLI output should say has_dependent_backups = True 14:39:29 <eharney> i'm not sure it should say True if the second backup failed 14:40:03 <rosmaita> probably not, but you need to be able to find the failed backup somehow 14:40:08 <eharney> right 14:40:22 <michael-mcaleer> the failed backup is still linked to the backup, albeit just in namespace because it failed 14:40:44 <michael-mcaleer> would has_failed_backups be more suitable? 14:40:53 <eharney> no 14:41:24 <eharney> we could have the delete failure message list the id of the second backup 14:42:09 <eharney> also should probably have a backup-delete --cascade option like we do for volume snaps to make this easier 14:42:32 <rosmaita> or auto-delete dependents that are in error state? 14:42:39 <rosmaita> but i agree that --cascade would be useful 14:42:53 <eharney> that could work too 14:43:30 <rosmaita> well, it looks like FengJiankui wants to work on it 14:43:40 <rosmaita> i'll leave a note for him on the bug 14:43:50 <michael-mcaleer> thats all from me this week, thanks everyone for the input 14:43:57 <rosmaita> if he can't make the meeting, mabye we can discuss on the ML 14:44:02 <rosmaita> thanks michael-mcaleer 14:44:09 <rosmaita> #topic specs 14:44:28 <rosmaita> anyone here with questions about their spec proposal?/ 14:45:37 <rosmaita> i think i've left comment on everything but https://review.opendev.org/c/openstack/cinder-specs/+/764628 14:46:53 <eharney> i vaguely remember discussing this glance ceph optimization years ago 14:47:23 <eharney> it's something we should look into, not sure if it needs a full spec process or not 14:48:54 <rosmaita> i guess a launchpad BP will do as a driver optimization 14:49:20 <rosmaita> thanks eric 14:49:40 <eharney> the proposal is basically: we currently optimize image->volume in situations where we can with ceph -- so do it in the other direction too 14:51:44 <rosmaita> well, if no one here has questions about their specs, we can move on 14:52:07 <rosmaita> just cinder-cores, please review specs so they can meet the freeze deadline 14:52:14 <rosmaita> #topic open discussion 14:53:11 <eharney> someone added a line about mypy? 14:53:15 <michael-mcaleer> yeah that was my 14:53:17 <michael-mcaleer> me* 14:53:51 <michael-mcaleer> I started to look at some of the code submissions for myPy from walshh_ and although it is straight forward there is still some questions on how to properly review it 14:54:18 <eharney> well 14:54:20 <michael-mcaleer> things like when/when not to use myPy type settings, etc., its difficult because there is no reference correct way that things should be done 14:54:30 <eharney> running "tox -e mypy" and reading the html report will basically tell you if it's working 14:54:44 <eharney> type settings? 14:55:22 <michael-mcaleer> even at that, the uploaded patchset runs cleanly with mypy but I could see some methods where types are defined but others are not in different files and couldnt discern the difference why one function had them and another did not 14:55:48 <michael-mcaleer> type settings = wha the type is set to for input/return parameters for each function 14:55:51 <michael-mcaleer> what* 14:56:01 <eharney> yes, this is the sticking point for most reviewers i think -- trying to determine the goal for coverage to consider it good enough to merge 14:56:31 <michael-mcaleer> ok, makes sense, I was incorrectly under assumption it was full coverage but wasn't sure 14:56:53 <eharney> some people have been leaning that way, but i still question if that makes sense at the beginning of this 14:57:29 <michael-mcaleer> it's a lot of work to hit 100% coverage from what ive seen in the few submissions in already 14:57:50 <michael-mcaleer> not complicated changes, just a lot of them 14:57:52 <eharney> the problem is, even if you hit 100% coverage in a file, it won't actually be fully covered unless you also hit that in every file it imports etc 14:58:21 <eharney> so, we could do that, but i'm still not convinced it's the most efficient use of effort 14:59:22 <michael-mcaleer> no problem, that gives me a bit more direction with reviews for now anyway, I will wait for core reviewer comments to see if there is a consistent set of 'guidelines' or 'best practices' for this work 14:59:30 <rosmaita> let's discuss this in video next week 14:59:36 <michael-mcaleer> thanks eharney 14:59:37 <rosmaita> will be a bit easier to hash it out 14:59:50 <rosmaita> ok, we need to make room for horizon 14:59:53 <rosmaita> thanks for attending 14:59:55 * eharney is out of the office next week 14:59:57 <e0ne> rosmaita: thanks ;) 15:00:01 <rosmaita> please review specs! 15:00:13 <rosmaita> #endmeeting cinder