| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 18:35:06 | sean-k-mooney | when we boot the instance if encyption is not enable din the iamge or the flavor | |
| 18:35:17 | melwitt | right | |
| 18:35:19 | sean-k-mooney | we should write hw_ephemeral_encryption=true to the instance system metadata | |
| 18:35:31 | sean-k-mooney | correct? | |
| 18:35:53 | sean-k-mooney | to record that this instance is using encyption so we can schdule and so it is propagated by default to future snapshots | |
| 18:36:14 | melwitt | it will be automatically (as image_hw_ephemeral_encryption=true) | |
| 18:36:16 | melwitt | image properties are stored in system metadata already | |
| 18:36:21 | melwitt | (meaning today, not only with the proposed patch series) | |
| 18:36:37 | sean-k-mooney | well we just said hw_ephemeral_encryption was unset but the image was encypted | |
| 18:37:16 | melwitt | oh, ok sorry. I see what you're saying now | |
| 18:38:09 | sean-k-mooney | basically if someone creates an image with os_glance_encrypt_format=luks | |
| 18:38:15 | melwitt | hm yeah, currently we are covered to maintain encrypted disks via BDM attributes but you're right that doesn't cover the scheduling piece | |
| 18:38:42 | sean-k-mooney | and we boot a vm form that with a normal flavor with no extra spec | |
| 18:39:22 | sean-k-mooney | we would need to populate image_hw_ephemeral_encryption=true and image_hw_ephemeral_encryption_format=luks | |
| 18:39:31 | melwitt | yeah, I think I understand what you're saying. we wouldn't have the image prop nor flavor extra spec to make sure we're always scheduled to hosts that support local encryption | |
| 18:39:44 | sean-k-mooney | yep | |
| 18:40:32 | sean-k-mooney | so we proably dont need hw_ephemeral_encryption_format and could just use os_glance_encrypt_format if we will never suport format convertion | |
| 18:40:40 | melwitt | yeah, ok. I think it would make sense to set image_hw_ephemeral_encryption=true in system metadata if we are doing it by implication from the source image. or else need some other way to deal with it | |
| 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 | sean-k-mooney | yes but my understaindg is that it was replacing and "adopting" the existing lvm volumes | |
| 19:09:24 | melwitt | I'm not sure about lvm in BDMs, I have to double check | |
| 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 | |