14:00:06 <jbernard> #startmeeting cinder
14:00:06 <opendevmeet> Meeting started Wed Sep  4 14:00:06 2024 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:06 <opendevmeet> The meeting name has been set to 'cinder'
14:00:10 <jbernard> #topic roll call
14:00:33 <rosmaita> o/
14:00:44 <whoami-rajat_> hi
14:00:52 <jhorstmann> o/
14:02:22 <akawai> o/
14:02:32 <rosmaita> whoami-rajat: thanks for fixing that pep8 issue
14:03:10 <whoami-rajat> rosmaita, np, it was really strange it started breaking in gate, i think maybe we bumped some requirement that caused it
14:03:57 <jbernard> #link https://etherpad.opendev.org/p/cinder-dalmatian-meetings
14:04:47 <jungleboyj> o/
14:05:17 <bryanneumann> o/
14:05:29 <jbernard> hello everyone
14:05:36 <jbernard> thin adgenda for today :)
14:06:22 <jbernard> so, technically feature freeze was last week
14:06:38 <jbernard> there still one or two that we would like to land
14:06:54 <jbernard> #link https://etherpad.opendev.org/p/cinder-dalmatian-reviews
14:07:20 <jbernard> we were able to get get to all of patches on the list in some capacity
14:07:28 <jbernard> not all were merged, some were moved to post-release
14:07:53 <jbernard> but overall, I think we got the majority of what was needed
14:08:06 <jbernard> which is pretty good considering our review bandwidth
14:08:33 <jbernard> thank you to everyone that both reviewed patches and reponded to review notes to help get patches in
14:10:32 <jbernard> the patches that haven't yet landed are at the top of the list for unfreeze
14:10:46 <jbernard> im working on hightlights for the release team this week
14:11:55 <jbernard> that's about all ive got for today
14:12:03 <jbernard> ill open things up for discussion
14:12:10 <jbernard> #topic open discussion
14:12:30 <eharney> i have a question about an API patch i have up
14:12:35 <eharney> https://review.opendev.org/c/openstack/cinder/+/926914  <- does this need a microversion change?
14:16:05 <jbernard> eharney: would a newer client fail against a service that didn't have this patch?
14:16:21 <eharney> no
14:16:58 <jbernard> maybe you're thinking the same thing then, maybe a microversion is needed?
14:17:06 <jbernard> s/is/isn't
14:17:26 <jbernard> whoami-rajat: ^ curious your thoughts
14:17:58 <eharney> some requests that would previously fail will now be accepted which technically meets the requirements we document for needing a microversion, i think
14:18:04 <eharney> whether this matters in this instance is less obvious
14:19:55 <jbernard> i dont think it costs us anything to bump it, maybe it's better to be safe
14:20:44 <eharney> the cost is forever maintaining two different paths down the api parameter validation code :)
14:21:19 <jbernard> fair
14:22:55 <jbernard> i need to re-read our requirements doc to have a more informed opinion
14:23:03 <whoami-rajat> so we are relaxing the request for snapshot description to accept more characters, specifically newline
14:23:18 <whoami-rajat> we are also removing the character restriction i see which was previously 'minLength': 0, 'maxLength': 255
14:23:45 <whoami-rajat> ideally it should require MV bump but it seems overkill for a change like this ...
14:23:57 <eharney> the length restrictions don't change
14:24:14 <tosky> just remember that any tempest tests for that feature (I've seen a WIP) will apply to all releases, so the tests may need a flag (unless this is a fix and it is backported to all active branches :)
14:25:45 <eharney> good point
14:27:19 <whoami-rajat> i see, the validation is done by _validate_description_non_mandatory_remove_white_spaces and it is consistent with what volume schemas for description does
14:29:55 <whoami-rajat> the QA team has been strict about MVs and have blocked some of my past changes for similar reasons, on the other hand this one is a low impact change so we can let it slide, not sure TBH
14:30:34 <eharney> i'll just go with the microversion plan, i think
14:31:30 <eharney> there is some other weirdness about differences in volumes/snapshots name fields, but i'm a lot more suspicious about adding support for newlines in names
14:32:04 <eharney> (which is currently allowed for volumes)
14:37:22 <jbernard> anything else?  Else we can all get back to things
14:37:26 <jhorstmann> I am currently looking for feedback on my idea for a cinder driver providing local storage by transparently migrating data using the device mapper clone target.
14:37:28 <jhorstmann> I reached out on openstack-discuss, but got no response so far (https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/DYCKN6KEIRMM34SMKHWQU6HSJD3URMFN)
14:37:30 <jhorstmann> Is this something which could be interesting for upstream?
14:38:52 <jbernard> jhorstmann: that's an interesting idea, sorry I missed it
14:39:28 <jbernard> jhorstmann: ill try to get a response to you
14:39:32 <jbernard> jhorstmann: on the list
14:39:51 <jhorstmann> no worries, that's why I am asking again :)
14:40:05 <jhorstmann> thank you
14:40:46 <mhen> before everyone leaves just a small thing
14:40:52 <jbernard> sure
14:40:59 <mhen> regarding the new image encryption standardization
14:41:13 <mhen> we got a new comment on the glance patchset https://review.opendev.org/c/openstack/glance/+/926295
14:41:18 <whoami-rajat> jhorstmann, I haven't read the full email but will it be able to provide all the required functionalities needed for a cinder driver? https://docs.openstack.org/cinder/latest/reference/support-matrix.html#required-driver-functions
14:41:32 <mhen> that will also influence the cinder patchset https://review.opendev.org/c/openstack/cinder/+/926298
14:41:54 <mhen> there is some discussion necessary regarding introduction of a new container_format or disk_format for images
14:42:14 <mhen> if you can please participate in the popup meeting on monday https://meetings.opendev.org/#Image_Encryption_Popup-Team_Meeting
14:42:32 <mhen> it didn't happen this week but will likely next week
14:43:05 <rosmaita> mhen: ack
14:44:09 <mhen> thanks
14:44:14 <whoami-rajat> mhen, so the luks inspector Dan has proposed would likely fail your changes with image_format as luks since both mean different things?
14:44:23 <jhorstmann> whoami-rajat: I have read that list and I have to admit that I currently do not have a solution for everything. Especially how to handle snapshots will be tricky. I wanted to present the general idea and see if there is interested first
14:45:51 <whoami-rajat> jhorstmann, ah ok, i should've read the full email, it mentions this, so i didn't want you to put too many efforts and eventually end up in a condition where we won't accept the driver hence wanted to highlight we've a list of required features
14:46:00 <whoami-rajat> we can surely discuss this at the PTG
14:46:18 <whoami-rajat> i think if we don't have the required features, the tempest test will start failing for that particular driver
14:46:36 <whoami-rajat> which we can maybe skip in the driver CI (yes, we will need to add a new CI for it)
14:46:51 <whoami-rajat> but we can discuss these details during PTG
14:47:59 <mhen> whoami-rajat: likely; due to the request from glance we avoided changing container_format or disk_format for encrypted images until now and handled this purely via special metadata properties but it seems that we will want to introduce new container_ or disk_format values after all to better represent those images and make them more clearly identifiable by the inspector
14:48:17 <jhorstmann> whoami-rajat: so far I can check volume CRD, attach/detach (though not while volumes are still being copied). currently working on host assisted volume migration, which should be possible
14:49:01 <whoami-rajat> mhen, ok, understood, yeah the CVE was a big pain hence i understand Dan's concern of us not repeating similar mistake again
14:50:26 <jhorstmann> whoami-rajat: discussion at the PTG sounds good
14:50:48 <jbernard> jhorstmann: that's a perfect venue for a topic like this, looking forward to it
14:51:15 <whoami-rajat> jhorstmann, thanks for proposing the idea, would appreciate your notes on setting it up :)
14:52:21 <whoami-rajat> host assisted migration shouldn't require much from driver side since most of the work is handled by cinder only
14:52:52 <whoami-rajat> but good to test the workflow
14:53:17 <jhorstmann> whoami-rajat: there is a brief instruction on setup hidden in footnote [4] of the email
14:55:29 <whoami-rajat> jhorstmann, got it, looks straightforward, thanks
14:57:55 <jbernard> ok, last call
14:58:16 <jhorstmann> jbernard, whoami-rajat: please note that there is a bug in the driver version linked in the mail leading to volumes being attached read-only, because I forgot to move 'access_mode' metadata
14:58:57 <jbernard> jhorstmann: do you have a link to a version that includes a fix for this?
15:00:59 <jhorstmann> jbernard: I will provide one as a reply to my original mail, okay?
15:01:41 <jbernard> jhorstmann: perfect
15:01:47 <jbernard> ok, thank you everone
15:01:52 <jbernard> #endmeeting