| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 18:53:10 | sean-k-mooney | i guess this is a delete between the libvirt and non libvirt spec version | |
| 18:53:29 | melwitt | I do think maybe it could be a user pain point if we don't give them a way to go lvm => luks | |
| 18:53:38 | sean-k-mooney | since the libvirt spec say " As highlighted at the start of this spec this initial support will only be for the LUKSv1 encryption format." | |
| 18:54:24 | sean-k-mooney | melwitt: right so i was expecting that to happen via a live migrate or similar | |
| 18:54:34 | sean-k-mooney | lvm -> luks | |
| 18:54:56 | sean-k-mooney | so this is part of the probelm with having two specs for this | |
| 18:55:01 | melwitt | yeah, ok. so maybe what it should say is that's what we support at this time and hw_ephemeral_encryption_format should only be introduced if we are adding the ability to convert formats | |
| 18:55:08 | sean-k-mooney | the libvirt spec say we will only support luks | |
| 18:56:02 | sean-k-mooney | right the parent spec says we can supprot plain but then that also implese we can have a diffent image vs instnace encyption format | |
| 18:56:15 | melwitt | I think at the very least that would be an additional patch(es) later in the series. the intent was definitely to start with only luks | |
| 18:56:19 | melwitt | yeah, I dunno if maybe I should consolidate the specs and just not have the libvirt one going forward? I dunno | |
| 18:57:06 | sean-k-mooney | your right that the libvirt one has not changed for what its worth | |
| 18:57:36 | sean-k-mooney | it has and still does say you would only support luks and the generic one says we will supprot muliple formants and has doen for multipel cycles | |
| 18:58:14 | melwitt | ok. I'll go through it and make it clear that for now/for early patches it's luks only. and that hw_ephemeral_encryption_format is coupled with format changes and that may or may not be something we add on in later patches | |
| 18:58:17 | sean-k-mooney | those two are in conflict since this is not being implemented in any other driver | |
| 18:58:50 | sean-k-mooney | ok but then that also bring up the config option | |
| 18:58:52 | melwitt | well, I guess (and we have comments about this on the spec) hw_ephemeral_encryption_format=plain could/would be a way to say "I want lvm encryption specifically" | |
| 18:59:01 | sean-k-mooney | we dont need [ephemeral_storage_encryption]/default_format if its luks only | |
| 18:59:37 | sean-k-mooney | melwitt: but we dont want to use that to request legacy lvm encyption right | |
| 19:00:13 | melwitt | and the debate on that one is should the cloud (and only the cloud) dictate the format | |
| 19:00:17 | melwitt | and that providing a choice of format is implying a mixed cloud, which afaik we don't officially support | |
| 19:00:46 | sean-k-mooney | we supprot mixed clouds with diffent images_type backends in nova | |
| 19:00:58 | sean-k-mooney | but we just dont support move operations between images_type backends | |
| 19:00:59 | melwitt | yeah I think that's where the comments are at right now, is we don't want to assume a mixed cloud being possible and you get what you get depending on what cloud you're on and what it provides | |
| 19:01:27 | sean-k-mooney | well its very common ot have some comptues use local storage and other use ceph | |
| 19:02:08 | sean-k-mooney | wither that local storage is lvm or file backed (qcow/raw) is proably workload dependent | |
| 19:02:14 | melwitt | ok. so if that's the case, then that would be the only real purpose of a hw_ephemeral_encryption_format | |
| 19:02:35 | melwitt | I think that will be what drives the existence of hw_ephemeral_encryption_format -- whether or not we are saying we support a mix of lvm and luks hosts | |
| 19:02:48 | sean-k-mooney | yes but landing on a host with the legacy lvm supprot would not be vlaid for hw_ephemeral_encryption_format | |
| 19:03:05 | sean-k-mooney | hw_ephemeral_encryption_format should be the new feature exclively right | |
| 19:03:10 | melwitt | there are placement traits for the format | |
| 19:03:22 | melwitt | so we could schedule based on that if we had a mix | |
| 19:03:49 | sean-k-mooney | right but im saying that COMPUTE_EPHEMERAL_ENCRYPTION_PLAIN does not imply lvm | |
| 19:04:18 | sean-k-mooney | it impikes nova si cable of booting the instance with stoage that uses the dmcypt_plain encyption format | |
| 19:04:19 | melwitt | it does in the universe of the local encryption feature as far as I understand it | |
| 19:04:42 | melwitt | because I didn't think we were wanting to offer dm-crypt plain for anything new | |
| 19:05:03 | sean-k-mooney | it could be a rbd volume mounted with dmcypt no? | |
| 19:05:27 | melwitt | so the only thing COMPUTE_EPHEMERAL_ENCRYPTION_PLAIN could mean is lvm and [ephemeral_storage_encryption]enabled=true or whatever | |
| 19:05:47 | sean-k-mooney | melwitt: so to me COMPUTE_EPHEMERAL_ENCRYPTION_PLAIN imples using the new feature which also impleis storign seperate secrets for each disk in barbican ectra | |
| 19:06:14 | melwitt | that is not my understanding that we would be supporting rbd with dm-crypt plain | |
| 19:06:30 | sean-k-mooney | the spec does not say you will implment it | |
| 19:06:47 | sean-k-mooney | but takeing a step back and looking at the trait defintion that woudl be a vaild implmeation in nova | |
| 19:06:57 | melwitt | I think (and I could be wrong because I never discussed this with Lee) but I think PLAIN was intended to be for retrofitting legacy (lvm) encryption into the new model | |
| 19:07:08 | melwitt | and no longer use the config options for lvm encryption | |
| 19:08:02 | sean-k-mooney | perhaps but i would not consider the legacy lvm supprot to be a valid impletation with regards to reporting COMPUTE_EPHEMERAL_ENCRYPTION | |
| 19:08:16 | melwitt | the spec has always said "deprecate legacy lvm config and make lvm encrypt work with the flavor/image model" | |
| 19:08:23 | sean-k-mooney | perhaps we would need to granfather it in for upgrade reasons | |
| 19:08:50 | sean-k-mooney | but today if you use the legacy feature its not reflected in the bdms right | |
| 19:08:51 | melwitt | yeah I think the intent was/is to consolidate the way in which local encryption is requested and scheduled and all that | |
| 19:09:04 | melwitt | to make it all work the same way | |
| 19:09:24 | melwitt | I'm not sure about lvm in BDMs, I have to double check | |
| 19:09:24 | sean-k-mooney | yes but my understaindg is that it was replacing and "adopting" the existing lvm volumes | |
| 19:09:46 | sean-k-mooney | i.e. we would back populate the bdms with the encyption flags and format info | |
| 19:10:14 | melwitt | my understanding is that it also provides the mechanism for requesting lvm going forward | |
| 19:10:35 | sean-k-mooney | so lvm encyption is not somethign you request today its config drivven only | |
| 19:10:48 | melwitt | I think it's supposed to be all of that. replace/adopt + support creating new instances with lvm using flavor/image and no more lvm encryption config options | |
| 19:11:01 | melwitt | right.. | |
| 19:11:13 | sean-k-mooney | but the new lvm instance would not use the config options | |
| 19:11:24 | melwitt | right | |
| 19:11:30 | sean-k-mooney | we would use the flavor/iamge properties | |
| 19:11:36 | sean-k-mooney | and unlike the adoptied ones | |
| 19:11:44 | sean-k-mooney | each lvm disk would have its own key | |
| 19:11:49 | sean-k-mooney | just like with qcow | |
| 19:12:14 | melwitt | yes, that is what I thought the spec was intending | |
| 19:12:18 | melwitt | to not have two separate ways of doing local encryption | |
| 19:12:33 | sean-k-mooney | right | |
| 19:12:45 | melwitt | and in the process lvm gains some new user friendly abilities as a result | |
| 19:13:00 | sean-k-mooney | but that would only result in host tha tuse lvm reporting COMPUTE_EPHEMERAL_ENCRYPTION | |
| 19:13:10 | sean-k-mooney | after we supprot upgrading the exiting instnaces | |
| 19:13:32 | melwitt | ok. so all that said, my understanding was that for the current chunk we're trying to do now in dalmatian we are only doing luks and leaving lvm as the legacy config options at this time | |
| 19:13:50 | sean-k-mooney | yep | |
| 19:13:54 | sean-k-mooney | thats what i tought too | |
| 19:14:08 | sean-k-mooney | so supporting rbd,raw/flat,qcow | |
| 19:14:17 | sean-k-mooney | but not lvm | |
| 19:14:26 | melwitt | ok. so it seems then that we would hold off on introducing hw_ephemeral_encryption_format until we work on the lvm support | |
| 19:14:31 | melwitt | right | |
| 19:14:37 | sean-k-mooney | and the exisitng lvm fature will be deprecate but not removed until we can adopt them into the new framework | |
| 19:15:23 | sean-k-mooney | yes we would only need hw_ephemeral_encryption_format if we supprot somethign other hten luksv1 | |
| 19:16:11 | sean-k-mooney | which also means if os_glance_encrypt_format is set to anything other then luks we shoudl reject that too right | |
| 19:16:31 | melwitt | ok, I think we all agree about that. so I'll update the spec to explain this in a lot of detail 😂 and that hw_ephemeral_encryption_format will not be part of this first chunk and that it would come into play only when we work on adding support for lvm | |
| 19:17:02 | sean-k-mooney | and do we agree the same is true for the config option | |
| 19:17:22 | melwitt | I think it would be reasonable to reject that yes, if os_glance_encrypt_format is not luks. we won't be able to honor it | |
| 19:17:40 | sean-k-mooney | ok | |
| 19:18:15 | melwitt | I think I made the config option a choices= where the only choice is luks | |
| 19:18:17 | melwitt | but I'll double check and make it that if it isn't already | |
| 19:18:30 | sean-k-mooney | ok | |
| 19:18:40 | sean-k-mooney | if its only luks then i dont think we need it personally | |
| 19:20:13 | melwitt | that's a fair point. I suppose all it could potentially be helping with transparency but I could see the argument not to have it | |
| 19:20:23 | opendevreview | Merged openstack/nova master: Enable OCaaS for several nova jobs https://review.opendev.org/c/openstack/nova/+/919738 | |
| 19:20:26 | sean-k-mooney | i think what we are setteling on is we only need 1 extra spec/image property the boolean hw:ephemeral_encryption/hw_ephemeral_encryption | |
| 19:20:40 | melwitt | that is also my understanding | |
| 19:20:44 | sean-k-mooney | and if that is unset and the image in encyped then the vm would be encypted too | |
| 19:20:53 | sean-k-mooney | meaning you dont have to opt in for encypted images | |
| 19:21:04 | melwitt | yes, that's what I understand as well | |
| 19:21:20 | sean-k-mooney | so there is only one last bit i want to check | |
| 19:22:00 | sean-k-mooney | will we allow an opt out via the flavor i.e. hw:ephemeral_encryption=false and os_glance_encrypt_format=luks | |
| 19:22:06 | sean-k-mooney | should that be a 409 conflict | |
| 19:22:09 | sean-k-mooney | or decypt the image | |
| 19:22:15 | melwitt | the main thing is I think we want to avoid an unpleasant surprise on that. similar to the encrypted rescue image, not to just decrypt it | |
| 19:22:47 | melwitt | I think the desire based on current code review comments is that it would decrypt in that case | |