| jbernard | #startmeeting cinder | 14:01 |
|---|---|---|
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'cinder' | 14:01 |
| jbernard | #topic roll call | 14:01 |
| jbernard | o/ | 14:01 |
| sfernand | hi | 14:01 |
| whoami-rajat | hi | 14:01 |
| Luzi | o/ | 14:01 |
| mhen | o/ | 14:01 |
| jbernard | #link https://etherpad.opendev.org/p/cinder-epoxy-meetings | 14:02 |
| abishop | o/ | 14:02 |
| msaravan | hi | 14:02 |
| jbernard | we'll get started in a couple of minutes | 14:04 |
| Sai | o/ | 14:05 |
| rosmaita | o/ | 14:05 |
| tosky | o/ | 14:05 |
| yuval_ | o/ | 14:07 |
| jbernard | ok, welcome everyone | 14:10 |
| jbernard | sorry for the delay, today is another snow day so schools are closed where i live | 14:10 |
| jbernard | lets see | 14:11 |
| jbernard | #topic annoucements | 14:11 |
| jbernard | i need to register for the ptg | 14:12 |
| jbernard | and if you plan to attend, it looks like the registration link is here | 14:12 |
| jbernard | #link http://ptg.openinfra.dev/ | 14:12 |
| jbernard | client library release (final) is this week | 14:13 |
| jbernard | this is os-brick for us | 14:13 |
| jbernard | #topic image encryption | 14:14 |
| jbernard | ^ i have tested this locally and it all seems to work for me | 14:15 |
| rosmaita | \o/ | 14:15 |
| Luzi | yay | 14:15 |
| mhen | nice, thank you for testing | 14:15 |
| jbernard | i have notest that I need to transcribe into the review | 14:15 |
| mhen | we primarily tested rbd (Ceph) and (iirc) lvm backends using DevStack | 14:15 |
| mhen | a bunch of other storage backends are failing in the patchset's Zuul pipeline (StorPool, HPE etc.) | 14:15 |
| jbernard | but the weather/school-closings have been quite the ordeal in recent weeks | 14:15 |
| jbernard | mhen: are the failings related to the changes? (i haven't looked at those yet) | 14:16 |
| mhen | sadly, we neither have the necessary expertise nor available resources to evaluate and test integration with those proprietary storage systems ourselves | 14:16 |
| 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 |
| jbernard | hmm | 14:16 |
| mhen | some log links also 404 | 14:17 |
| mhen | (for IBM) | 14:17 |
| jbernard | do you know the set of failing 3rd party CIs? | 14:17 |
| whoami-rajat | it would be good to see if those failures are similar in other patches, if yes then probably unrelated | 14:18 |
| jbernard | we need to get that sorted before we could potentially merge | 14:18 |
| whoami-rajat | also are they failing consistently with every recheck or they passed as well? | 14:18 |
| jbernard | mhen: im can help track down folks to get input of specific failures | 14:19 |
| mhen | so, would it be valid to trigger the Zuul build a few times in succession and note down repeatedly failing backends? | 14:21 |
| mhen | ... and then trying to get in touch with folks responsible for them (through you jbernard) specifically? | 14:21 |
| jbernard | that was my thought too, if we have current results I can use those to reach out to folks | 14:22 |
| whoami-rajat | should be visible from older history but if there have been major changes in patchsets then we can retrigger it | 14:22 |
| whoami-rajat | i see other third party CIs passing so probably failures are not related to your patch | 14:23 |
| whoami-rajat | also do we know if we run encryption tests in third party CIs? | 14:23 |
| whoami-rajat | IIUC this change will only affect encryption workflow | 14:23 |
| rosmaita | third party CIs are supposed to run the encryption tests | 14:24 |
| rosmaita | they can use the fixed-key setup if they don't want to run barbican in their ci | 14:24 |
| 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 |
| 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:24 |
| jbernard | i could be wrong then, if the logs are present, we should be able to tell | 14:25 |
| jbernard | in general though, i think we need two things: | 14:26 |
| jbernard | 1. verify the chagnes are not effecting other drivers | 14:27 |
| jbernard | 2. at least 1 other reviewer is needed | 14:27 |
| whoami-rajat | hitachi and nec CI are running some encryption tests | 14:27 |
| whoami-rajat | nec: https://cinder-cilogs.openstack.nec-solutioninnovators.com/98/926298/10/20250218090527/NEC-ISCSI/console.txt | 14:27 |
| 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:27 |
| whoami-rajat | both iscsi ones | 14:28 |
| whoami-rajat | also they're passing so looks good | 14:28 |
| whoami-rajat | one other concern i had | 14:28 |
| whoami-rajat | recently Dan smith made me aware about his changes to use gpt as a format instead of raw | 14:29 |
| whoami-rajat | #link https://review.opendev.org/q/topic:%22bp/glance-as-defender%22+status:open | 14:29 |
| 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:29 |
| 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:32 |
| mhen | i.e. the blob starts with the LUKS header, not the GTP or MBR (raw) header | 14:33 |
| mhen | *GPT | 14:33 |
| mhen | any MBR or GPT header is encrypted payload of the LUKS blob | 14:34 |
| mhen | will keep it in mind though, maybe something comes up | 14:35 |
| mhen | thanks for pointing this out | 14:35 |
| whoami-rajat | ok, makes sense | 14:35 |
| 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:38 |
| jbernard | mhen: sounds good, i can do the tracking-down and requesting input part | 14:39 |
| jbernard | if such is needed | 14:39 |
| mhen | thanks for offering the assitance, much appreciated! | 14:41 |
| mhen | *assistance | 14:41 |
| jbernard | is anyone available to review part (or the whole) of this patch? | 14:41 |
| jbernard | if the ci results are favorable, we still need additional review input | 14:41 |
| yuval_ | which patch? | 14:41 |
| jbernard | yuval_: image encryption | 14:41 |
| jbernard | #link https://review.opendev.org/c/openstack/cinder/+/926298 | 14:41 |
| yuval_ | I can try but I dont think I have enough knowledge | 14:42 |
| jbernard | no worries, even part is helpful | 14:45 |
| rosmaita | i will take a look too | 14:45 |
| jbernard | thanks | 14:45 |
| jbernard | #topic open discussion | 14:46 |
| 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:46 |
| 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 |
| mhen | for qcow2+LUKS images it's a different story as we need to convert those to (raw) LUKS in Cinder beforehand | 14:48 |
| whoami-rajat | okay, got it, thanks | 14:49 |
| 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:49 |
| 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 |
| mhen | they have their qcow2+LUKS | 14:51 |
| whoami-rajat | ok, so the only way to use these encrypted images is through encrypted volumes | 14:51 |
| whoami-rajat | interesting, does nova also support encrypting it's disks created from images? | 14:52 |
| 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 |
| mhen | there have been multiple attempts at ephemeral storage encryption in Nova in the past | 14:54 |
| 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 |
| 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:54 |
| andrei | I have small question, where can I check a list of drivers that will be removed from codebase? | 14:55 |
| yuval_ | https://review.opendev.org/c/openstack/cinder/+/939570 | 14:55 |
| whoami-rajat | mhen, ok, i wasn't aware, thanks for all the info! | 14:55 |
| 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 |
| whoami-rajat | #link https://docs.openstack.org/cinder/latest/reference/support-matrix.html | 14:56 |
| whoami-rajat | #link https://docs.openstack.org/cinder/latest/reference/support-matrix.html#operation_supported | 14:56 |
| whoami-rajat | this is more precise | 14:56 |
| andrei | whoami-rajat, thank you! | 14:57 |
| 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:57 |
| whoami-rajat | ++ | 14:59 |
| jbernard | ok, last call everyone | 15:00 |
| whoami-rajat | yuval_, the doc claims to be supporting retype but i don't see that being overriden in the lightos driver? | 15:00 |
| whoami-rajat | do you mean host-assisted retype? | 15:00 |
| whoami-rajat | don't mean to hold the meeting, we can discuss in cinder channel | 15:02 |
| jbernard | no worries | 15:03 |
| jbernard | thank you everyone | 15:03 |
| jbernard | #endmeeting | 15:03 |
| opendevmeet | Meeting ended Wed Feb 19 15:03:39 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-02-19-14.01.html | 15:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-02-19-14.01.txt | 15:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-02-19-14.01.log.html | 15:03 |
| whoami-rajat | thanks! | 15:04 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!