| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 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 :) | |
| 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 | |