| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 18:13:34 | sean-k-mooney | "(?!" is not supported | |
| 18:13:38 | gmann | yes | |
| 18:14:07 | sean-k-mooney | so when the first email was sent about this change im 99% certin nova was not flagged as needing anychanges | |
| 18:14:19 | sean-k-mooney | now zuul is omitting a waring | |
| 18:14:27 | gmann | yeah | |
| 18:14:28 | sean-k-mooney | and i was wondering if anyone is currently fixing this | |
| 18:15:20 | gmann | I am not aware if anyone fixing those. we fixed a few of them in 'branches' variant in past | |
| 18:15:45 | sean-k-mooney | dansmith: melwitt when i said new galnce feature i was refering to the ablity to store an encypted image, which would require supprot in nova/cinder to create an instance/volume form them | |
| 18:16:00 | sean-k-mooney | from my perspective melwitt spec has nothign to do with that | |
| 18:16:22 | dansmith | glance won't have any changes to allow storing an encrypted image | |
| 18:16:41 | dansmith | it's already storing them for cinder | |
| 18:17:09 | sean-k-mooney | https://github.com/openstack/glance-specs/blob/master/specs/2024.1/approved/glance/image-encryption.rst | |
| 18:17:17 | sean-k-mooney | so that is not going to be implemnted | |
| 18:17:42 | dansmith | it's just a spec to capture the standardization of the properties at this point | |
| 18:18:18 | dansmith | it was originally going to involve some other pieces but I think it's all removed.. either way, as melwitt has demonstrated with her series already, no glance support is required or expected here AFAIK | |
| 18:18:24 | sean-k-mooney | ok but form my perspective os_glance_encrypt_format has nothing to do with the local encyption series | |
| 18:18:37 | dansmith | I understand you feel that way | |
| 18:20:09 | melwitt | fwiw sean-k-mooney I don't think it does/has to have something to do with the local encryption series but I'm not following what/why that matters (?) | |
| 18:20:43 | sean-k-mooney | melwitt: it matter because dan is asserting that if os_glance_encrypt_format is set we cant boot a instnace without encyption form it | |
| 18:21:05 | sean-k-mooney | where as i think decypting the image in that case is the correct behavior because the image is not set to enable encyption | |
| 18:22:05 | melwitt | sean-k-mooney: from what I understand we were thinking we would be able to if hw_ephemeral_encryption=false or hw:ephemeral_encryption=false on the image or flavor. like if someone explicitly conveys they want it to be decryped | |
| 18:22:45 | sean-k-mooney | we could make it a trisate and have hw_ephemeral_encryption=false have a diffent menaing then hw_ephemeral_encryption not set | |
| 18:22:59 | sean-k-mooney | but that is ofthen confusing to users | |
| 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 | |