14:01:36 <jbernard> #startmeeting cinder
14:01:36 <opendevmeet> Meeting started Wed Feb 19 14:01:36 2025 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:36 <opendevmeet> The meeting name has been set to 'cinder'
14:01:42 <jbernard> #topic roll call
14:01:44 <jbernard> o/
14:01:47 <sfernand> hi
14:01:50 <whoami-rajat> hi
14:01:51 <Luzi> o/
14:01:58 <mhen> o/
14:02:01 <jbernard> #link https://etherpad.opendev.org/p/cinder-epoxy-meetings
14:02:03 <abishop> o/
14:02:11 <msaravan> hi
14:04:16 <jbernard> we'll get started in  a couple of minutes
14:05:07 <Sai> o/
14:05:14 <rosmaita> o/
14:05:18 <tosky> o/
14:07:02 <yuval_> o/
14:10:01 <jbernard> ok, welcome everyone
14:10:25 <jbernard> sorry for the delay, today is another snow day so schools are closed where i live
14:11:12 <jbernard> lets see
14:11:16 <jbernard> #topic annoucements
14:12:04 <jbernard> i need to register for the ptg
14:12:31 <jbernard> and if you plan to attend, it looks like the registration link is here
14:12:34 <jbernard> #link http://ptg.openinfra.dev/
14:13:26 <jbernard> client library release (final) is this week
14:13:39 <jbernard> this is os-brick for us
14:14:47 <jbernard> #topic image encryption
14:15:02 <jbernard> ^ i have tested this locally and it all seems to work for me
14:15:11 <rosmaita> \o/
14:15:12 <Luzi> yay
14:15:20 <mhen> nice, thank you for testing
14:15:21 <jbernard> i have notest that I need to transcribe into the review
14:15:43 <mhen> we primarily tested rbd (Ceph) and (iirc) lvm backends using DevStack
14:15:47 <mhen> a bunch of other storage backends are failing in the patchset's Zuul pipeline (StorPool, HPE etc.)
14:15:54 <jbernard> but the weather/school-closings have been quite the ordeal in recent weeks
14:16:16 <jbernard> mhen: are the failings related to the changes? (i haven't looked at those yet)
14:16:23 <mhen> sadly, we neither have the necessary expertise nor available resources to evaluate and test integration with those proprietary storage systems ourselves
14:16:35 <mhen> as a result, we cannot easily discern from the logs if the failures are our fault and need to be addressed in a patchset or not
14:16:48 <jbernard> hmm
14:17:11 <mhen> some log links also 404
14:17:25 <mhen> (for IBM)
14:17:57 <jbernard> do you know the set of failing 3rd party CIs?
14:18:23 <whoami-rajat> it would be good to see if those failures are similar in other patches, if yes then probably unrelated
14:18:44 <jbernard> we need to get that sorted before we could potentially merge
14:18:47 <whoami-rajat> also are they failing consistently with every recheck or they passed as well?
14:19:45 <jbernard> mhen: im can help track down folks to get input of specific failures
14:21:11 <mhen> so, would it be valid to trigger the Zuul build a few times in succession and note down repeatedly failing backends?
14:21:53 <mhen> ... and then trying to get in touch with folks responsible for them (through you jbernard) specifically?
14:22:43 <jbernard> that was my thought too, if we have current results I can use those to reach out to folks
14:22:50 <whoami-rajat> should be visible from older history but if there have been major changes in patchsets then we can retrigger it
14:23:10 <whoami-rajat> i see other third party CIs passing so probably failures are not related to your patch
14:23:23 <whoami-rajat> also do we know if we run encryption tests in third party CIs?
14:23:39 <whoami-rajat> IIUC this change will only affect encryption workflow
14:24:00 <rosmaita> third party CIs are supposed to run the encryption tests
14:24:16 <rosmaita> they can use the fixed-key setup if they don't want to run barbican in their ci
14:24:16 <jbernard> i think it's up to the vendor to configure the exact subset of tests to run, im assuming it would/could differ from vendor to vendor
14:24:57 <mhen> does Zuul make a rebase itself before testing or would it be advisable to rebase the patchset every once in a while to incorporate potential fixes that might have landed on main in the meantime?
14:25:05 <jbernard> i could be wrong then, if the logs are present, we should be able to tell
14:26:57 <jbernard> in general though, i think we need two things:
14:27:08 <jbernard> 1. verify the chagnes are not effecting other drivers
14:27:24 <jbernard> 2. at least 1 other reviewer is needed
14:27:34 <whoami-rajat> hitachi and nec CI are running some encryption tests
14:27:44 <whoami-rajat> nec: https://cinder-cilogs.openstack.nec-solutioninnovators.com/98/926298/10/20250218090527/NEC-ISCSI/console.txt
14:27:52 <whoami-rajat> hitachi: http://ec2-18-177-230-241.ap-northeast-1.compute.amazonaws.com/refs/changes/98/926298/10/iscsi/stestr_results.html
14:28:00 <whoami-rajat> both iscsi ones
14:28:21 <whoami-rajat> also they're passing so looks good
14:28:45 <whoami-rajat> one other concern i had
14:29:15 <whoami-rajat> recently Dan smith made me aware about his changes to use gpt as a format instead of raw
14:29:18 <whoami-rajat> #link https://review.opendev.org/q/topic:%22bp/glance-as-defender%22+status:open
14:29:53 <whoami-rajat> I'm not 100% sure if it keeps backward compatibility (should be) but good to check it against your patch as well if it doesn't create any conflict
14:32:58 <mhen> we use a dedicated disk_format (luks), everything within it (e.g. raw or gpt) should be irrelevant to Glance as it is only visible to the guest
14:33:36 <mhen> i.e. the blob starts with the LUKS header, not the GTP or MBR (raw) header
14:33:45 <mhen> *GPT
14:34:15 <mhen> any MBR or GPT header is encrypted payload of the LUKS blob
14:35:19 <mhen> will keep it in mind though, maybe something comes up
14:35:24 <mhen> thanks for pointing this out
14:35:44 <whoami-rajat> ok, makes sense
14:38:40 <mhen> I will take trying to discern reproducible failures of storage CIs from occasional hiccups as an action item and reach out to jbernard for those I can identify
14:39:50 <jbernard> mhen: sounds good, i can do the tracking-down and requesting input part
14:39:59 <jbernard> if such is needed
14:41:02 <mhen> thanks for offering the assitance, much appreciated!
14:41:08 <mhen> *assistance
14:41:17 <jbernard> is anyone available to review part (or the whole) of this patch?
14:41:37 <jbernard> if the ci results are favorable, we still need additional review input
14:41:39 <yuval_> which patch?
14:41:48 <jbernard> yuval_: image encryption
14:41:57 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/926298
14:42:08 <yuval_> I can try but I dont think I have enough knowledge
14:45:07 <jbernard> no worries, even part is helpful
14:45:20 <rosmaita> i will take a look too
14:45:32 <jbernard> thanks
14:46:23 <jbernard> #topic open discussion
14:46:41 <whoami-rajat> mhen, just to clarify the workflow, we encrypt the whole image (LUKS header) and inside the image it could have/not have the partition table (GPT/MBR), we create an encrypted volume out of it with same keys and then os-brick/cryptsetup decrypts it and we can use the volume/image as it is
14:48:30 <mhen> whoami-rajat: correct. We copy the LUKS data over one to one into the volume and simply re-use the LUKS encryption natively.
14:48:58 <mhen> for qcow2+LUKS images it's a different story as we need to convert those to (raw) LUKS in Cinder beforehand
14:49:21 <whoami-rajat> okay, got it, thanks
14:49:40 <whoami-rajat> mhen, also do we have support in nova to decrypt the LUKS+raw image if we launch a VM from it directly?
14:51:06 <mhen> not in this iteration of the feature yet as Nova did not want to adopt it yet the last time we had a talk with them iirc
14:51:29 <mhen> they have their qcow2+LUKS
14:51:47 <whoami-rajat> ok, so the only way to use these encrypted images is through encrypted volumes
14:52:40 <whoami-rajat> interesting, does nova also support encrypting it's disks created from images?
14:54:00 <mhen> when the current patchset(s) land, you may use either qcow2+LUKS or raw LUKS images through Cinder volumes; concerning qcow2+LUKS there is also some Nova-side implementation for that in particular but I don't know the current state
14:54:15 <mhen> there have been multiple attempts at ephemeral storage encryption in Nova in the past
14:54:51 <mhen> I believe the latest idea was to use the qcow2+LUKS (native LUKS feature of qcow2) format as-is as a backing file or something
14:54:59 <yuval_> since we close to ending just want to put out I have 2 patches that are no-code(just doc's) that I would like to merge: https://review.opendev.org/c/openstack/cinder/+/939635
14:55:27 <andrei> I have small question, where can I check a list of drivers that will be removed from codebase?
14:55:28 <yuval_> https://review.opendev.org/c/openstack/cinder/+/939570
14:55:34 <whoami-rajat> mhen, ok, i wasn't aware, thanks for all the info!
14:56:24 <whoami-rajat> andrei, recently we haven't removed any driver from codebase but we do mark it as unsupported, you can check the support matrix for unsupported drivers
14:56:36 <whoami-rajat> #link https://docs.openstack.org/cinder/latest/reference/support-matrix.html
14:56:48 <whoami-rajat> #link https://docs.openstack.org/cinder/latest/reference/support-matrix.html#operation_supported
14:56:51 <whoami-rajat> this is more precise
14:57:37 <andrei> whoami-rajat, thank you!
14:57:43 <mhen> re qcow2+LUKS in Nova: https://blueprints.launchpad.net/nova/+spec/ephemeral-encryption-libvirt (search on this page for "qcow2" - there are a few related patchsets)
14:59:00 <whoami-rajat> ++
15:00:11 <jbernard> ok, last call everyone
15:00:16 <whoami-rajat> yuval_, the doc claims to be supporting retype but i don't see that being overriden in the lightos driver?
15:00:49 <whoami-rajat> do you mean host-assisted retype?
15:02:51 <whoami-rajat> don't mean to hold the meeting, we can discuss in cinder channel
15:03:18 <jbernard> no worries
15:03:37 <jbernard> thank you everyone
15:03:39 <jbernard> #endmeeting