| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 18:44:43 | sean-k-mooney | ok its getting late for me and dinner/breakfest is calling. im not sure where we are on this topic. | |
| 18:45:19 | sean-k-mooney | to me it was imporant to be able to take an unecypted image and create an encypted instance form that (vai selecting an encypted flavor) | |
| 18:45:39 | sean-k-mooney | and by default i would expect snapshots form that encypted instance to stay encypted | |
| 18:46:06 | sean-k-mooney | dan has a different usecase which is taking an encypted image and booting an encypted instance form that | |
| 18:46:35 | sean-k-mooney | snapshots creates an intersection fo both usescases | |
| 18:46:37 | melwitt | I think we all agree on that, it was only the idea of letting the user request or control the encryption format that was being debated | |
| 18:47:03 | sean-k-mooney | well previosuly i agured that should not be exposed at all | |
| 18:47:08 | melwitt | (agree on flavor hw:ephemeral_encryption=true|false) | |
| 18:47:49 | sean-k-mooney | i.e. the format used should not be exposed ot the user. that was reintroduced this cycle for the lvm upgrae case | |
| 18:48:29 | melwitt | ok, so it seems like you and dan agree about that then? provide only the boolean and don't expose a hw_ephemeral_encryption_format ... and the glance image format os_glance_encrypt_format is not related to that, it's only related to describing the image | |
| 18:48:53 | melwitt | oh, you mean to support them converting lvm => luks? | |
| 18:49:03 | sean-k-mooney | yes | |
| 18:49:07 | melwitt | if so I forgot that was the reasoning | |
| 18:49:24 | melwitt | ok, my bad if I forgot | |
| 18:49:26 | sean-k-mooney | that why plain came back into the spec | |
| 18:50:14 | melwitt | so I get your point is if we are ever going to support format conversions | |
| 18:50:18 | melwitt | ok.. I thought plain was already in the spec but tbh I can't remember for sure | |
| 18:50:42 | sean-k-mooney | it was pre zed | |
| 18:51:00 | sean-k-mooney | and then in antelope and bobcat we removed it and said we woudl only implmeent luks | |
| 18:51:08 | sean-k-mooney | and we have reverted back now | |
| 18:51:34 | sean-k-mooney | caracal also only supproted luks | |
| 18:52:15 | melwitt | ? I didn't think I changed anything regarding that from bobcat. I need to go look at it | |
| 18:52:59 | melwitt | ok, if that's the case then I expect to need to revise the currently proposed spec | |
| 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 | |