| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 18:24:42 | melwitt | at least so far (and from before I started working on it), hw_ephemeral_encryption=false has meant explicitly don't encrypt, not set means "don't care", hw_ephemeral_encryption=true | |
| 18:25:09 | sean-k-mooney | right that is what i expect hw_ephemeral_encryption=false to mean | |
| 18:25:12 | melwitt | *hw_ephemeral_encryption=true means specifically want encrypted | |
| 18:25:35 | sean-k-mooney | but i also expect unset hw_ephemeral_encryption to maintian the exsiting behavior | |
| 18:25:40 | sean-k-mooney | which woudl be unencypted | |
| 18:26:26 | melwitt | it does, but I think if the source image is encrypted, the default behavior should be to maintain the encryption no? | |
| 18:26:37 | dansmith | ++ | |
| 18:26:39 | sean-k-mooney | correct | |
| 18:26:49 | melwitt | ok. I'm not sure we are really disagreeing :) | |
| 18:26:54 | sean-k-mooney | and for encypted iamges we would do what | |
| 18:27:07 | sean-k-mooney | i woudl expect use to reject booting them | |
| 18:27:42 | sean-k-mooney | you have not enabled encyption in nova using either the flavor or image property we are specifying | |
| 18:27:55 | sean-k-mooney | so there is no way for use to schdule to a host that supprots the feature | |
| 18:27:57 | melwitt | I just said encrypted images implies encrypted if hw_ephemeral_encryption is unset, if hw_ephemeral_encryption=false is present, decrypt it | |
| 18:28:24 | sean-k-mooney | right so i dont think that a backwars compatiabel change. | |
| 18:28:52 | sean-k-mooney | we coudl make that work but then we have to document this very diffently | |
| 18:28:55 | melwitt | yeah I mean if the source image is encrypted and hw_ephemeral_encryption is unset and no host in the cloud supports local encryption, I think it would reject that request and the person has to come back with hw_ephemeral_encryption=false? | |
| 18:29:20 | sean-k-mooney | right os i dont like relying on an no valid host for that determination | |
| 18:29:57 | sean-k-mooney | if we want to make this work then i think we shoudl not have image properties to enable instance encyption | |
| 18:30:32 | sean-k-mooney | and instead just have the flavor extra spec and enabel encyption if the OS_GLANCE_ENCYPTION* | |
| 18:30:35 | sean-k-mooney | image property is there | |
| 18:30:36 | melwitt | I think the problem with that is then it gives users no way to control it. since flavors are generally admin only created | |
| 18:30:58 | sean-k-mooney | they woudl contol it by uploading an encypted image | |
| 18:31:29 | melwitt | 🤔 | |
| 18:32:00 | sean-k-mooney | i really think the sandardsation attpemt for the image properies in glance is incorrect | |
| 18:32:18 | sean-k-mooney | i dont disagree with it in principal but | |
| 18:32:30 | sean-k-mooney | with the implication it has for nova/cinder | |
| 18:33:58 | sean-k-mooney | dansmith: am i correct in saying you want a single way to express that a given image is encypted and all resouces careated form it should remain encypted" while allso allowing it to be explcitly unecypted via a snapshot | |
| 18:34:13 | melwitt | well the glance image properties are not doing anything to request encryption, they're just describing the image. and on our side I think we should default to encrypted if the source is encrypted, with hw_ephemeral_encryption=false (our image prop, not glance's) being the way out of that if someone wants that | |
| 18:34:46 | sean-k-mooney | melwitt: i can see that | |
| 18:34:55 | sean-k-mooney | but in that case if the souce image is encypted | |
| 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 | |