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