On 14/08/2025 14:43, Markus Hentsch wrote:
Dear Sean,
Procedurally, the problem is you do not have an approved spec or blueprint for this feature in Nova, and it has been several releases since we last discussed this feature. [...] One of the things that is not supported in your series is direct booting of an encrypted image. [...] Even though this is a small patch it is quite a lot to ask for Nova to review, especially when it was not discussed at the PTG with the Nova or Cinder teams.
With all due respect, I think this is misrepresenting the history of this whole contribution quite a bit. As we initially started with this initiative all the way back in 2019 with a lot of back and forth over time, the history and agreements may not be fully obvious to all parties involved, so let me recap the key points.
While talking to the TC about the challenges of starting a contribution in such cross-project manner in the beginning, we were advised to initiate a popup team for the image encryption. We organized a regular popup team IRC meeting from 2019 all the way into 2025 [1], asking all relevant parties (Nova, Cinder, Glance, Barbican) to participate.
We initially also did a Nova spec for this but very early on (2019) the Nova team said that they wanted to take care of LUKS support for ephemeral storage encryption on their side first before considering/adopting any local image encryption [2.1] [2.2] [2.3]. At this time we agreed with Nova to leave ephemeral storage out of it and focus on working with Glance, Cinder and Barbican to get the base image encryption format and interoperability volumes in Cinder landed.
Between 2019 and 2023 we did lots of iterations on the basic integration, wrote specs for Glance as well as Cinder and waited for the implementation of the Secret Consumers API in Barbican [3.1] [3.2] for the final workflow because it was crucial that when using Barbican secrets (image keys) cross-service between Glance and Cinder that usage is properly tracked and keys aren't deleted while still in-use by either.
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.
From the beginning until the middle of 2025 we unfortunately had little resources to work on this from our side, so communication and progress took a bit of hit but we tried to continue the best we could. We intensified our work on this again over the last few months and got the patchsets focusing on images and volumes in good shape together with Glance and Cinder while also adding full Tempest scenario tests covering the full usage across Glance, Cinder and Nova.
We are now at a point where this is working for Glance and Cinder with favorable reviews from their side. The Nova team only requested to have the encryption format changed in the 2024 PTG, which we did as mentioned above but did not amend their stance on their involvement at any point. As we did agree in 2019 to leave Nova out of the implementation (as requested) and focus on Glance and Cinder, the patchset we are proposing to Nova is the bare minimum to get what we did for Glance and Cinder working in Nova but it does not touch anything else in Nova beyond that, especially ephemeral storage. And this is by design, because we were specifically asked not to and kept to the agreement.
so this si the disconnect when moving forward with the integration into nova you need to actually reach out again to agree that the design is still correct. all feature need to be re-appoved for each release by each team affected in a given release. we di not ask you to never talk to us again we asked you to come back to use when the depencies in cinder/glance were resolved and it was time to work on the nova part. in 2024 in dalmatian Dan asked for change to the local ephermal encuypion spec specifically related to ensuring that when we take a snapshot of a guest with an encrypted root disk that we support specifying how the encyption is done for the snapshot image. https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/ephem... this is a nova api change that default to using the same barbiacn key as the root image but can generate a new key or use an existing secret key provide by the user. this change did not merge because of the CVEs related to backing files and data file in qcow2 and vmdk formats that were foudn during that cycle. but form a nove presepctive i do nto see why this woudl be any differnt for cinder boot volumes. now i have not had time to dug into your patch in detail but looking at the comment form lee https://review.opendev.org/c/openstack/nova/+/926326/3/nova/compute/api.py#7... the code xispclity skip the check in the boot form volume case so that resolve the main issue i had with that. these design issue evolve over time so what may have been ok in 2024 may not be ok in 2025 of ohter features have landed in between. dan also responed so if dan has context and has time review given the size it might eb oke to proceed but this should have been approved as a specless bluering in the nova irc meeting proir to milestoen 2 on july 3rd.
I hope this can clear up some of the misunderstanding around the topic and can help us identify what exactly is missing for Nova and how to proceed for the first iteration of this feature. Based on the discussions so far, I think ideally we would have image encryption compatibility for Cinder volumes only (in Nova) and have the base ready for an extension towards ephemeral storage encryption in the future. We will look at the technical points you raised in more detail and see if we can address them appropriately, either by adjusting a patchset or documenting this in dedicated spec(s).
Please let us know if you think we can discuss this more efficiently by joining the Nova IRC meetings again, creating a dedicated PTG slot with Nova and/or reviving the popup team slot.
Kind regards,
Markus
[1] https://meetings.opendev.org/meetings/image_encryption/
[2.1] https://review.opendev.org/c/openstack/nova-specs/+/608696/11#message-a8642c... [2.2] https://review.opendev.org/c/openstack/nova-specs/+/608696/11#message-e597b0... [2.3] https://meetings.opendev.org/meetings/image_encryption/2019/image_encryption...
[3.1] https://meetings.opendev.org/meetings/image_encryption/2019/image_encryption... [3.2] https://meetings.opendev.org/meetings/image_encryption/2023/image_encryption...
[4] https://etherpad.opendev.org/p/dalmatian-ptg-cinder#L382
[5] https://review.opendev.org/q/topic:%22image-encryption%22+status:abandoned
[6] https://review.opendev.org/q/topic:%22LUKS-image-encryption%22