On 14/08/2025 15:09, Dan Smith wrote:
One of the things that is not supported in your series is direct booting of an encrypted image. I could be wrong, but I think this is just a simplistic read of the first addition in the patch. AFAIK, the direct-boot abort is already in the tree, and they are just adding an additional check for the new key id parameter to mirror the same (existing) behavior. That is, of course, fine.
yes it is just an exteion of that but you shoudl be able to sue if for the "boot form voluem form inmage workflow" no? we had a very long converation about local iamge encryption and why you were not ok with breakign the workflow of creating a vm, modifying it to customisze it and sthen creating a snapshot and booting addtioanl vms. if the snapshot you are takign is of the boot volume and you don't support that work flow for that as well then we have a conflcit between the requrieemtn for both features. if something is taking a snapshot of a data volume and uploading it as an image that is diffent as that data volume is presumabel not marked as bootable anyway in cinder. booking using the encrypted image for local storage is totally valid as we have not implemented that in nova yet but i woudl expect the BFV case to work.
In April 2024 we had a cross project session with Nova and Glance at the PTG [4]! There was a big discussion around the encryption format initiated by Dan Smith (Nova). He proposed to move away from GPG and use LUKS instead because this would streamline it with existing functionality and formats that are already available in Nova and Cinder. Due to this proposal from Nova, we agreed to discard our existing patchsets [5] and rewrite our image encryption feature with new patchsets [6] with LUKS as the encryption format, as suggested by Dan Smith (Nova). We also talked specifically about the cryptographic key differentiation (hexlify vs. non-hexlify) which materialized in the os-brick change that you mentioned. Yep, this and the rest of your history summary matches my recollection as well.
that all fine and it more or less aligned with my recollection of this to however it misses the point that feature proposals be it tracked by a blueprint or spec are only accpted for a given release and need to be epxlictly propsoed again for the next cycle if tye are not complete. so even if it was acepted as a specless blueprint or an actul spec in 2024 on the nova side it would still need one for this cycle. appoval for dalmaion 2024.2 expired at the start of the 2025.1 cycle.
I know I've been on the hook to review this stuff and just keep getting pulled in different directions on more important stuff. My apologies, but there are some pretty important things up for review right now (like eventlet removal). Your patch to use brick for the passphrase extraction seems like a fine thing to merge at this point, especially because the earlier we merge it the better from the compatibility point of view. I'll try to make time today to look at it in detail.
--Dan