| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 17:54:15 | melwitt | "today" meaning in the proposed patch series? | |
| 17:54:22 | melwitt | in the series there is support for booting from encrypted images | |
| 17:54:28 | melwitt | oh, yeah you might be thinking of signed | |
| 17:54:29 | sean-k-mooney | no today meaning Caracal/master | |
| 17:54:34 | dansmith | that's kinda the whole point right? | |
| 17:54:46 | dansmith | (booting from encrypted images" | |
| 17:55:38 | sean-k-mooney | not entirely. so i tought the gap we were trying to solve is booting vms with encypted local storage | |
| 17:55:52 | sean-k-mooney | irriespective of the encyption state in glance | |
| 17:56:14 | melwitt | I think the main point is booting encrypted from unencrypted but booting from encrypted quickly becomes an expectation bc of snapshotting imho | |
| 17:56:16 | dansmith | what's the point of local storage encryption if snapshots are clear? | |
| 17:56:36 | sean-k-mooney | they wernt clear in the previosu iteration of the spec | |
| 17:56:53 | dansmith | maybe I'm completely off base here, but in a cloud snapshots are like the #2 most important unit of measure behind instances themselves | |
| 17:56:55 | melwitt | because the user might add private data after that (I thought?) | |
| 17:56:59 | dansmith | you need snaps for basically everything in the cloud workflow | |
| 17:57:16 | sean-k-mooney | i dont think that is true | |
| 17:57:28 | melwitt | but like for example my laptop, the OS image was not encrypted but my disk is encrypted | |
| 17:58:11 | sean-k-mooney | * i dont think snapshots is the #2 most imporant thing in a cloud workflow | |
| 17:58:16 | dansmith | melwitt: it's a bit different there because the OS is read-only and your user data is transportable separately from the OS image, whereas we don't really support that | |
| 17:58:27 | melwitt | that's what I think the most common case probably is. but like I said I think if snapshot is a basic feature available in the cloud, I think users would expect to be able to boot from an encrypted snapshot as well | |
| 17:58:29 | dansmith | sean-k-mooney: okay well, we disagree there then | |
| 17:59:25 | sean-k-mooney | melwitt: right but lest take an example | |
| 17:59:45 | sean-k-mooney | i boot a vm form an unencypted ubuntu image with a flavor that enabel instance encyption | |
| 18:00:18 | sean-k-mooney | if we take a snapshot of that then i would expect you to set the hw_ephemeral_encyption image property in the snapshot | |
| 18:00:35 | sean-k-mooney | and the OS_GLACE_* properties to recored the format | |
| 18:01:14 | dansmith | what about cinder? | |
| 18:01:27 | sean-k-mooney | can you elaberate? | |
| 18:01:30 | dansmith | you want them to set that property on an encrypted image they upload just in case someone wants to boot from it? | |
| 18:01:43 | sean-k-mooney | no | |
| 18:01:56 | dansmith | because if they don't you'll decrypt their data when you boot from it if you don't know to go set that intent flag | |
| 18:02:03 | sean-k-mooney | but if we were taking a snapshot of a BFV volume we could | |
| 18:02:07 | melwitt | I think that's where I differ in my thought, I don't think hw_ephemeral_encryption (the boolean) on the snapshot. only the secret uuid (os_glance_encrypt_key_id) which implies it is encrypted | |
| 18:02:27 | sean-k-mooney | it imples the image is | |
| 18:02:39 | sean-k-mooney | but not that only encypted guest can be crated form it | |
| 18:03:06 | melwitt | right | |
| 18:03:24 | sean-k-mooney | weither we set hw_ephemeral_encyption on the snapshot is a design choose we can make | |
| 18:03:53 | sean-k-mooney | but to me hw_ephemeral_encyption is the only thing on an image that says the resulting vm must be booted with encypted local storage | |
| 18:04:01 | dansmith | melwitt: wait, you think that if you snapshot an encrypted instance to an encrypted image and then create another instance from that, it should be de-crypted? | |
| 18:05:17 | melwitt | dansmith: no, I don't.. but somewhere along code review someone commented that I should not assume encrypted if the source is encrypted. originally I did assume encrypted if source encrypted | |
| 18:05:29 | gmann | sean-k-mooney: yes, we can use the "files" (files is correct name of var, not relevent-files ) variable to define the files we want to run the job when they are changed. | |
| 18:05:44 | dansmith | okay, I missed that I guess.. I definitely do not think we should ever decrypt unless specifically asked | |
| 18:06:13 | sean-k-mooney | dansmith: so to me that means we shoudl reject booting form an image with OS_GLACE_* options | |
| 18:06:17 | dansmith | so if we have the hw_ boolean on the image, I think that either we take the default to match the format, or we *require* it be set to something before we agree to use the image (i.e. tell me what you want me to do with this) | |
| 18:06:21 | sean-k-mooney | if the flavor or iamge does not have hw_ephemeral_encyption=True | |
| 18:06:36 | melwitt | ok. I might have misunderstood what the person said. and tbh I need to double check what it's doing at the moment because I don't remember off the top of my head | |
| 18:06:37 | dansmith | sean-k-mooney: we could, but I think we could also punch the users in the face | |
| 18:06:51 | sean-k-mooney | i think the glance feature is currently broken | |
| 18:07:04 | dansmith | there is no glance feature (now or in the future) to be clear | |
| 18:07:05 | sean-k-mooney | becuase to mean the exisitng option are only about the format of the image at rest | |
| 18:07:15 | sean-k-mooney | without condiering the extra requiremns for nova/cinder | |
| 18:07:56 | sean-k-mooney | im confuges but someones at my door brb | |
| 18:08:09 | gmann | sean-k-mooney: and when we have less number of files we want job to run it is better and much readable to define those via "files" var instead of excluding a lot of others via "irrelevant-files" | |
| 18:08:14 | melwitt | I think the comment was about the fetch_to_raw method, I originally made it base the destination format on the source format. i.e. if image is encrypted then created disks should be encrypted | |
| 18:09:04 | dansmith | melwitt: right and that's definitely what I think we should do.. I commented on that method, so I hope I didn't mis-convey that I thought decrypting was the right thing to do | |
| 18:09:22 | dansmith | fetch_to_raw shouldn't really be making that policy decision | |
| 18:10:01 | dansmith | IIRC, that comment was about assuming plain if the source was plain or something, in support of my argument here | |
| 18:10:23 | melwitt | dansmith: I may have misinterpreted. I can see the point that it shouldn't make the decision. I hadn't thought of that. either way I'll go back and fix it if it needs fixing because I'm not 100% sure at the moment | |
| 18:11:02 | melwitt | *make the policy decision | |
| 18:11:04 | dansmith | melwitt: I think my comment was about what happens if you don't pass in explicit requirements to it, but not about what we should do at the high-level as a "policy" | |
| 18:11:11 | dansmith | ack | |
| 18:11:19 | melwitt | gotcha | |
| 18:11:29 | sean-k-mooney | gmann: ya so the issue is we currently use a negitive regex and zuul has change the regex lib they use and that is not supproted | |
| 18:11:51 | sean-k-mooney | gmann: so we will need to remove all our usages of negitive regex regardlels of which is shorter | |
| 18:12:31 | sean-k-mooney | melwitt: dansmith would it help to hop on a meet call?. | |
| 18:12:42 | gmann | sean-k-mooney: you mean irrelevant-files is not supported now? and we need to use "'files' and negate=True" ? | |
| 18:13:05 | sean-k-mooney | gmann: no i mean that rc2 does not supprot negitive suffix matches | |
| 18:13:06 | gmann | I am not aware of that, if so then it is a big changes to all the openstack jobs | |
| 18:13:24 | sean-k-mooney | so we use irrelivent files with "(?! ... )" | |
| 18:13:28 | gmann | sean-k-mooney: ohk, yes that is true. we have done those changes in Tempest too. got it | |
| 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 :) | |