| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 16:27:30 | bauzas | and as I said just before, we shall round about some patches next week hopefully | |
| 16:27:36 | elodilles | \o/ | |
| 16:28:02 | bauzas | #topic Open discussion | |
| 16:28:11 | bauzas | (enriquetaso) Discuss the blueprint: NFS Encryption Support for qemu | |
| 16:28:14 | bauzas | enriquetaso: shoot | |
| 16:28:18 | enriquetaso | hi | |
| 16:28:21 | enriquetaso | sure | |
| 16:28:30 | enriquetaso | As discussed on the PTG a couple weeks ago. I’ve proposed the blueprint. | |
| 16:28:30 | enriquetaso | As discussed on the PTG a couple weeks ago. I’ve proposed the blueprint. | |
| 16:28:42 | enriquetaso | #link https://blueprints.launchpad.net/nova/+spec/nfs-encryption-support | |
| 16:28:57 | enriquetaso | Summary: Cinder is working on supporting encryption on NFS volumes. To do this NFS driver uses LUKS inside qcow2 for this. | |
| 16:29:10 | enriquetaso | This affects Nova because Nova cannot handle qemu + LUKS inside qcow2 disk format at the moment. | |
| 16:29:25 | enriquetaso | What are your thoughts? | |
| 16:29:35 | enriquetaso | should I mention the rolling upgrades would be a problem on the bp ? | |
| 16:30:20 | bauzas | lemme reopen the ptg notes | |
| 16:30:50 | bauzas | right | |
| 16:31:51 | bauzas | we basically said we were quite okay with the proposed design but we were wondering if it was worth not scheduling to old computes | |
| 16:32:03 | bauzas | we have three options here : | |
| 16:32:23 | bauzas | 1/ avoid scheduling to old computes (by adding a prefilter) | |
| 16:33:07 | bauzas | 2/ preventing this feature on the API level by checking the compute service versions | |
| 16:33:59 | bauzas | 3/ do some compute check that would prevent the volume to be encryped on some preconditionsq | |
| 16:34:36 | bauzas | #2 seems a bit harsh to me | |
| 16:35:02 | sean-k-mooney | dind we discusss addign a trait | |
| 16:35:07 | bauzas | we did it | |
| 16:35:09 | sean-k-mooney | so 1 | |
| 16:35:21 | bauzas | without having full quorum, hence me restating the options | |
| 16:35:34 | sean-k-mooney | well i vote 1 or file a spec | |
| 16:36:04 | bauzas | then I tend to say option #1 and specless blueprint as we basically went down | |
| 16:36:12 | gibi | I'm OK with 1/ | |
| 16:36:16 | sean-k-mooney | becasue if we dont just use a trait/prefileter then i think we need a spec to expalin why that is not sufficent and descirbe it in detail | |
| 16:37:01 | dansmith | so a trait of "this is newer than X"? | |
| 16:37:09 | sean-k-mooney | no | |
| 16:37:16 | dansmith | that's kinda fundamentally wrong, so you need to expose it as a feature flag | |
| 16:37:22 | sean-k-mooney | COMPUTE_somehting | |
| 16:37:36 | bauzas | sean-k-mooney: do we all agree now that we accept a new trait saying something like "I_CAN_ENCRYPT_YOUR-STUFF" | |
| 16:37:38 | dansmith | is there any compute config that needs to be enabled? if so, ideally that would control the exposure (or not) of the trait | |
| 16:37:38 | sean-k-mooney | to report the hypervers capablity to supprot lux in qcow | |
| 16:37:56 | sean-k-mooney | dansmith: i think this just need to check the qemu/libvirt version | |
| 16:38:00 | bauzas | my only concern is the traits inflation but that's a string | |
| 16:38:02 | sean-k-mooney | and report it statically if we are above that | |
| 16:38:09 | sean-k-mooney | i dont think we need a cofnig option | |
| 16:38:17 | bauzas | sean-k-mooney: that's why I was considering option 3 | |
| 16:38:35 | dansmith | sean-k-mooney: yeah, that's just a little annoying I think | |
| 16:38:39 | bauzas | which would be "meh dude, you don't have what I need, I'll just do what I can do" | |
| 16:38:45 | sean-k-mooney | bauzas: i dont think optional encypting is accpetable | |
| 16:38:47 | dansmith | because it becomes not as much a feature flag but a shadow version number | |
| 16:39:22 | bauzas | sean-k-mooney: true | |
| 16:39:28 | sean-k-mooney | if you asked for the storage to be enypeed we either need to do it or raise an error | |
| 16:40:05 | bauzas | sounds then reasonable to ERROR the instance | |
| 16:40:12 | enriquetaso | what a `new trait` involves? | |
| 16:40:18 | sean-k-mooney | dansmith: im not agaisn a min compute service version check in the api as well by the way | |
| 16:40:24 | bauzas | that's option 3 | |
| 16:40:25 | sean-k-mooney | i dont really think 2 is harsh | |
| 16:40:29 | bauzas | s/3/2 | |
| 16:40:46 | sean-k-mooney | we normally dont enabel feature untill the cloud is fully upgraded | |
| 16:40:54 | dansmith | I'm not saying that's how it needs to be, I'm just saying it feels like we're bordering on trait abuse here | |
| 16:40:56 | dansmith | so FWIW, | |
| 16:41:10 | sean-k-mooney | we have in the past done this on a per compute host bassis | |
| 16:41:15 | dansmith | we could also have a scheduler filter that requires a service version at or above a number | |
| 16:41:20 | sean-k-mooney | but in generall i think a min comptue version check is preferable | |
| 16:41:23 | dansmith | and we could add hints/advice to the scheduler for this sort of thing | |
| 16:41:31 | dansmith | which would be nice for this and other things I imagine | |
| 16:41:49 | bauzas | yeah this sounds quite a reasonable tradeoff | |
| 16:42:03 | sean-k-mooney | this being? | |
| 16:42:20 | bauzas | I'm just wondering whether we expose the service version on the scheduling side | |
| 16:42:31 | sean-k-mooney | i think you can already schedul based on the comptue service version | |
| 16:42:45 | sean-k-mooney | with either the json of comptue capablity filter | |
| 16:42:58 | sean-k-mooney | but in any case we want this to work without any configuration requried | |
| 16:43:20 | sean-k-mooney | bauzas: why not just do 2? | |
| 16:43:24 | gibi | I might miss something but if this feature nees compute code + libirt/qemu version then as simple compute version check is not enough | |
| 16:43:34 | dansmith | sean-k-mooney: Im saying make it integrated | |
| 16:43:44 | dansmith | sean-k-mooney: kinda like a prefilter | |
| 16:43:56 | bauzas | wait https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L399 | |
| 16:44:17 | dansmith | gibi: yeah, you need service version and libvirt version and qemu version right? | |
| 16:44:20 | sean-k-mooney | so if feature x requries minv version y have a prefilter or simialr that will request a host with that min version | |
| 16:44:25 | bauzas | that's ephemeral encryption | |
| 16:44:50 | sean-k-mooney | ya thats seperate | |
| 16:44:56 | sean-k-mooney | we are talkign about encyption for nfs | |
| 16:45:09 | sean-k-mooney | for cinder volume backend that use nfs | |
| 16:45:10 | dansmith | gibi: that's kinda why I just think this is trait pollution because we end up with all these feature flags for any possible combination of several versions | |
| 16:45:24 | dansmith | and especially in three years, that trait is useless as everything exposes it all the time | |
| 16:45:55 | dansmith | so I'm not sure what the best plan is here, to be clear, I'm just saying none of these simple things feels right | |
| 16:46:07 | sean-k-mooney | dansmith: not really usign a trait we report an abstract capblity. but in general i would prefer both a trait and a compute version bump | |
| 16:46:43 | dansmith | that's the thing though: | |
| 16:47:02 | sean-k-mooney | enriquetaso: how is this feature requested on teh volume by the way? | |
| 16:47:08 | dansmith | just exposing a "can do nfs encryption" because all the versions are new enough just feels like we could have a thousand of those things | |
| 16:47:20 | enriquetaso | when attaching the volume sean-k-mooney | |
| 16:47:35 | sean-k-mooney | how exactly a atribute on the volume | |
| 16:47:44 | sean-k-mooney | enriquetaso: we have two distict but related problems | |
| 16:47:55 | sean-k-mooney | for attachemtn we know the host and have to check if the host suprot this | |
| 16:48:03 | sean-k-mooney | for new boots or move operattions | |
| 16:48:13 | sean-k-mooney | we need to find another host that also supports it | |
| 16:48:38 | bauzas | that's why I tend to lean on option 2 | |
| 16:48:40 | sean-k-mooney | and we need this to work without any operator configurign of aggreates ectra | |
| 16:48:46 | bauzas | it's an interim solution | |
| 16:48:54 | dansmith | bauzas: me too, but 2 is not enough right? | |
| 16:49:07 | sean-k-mooney | option 2 works if an only if our min libvirt/qemu version are new enough | |
| 16:49:10 | dansmith | because you could be running an older libvirt/qemu | |
| 16:49:11 | enriquetaso | mmh, the volume attr says it's encrypted and the volume image format is qcow2: https://review.opendev.org/c/openstack/nova/+/854030/6/nova/virt/libvirt/utils.py | |
| 16:49:18 | dansmith | and I suspect it also depends on brick versions? | |