14:00:18 <rosmaita> #startmeeting cinder
14:00:19 <openstack> Meeting started Wed Aug  5 14:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'cinder'
14:00:29 <tosky> o/
14:00:30 <e0ne> рш
14:00:32 <e0ne> hi
14:00:33 <eharney> hi
14:00:35 <kaisers> o/
14:00:36 <rajinir> hi
14:00:36 <LiangFang> o/
14:00:39 <whoami-rajat> Hi
14:00:42 <walshh_> hi
14:00:48 <rambo_li> o/
14:01:01 <rosmaita> good turnout
14:01:05 <rosmaita> #link https://etherpad.openstack.org/p/cinder-victoria-meetings
14:01:28 <rosmaita> not much on the agenda today, so i'll wait another minute for stragglers
14:01:56 <lseki> o/
14:02:35 <geguileo> hi! o/
14:02:35 <rosmaita> ok, guess that's everybody
14:02:42 <enriquetaso> hi
14:02:45 <rosmaita> ok, *now* that's everybody
14:02:48 <enriquetaso> :)
14:02:57 <rosmaita> #topic updates - virtual mid-cycle
14:03:26 <rosmaita> it's next week on Wednesday at this time, so we won't have a team meeting
14:03:36 <rosmaita> actually, we will, it will just be the midcycle
14:03:52 <rosmaita> anyway: 12 August 2020 14:00-1600 UTC
14:04:16 <rosmaita> we'll do it in bluejeans, connection info is in the email
14:04:26 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016289.html
14:04:44 <rosmaita> don't forget to add topics to the etherpad
14:05:08 <rosmaita> #link https://etherpad.opendev.org/p/cinder-victoria-mid-cycles
14:05:40 <rosmaita> #topic updates - monthly video weekly meeting survey
14:06:02 <rosmaita> everyone who took the survey said we should to a video meeting again
14:06:12 <rosmaita> all 4 of them
14:06:27 <rosmaita> so our last meeting of August will be video + IRC again
14:06:39 <rosmaita> #topic updates - gate excitement
14:06:58 <rosmaita> you may have noticed that the gates were flakey earlier this week
14:07:05 <rosmaita> i believe they are back to normal now
14:07:24 <rosmaita> smcginnis put up a patch that got the cinder gate moving for a while
14:07:36 <rosmaita> and then a longer-term fix was found
14:07:50 <rosmaita> for the lower-constraints job failure
14:07:54 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016295.html
14:08:04 <rosmaita> and, grenade was blowing up in stable/ussuri
14:08:11 <rosmaita> looks like that is fixed now too
14:08:21 <rosmaita> #link https://review.opendev.org/#/c/744753/
14:08:38 <rosmaita> hopefully that will be all the excitement for this week
14:08:55 <rosmaita> that's all from me -- anyone have any news they'd like to share?
14:09:55 <rosmaita> #topic Release notes for bugs
14:10:02 <rosmaita> geguileo: that's you
14:10:09 <geguileo> thanks
14:10:28 <geguileo> we tend to add bug numbers in the release notes
14:10:32 <geguileo> but not always
14:10:53 <geguileo> and some of us just add the number, and others also add the link to the LP bug
14:11:12 <geguileo> I think we should reach a consensus on what we want to have
14:11:17 <geguileo> for consistency purposes
14:11:21 <e0ne> IMO, link to launchpad and some brief description will be great
14:11:31 <rosmaita> i agree
14:11:45 <geguileo> ok, whoami-rajat pointed it out in some of his reviews
14:11:45 <tosky> would it make sense to see if reno could parse and expand the launchpad link automatically from a keyword like lpnnnnn ?
14:11:53 <tosky> (maybe it's already there)
14:12:07 <geguileo> tosky: oh, if that existed it would be great
14:12:28 <rosmaita> i don't think it's already there, but it's a good idea
14:12:29 <geguileo> but in the meantime I think we kind of agree that having the link is what we want
14:12:36 <rosmaita> but for now, let's do it by hand
14:12:37 <whoami-rajat> geguileo, yep, rosmaita pointed that out in my reviews and I've been using that since :)
14:12:46 <eharney> that may get messy if it's a bug on multiple projects
14:12:58 <geguileo> ok, then I think we can start doing that and mentioning it in the reviews
14:13:24 <geguileo> I think we have a reno page in our docs
14:13:35 <geguileo> if we do, I'll mention this resolution there
14:13:44 <rosmaita> sounds good
14:13:48 <rosmaita> while we are on this topic
14:13:48 <geguileo> ok
14:14:23 <rosmaita> i try to point this out in reviews, but it would be good for driver change renos to begin with the driver name
14:14:34 <rosmaita> would make it easier for operators to find it
14:14:41 <rosmaita> something like
14:14:53 <rosmaita> Foo driver: fixed the bar in the baz.
14:15:10 <geguileo> sounds good
14:15:20 <geguileo> and we could do that in the first line of commit messages as well
14:15:21 <rosmaita> or Foo driver: `Bug #1234 <http...>`_: fixed the bar in the baz
14:15:22 <openstack> bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234 - Assigned to Daniel Henrique Debonzi (debonzi)
14:15:32 <whoami-rajat> makes sense
14:15:51 <rosmaita> well at least bug 1234 is fixed
14:15:59 <whoami-rajat> :D
14:16:01 <geguileo> lol
14:16:04 <lseki> lol
14:16:14 <rosmaita> ok, that will really improve the release notes
14:16:17 <rosmaita> thanks, geguileo
14:16:23 <rosmaita> any other observations?
14:16:35 <geguileo> I'll propose a format in the patch and we can decide how we exactly want it
14:16:40 <geguileo> thanks everyone :-)
14:16:43 <rosmaita> excellent
14:17:11 <rosmaita> #topic what to return when a request fails because the default volume type doesn't exist
14:17:20 <e0ne> not a 500 :)
14:17:22 <rosmaita> this is something whoami-rajat is working on now
14:17:36 <rosmaita> i think this is a legitimate 500 though
14:17:43 <rosmaita> it's a server side mis-configuration
14:17:44 <whoami-rajat> specifically create volume request fails
14:18:00 <eharney> 500 sounds right for that case
14:18:01 <rosmaita> or anything that needs to access the default volume type
14:18:20 <rosmaita> the situation is that we are now requiring the default_volume_type to be set
14:18:25 <rosmaita> but if the operator has a typo
14:18:30 <rosmaita> then it can't be found
14:18:40 <rosmaita> and since we don't allow untyped volumes since traing
14:18:42 <rosmaita> *train
14:18:47 <rosmaita> we fail the request
14:18:56 <e0ne> we've got InvalidConfigurationValue, 400 (https://github.com/openstack/cinder/blob/master/cinder/exception.py#L249)
14:19:35 <e0ne> but 400 doesn't looks good too:(
14:19:40 <eharney> 400 indicates that the problem is with the request from the user, which doesn't fit this
14:20:01 <e0ne> eharney: +1. that's why I don't like this option
14:20:17 <rosmaita> i guess you could stretch things and say if the user calls the admin and complains before making the next request, that's a 400
14:20:55 <rosmaita> but it really seems it's a server-side thing
14:21:02 <e0ne> rosmaita: +1
14:21:23 <rosmaita> hopefully it won't happen a lot
14:21:25 <e0ne> I don't like 500 errors but I can't propose a good enough solution :(
14:21:34 <whoami-rajat> providing a wrong volume type in request is good for a 400 but sadly returns 404
14:21:42 <whoami-rajat> here 500 makes sense to me as well
14:22:03 <rosmaita> no, if the requestor makes a mistake, should be 4xx
14:22:31 <rosmaita> because they can fix the request
14:23:22 <whoami-rajat> yep, that was a different topic, just using that to explain why 500 makes sense here
14:23:33 <rosmaita> ok, i misunderstood
14:23:47 <rosmaita> ok, looks like there's support for this to be a 500 ?
14:23:57 <eharney> yes
14:23:59 <whoami-rajat> +1
14:24:35 <rosmaita> ok, well hopefully operators will be careful in their configuration and won't see this very often
14:25:15 <rosmaita> #topic Support volume re-image
14:25:25 <rosmaita> #link https://review.opendev.org/#/c/606346/
14:25:29 <rosmaita> rambo_li: that's you
14:25:40 <rambo_li> yes
14:26:09 <rosmaita> this is a blast from the past
14:26:47 <rambo_li> yeah
14:26:57 <rambo_li> but the nova rebuild is need this
14:28:49 <rambo_li> I well hopefully this reimage api will merged in Victoria
14:30:11 <rosmaita> i don't think anyone is philosophically opposed to this, so it's mostly a matter of getting reviews
14:31:06 <rosmaita> we should probably add some tests to cinder-tempest-plugin to verify the functionality
14:31:44 <eharney> i am still skeptical about allowing the reimage operation on volumes with status "error"
14:32:00 <rosmaita> that does seem a bit odd
14:32:08 <eharney> i think it will just not work in many cases
14:34:18 <rambo_li> eharney: the volume status is "error" means the volume data is bad, so we can reimage this, any problem?
14:35:07 <eharney> it could mean many different things, including, there isn't actually a volume
14:35:50 <eharney> "error" indicating anything about the data on the volume is probably the rare case
14:36:05 <rosmaita> rambo_li: what's the status of the nova side of this?
14:37:50 <rambo_li> the volume is reserved
14:38:05 <rambo_li> when do the rebuild action
14:38:13 <rosmaita> ok, let's discuss this more at the midcycle next week
14:38:31 <rosmaita> i don't remember that stein spec at all and need to read through it
14:38:41 <rosmaita> and also the comments on the nova spec
14:38:51 <rosmaita> #link https://review.opendev.org/#/c/739349/11
14:39:26 <rosmaita> anything else?
14:40:17 <rosmaita> #topic generic NFS online extend
14:40:18 * jungleboyj sneaks in late.
14:40:22 <rosmaita> lseki: you're up
14:40:24 <lseki> o/
14:41:04 <lseki> so, currently generic NFS fails to extend an attached volume
14:41:28 <lseki> and I'm working on a fix that lets Nova do the actual extend operation
14:41:49 <lseki> the problem is: what if nova fails to do this extend operation
14:42:12 <lseki> the volume would remain with the original size, but the volume size would get inconsistent in Cinder DB
14:42:50 <lseki> Lee Yarwood from Nova proj told that Nova creates an action
14:42:54 <lseki> #link https://github.com/openstack/nova/blob/49c3ac7dfa7aca5504f9d19958ff82a40e47f5a1/nova/compute/api.py#L5316-L5323
14:43:14 <lseki> which Cinder could poll for, to check if it succeeded or not
14:43:37 <lseki> I'm not familiar with polling Nova things from Cinder
14:43:59 <lseki> so I'd like to know if there's a similar code that I could take as an example
14:44:09 <smcginnis> We generally don't. We don't want to have tight coupling with Nova, as much as possible.
14:44:11 <eharney> i'm not sure that cinder currently has any code that consumes events from nova
14:45:21 <eharney> we do have code to trigger events there in the other direction, presumably doing this would use a similar infrastructure
14:47:55 <whoami-rajat> i think we do some sort of polling for snapshot of attached volumes?
14:48:17 <eharney> in that case, nova updates a value that cinder can see in the db, we don't have to poll nova
14:49:23 <rosmaita> can we do the same thing here?
14:49:30 <rosmaita> i am not familiar with that code
14:50:07 <eharney> we shouldn't copy the way the snapshot update happens, because it's a hacky mess
14:50:17 <eharney> would probably be easier to just the nova events API
14:50:47 <rosmaita> ok, i am anti-hacky-mess
14:51:43 <whoami-rajat> https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/remotefs.py#L1677-L1721
14:52:19 <eharney> in this case, what is it we're waiting for nova to do exactly?
14:52:20 <whoami-rajat> but as Eric said, we should do the it optimally
14:53:19 <eharney> i guess libvirt is just extending the file
14:53:39 <LiangFang> lseki: could we let cinder give nova a callback, when nova finished, it call callback, and the cinder update DB? need to let nova handle callback
14:55:32 <lseki> hmm do Cinder & Nova have such callback mechanism?
14:55:43 <whoami-rajat> eharney, waiting for the blockRebase or blockCommit to complete? i think it updates a field in snapshot (progress) to 90 when it completes
14:55:55 <eharney> whoami-rajat: that's for snapshots, not for extend
14:56:18 <whoami-rajat> eharney, oh, i thought you asked for snapshots case, my bad
14:56:33 <rosmaita> lseki: can you map out how you see this working on an etherpad or something, and we can discuss more next week?  (you can send something to the ML when your etherpad is up, and we can look earlier and all be ready for a discussion)
14:56:55 <eharney> please test whether this works with encryption and whether it works with volumes attached to instances that are shutoff
14:56:56 <rosmaita> sounds like on the nova side, lyarwood at least is in favor of polling the server actions API
14:57:01 <eharney> iirc the encryption case is already known to have problems
14:57:27 <lseki> rosmaita: sure, I will write the alternatives
14:57:30 <rosmaita> lseki: the extend is initiated from the cinder side, is that correct?
14:58:11 <rosmaita> so we could reject unsupported configurations
14:58:48 <lseki> rosmaita: correct
14:59:02 <rosmaita> ok, that sounds good
14:59:16 <rosmaita> sorry everyone, looks like we are out of time for open discussion
14:59:30 <whoami-rajat> thanks!
14:59:31 <rosmaita> feel free to talk in #openstack-cinder if you have something on your mind
14:59:32 <LiangFang> I rememer resize is initiate from Nova, extend volume is initiate from cinder
14:59:48 <lseki> ty folks!
14:59:53 <rosmaita> #endmeeting