13:00:36 <Luzi> #startmeeting image_encryption
13:00:36 <opendevmeet> Meeting started Mon Aug 19 13:00:36 2024 UTC and is due to finish in 60 minutes.  The chair is Luzi. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:36 <opendevmeet> The meeting name has been set to 'image_encryption'
13:00:46 <Luzi> #topic Roll Call
13:01:16 <Luzi> I'll wait a few minutes for people to show up
13:03:18 <fungi> ohai
13:03:26 <mhen> o/
13:03:26 <Luzi> hi fungi
13:04:03 <Luzi> i wrote a mail to the ml, i hope some people from cinder and glance will also show up
13:05:48 <fungi> i saw, thanks for the update too
13:08:00 <Luzi> well it seems, we are the only ones
13:08:16 <Luzi> #topic Image Encryption Patches
13:08:41 <Luzi> while i had PTO, mhen thankfully started (and nearly finished) the implementation
13:08:46 <fungi> rosmaita was around in irc earlier, though not sure if he's been following the glance parts of this effort
13:08:49 <Luzi> https://review.opendev.org/q/topic:%22LUKS-image-encryption%22
13:09:04 <fungi> er, cinder i meant
13:09:28 <fungi> thanks mhen!
13:11:04 <rosmaita> o/
13:11:06 <Luzi> hi
13:11:33 <mhen> hi :)
13:11:46 <Luzi> here is an update: while i was on PTO mhen implemented nearly everything: https://review.opendev.org/q/topic:%22LUKS-image-encryption%22
13:12:18 <Luzi> we discussed one thing, were we have a question for Cinder and Glance:
13:12:49 <Luzi> a transition is needed from the old Glance image metadata naming (cinder_encryption_*) to the new one (os_encrypt_*)
13:13:32 <Luzi> so, how should we proceed with this topic?, because there will be images in the database with the old metadata names
13:15:12 <rosmaita> i talked about this a bit with Rajat (who has a holiday today) on friday
13:15:35 <Luzi> oh good
13:15:40 <rosmaita> i think you'll need a deprecation period like you outlined in your email
13:16:24 <Luzi> okay, we already identified the places, which we need to adjust.
13:16:27 <rosmaita> and you can possibly write an extension to the glance-manage tool that could migrate the metadata keys in the glance database
13:17:35 <rosmaita> one thing i'm not sure about is that the cinder_encryption_deletion_policy has been documented for a while
13:18:14 <Luzi> documentation is on my list
13:18:14 <rosmaita> so, if someone puts cinder_encryption_key_deletion_policy = no_delete (or whatever the real value is)
13:18:42 <rosmaita> and there is also os_encryption_key_deletion_policy == on_deletion already on the image
13:19:18 <rosmaita> do we need to worry about that?  i.e., should we respect what the person is trying to do?  because they won't get an error message
13:19:59 <rosmaita> that's the only reason i can think of for honoring the cinder_encryption_* metadata beyond a one or 2 cycle deprecation period
13:20:46 <rosmaita> sorry, what i meant about the documentation comment, is that the old name cinder_encryption_... has been documented a while back, and is in the current docs (i think)
13:20:56 <mhen> It is here: https://docs.openstack.org/glance/latest/user/common-image-properties.html
13:21:08 <mhen> our patchset will update this page with the new attributes
13:21:20 <mhen> maybe we should mention the old names in the descriptions?
13:22:17 <rosmaita> yes, say something about them being silently ignored
13:23:04 <rosmaita> and maybe backport a doc change saying something about the metadata key will no longer be functional starting with the 2025.1 release or something
13:24:08 <Luzi> okay that sounds good
13:24:36 <rosmaita> i guess the main issue is whether it is a good user experience to have the os_encryption_* override the cinder_encryption_* if both are present
13:26:28 <mhen> should we implement some safeguards preventing the creation of images with both or the addition of the other when one is already present?
13:27:18 <rosmaita> not sure, we don't want to to get too complicated (which opens an opportunity for bugs)
13:27:35 <mhen> right
13:27:48 <rosmaita> honestly, the cinder encrypted volume workflow was designed so that the end user didn't need to know about this stuff
13:28:01 <rosmaita> so i'm not sure that a lot of people are hacking into the workflow
13:28:24 <rosmaita> we had to document it in glance since we had one service deleting a resource created by another service
13:29:06 <mhen> you'd have to know about the hexlify tweak in order to actively use it, which is not documented afaik
13:30:01 <rosmaita> yeah, although you  could use the barbican secret for something else, and not know about the hexlify
13:31:45 <mhen> ah you  mean consuming the cinder-created secret for something else as a user`
13:31:51 <mhen> ?
13:32:09 <rosmaita> exactly
13:32:33 <rosmaita> looking at the cinder docs now to see if we say "do not mess with the cinder_* metadata on images"
13:32:33 <Luzi> is there somewhere documented to not use secrets created by OpenStack for something else, but to create a new one?
13:33:38 <Luzi> or that you should not re-use secrets, e.g. one secret for 2 or 3 images?
13:36:14 <rosmaita> i don't see anything
13:36:41 <rosmaita> gimme a minute to grep the docs instead of using a web search engine
13:38:09 <rosmaita> don't see 'cinder_encrypt' showing up anywhere in the current cinder docs
13:39:00 <Luzi> okay, I will take a look into the docs
13:39:05 <rosmaita> i think the idea was that since encrypted volumes were supposed to "just work" for end users, we don't explain the details anywhere (i guess to keep people from getting ideas)
13:40:08 <Luzi> so let me summarize: we add a deprecation period for the old metadata name and adjust the patches accordingly
13:41:07 <Luzi> i will take a look into the glance-manage tool and write an extension to change names in the database
13:42:12 <Luzi> that way we will only have the problem with users creating new images with the old metadata names, so we provide documentation
13:42:21 <Luzi> did i get everything?
13:43:39 <rosmaita> i think so ... the upgrade path for operators is: 1. install 2024.2 or later, new resources get os_encrypt* metadata, legacy cinder_encrypt* metadata is still honored for a deprecation period
13:44:00 <rosmaita> 2. run the glance-manage to update all the legacy encrypt metadata to os_encrypt*
13:44:37 <rosmaita> 3. at this point, no openstack service will create cinder_encrypt* metadata ... so if you still see some being created, must be by a user
13:44:56 <rosmaita> 4. reach out to the user and notify them that shortly the cinder_encrypt* will no longer work
13:45:08 <Luzi> yeah
13:45:53 <rosmaita> 3 & 4 sounds like a pain for operators, but we don't really think so, because it would mean that end users are making use of an undocumented "feature"
13:46:06 <rosmaita> so we don't expect that this will happen a lot
13:47:14 <Luzi> then it would be nice to have someone beside us, reviewing and/or testing the patches - to tell us if we missed something important
13:47:18 <rosmaita> might be a good idea to run that upgrade path by operators (i think put "[ops]" in the subject) and see if anyone objects
13:48:21 <fungi> it sounded like some of the operators in the scs community had an interest in these features, maybe they could provide feedback?
13:48:32 <rosmaita> ok, i will put reviewing these patches on my to-do list ... feel free to bug me on wednesday if you haven't seen any action
13:48:34 <Luzi> I will ask them too
13:48:40 <rosmaita> fungi: ++
13:48:43 <Luzi> thank you rosmaita
13:48:52 <rosmaita> well, don't thank me yet!
13:49:24 <Luzi> :D
13:49:43 <Luzi> okay, does anyone of you have any other questions or concerns?
13:49:51 <Luzi> regarding the image encryption
13:50:14 <fungi> i did not
13:52:07 <rosmaita> i think we're good
13:52:16 <Luzi> okay, thank you for joining this meeting and have a nice week :)
13:52:23 <Luzi> #endmeeting image_encryption