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. 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 -- Markus Hentsch DevOps Engineer Cloud&Heat Technologies GmbH Königsbrücker Straße 96 | 01099 Dresden +49 351 479 367 00 markus.hentsch@cloudandheat.com | www.cloudandheat.com Green, Open, Efficient. Ihr Cloud-Service- und Cloud-Technologie-Provider aus Dresden. https://www.cloudandheat.com/ Commercial Register: District Court Dresden Register Number: HRB 30549 VAT ID No.: DE281093504 Managing Director: Nicolas Röhrs Authorized signatory: Dr. Marius Feldmann