)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e3045ae33f21de9d25e7f4dbf5d014810f2d86d6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"98c45e10_e3bb6cc0","updated":"2024-05-09 15:39:36.000000000","message":"I\u0027m working on a new rev of this based on what was discussed at the PTG and will upload it by the spec review day.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"56e218c0_14333284","updated":"2024-03-27 14:51:24.000000000","message":"Whew, just barely made it through the base spec.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e7475ac99373df5c5c02ccd9bd40eab9aabb9b78","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"afa4dba0_5e078a8e","updated":"2024-05-20 16:43:54.000000000","message":"I think I said this before, but the libvirt part of this spec seems to be a bit superfluous in that it says (in a lot of words) that we\u0027ll implement the libvirt side of the larger effort. But, it\u0027s already written so I guess there\u0027s no reason not to keep it.\n\nThat said, I think all my concerns in the main spec have been addressed. I think we should proceed with this so as not to hold up the actual implementation and we can just come back and tweak this if necessary based on that.","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"cbfbf05f_983fd0aa","updated":"2024-05-20 16:28:30.000000000","message":"Sorry apparently I didn\u0027t commit these comments on Friday","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"93680d3a325b82d18f4e5cccd2efe5a1a88c6231","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"38d00180_c3484578","updated":"2024-05-22 14:22:19.000000000","message":"pushing draft comments sorry ment to do this last week","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b67913a6ddf9d2d6fabdb89104ee8af671222072","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"4b3b9808_fe017da2","updated":"2024-06-04 14:12:30.000000000","message":"Sorry, I didn\u0027t realize my +2 had been dropped from this.","commit_id":"4ea0b3177398fa9d16d0628ff0f7e190cc87d7c6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"7edb1e45_ff542dc0","updated":"2024-05-23 10:55:08.000000000","message":"i largely think the spec in its current form is ok\ni think at this point im getting some design fatigue\ndue to the complexity involed and the lenght of the spec but\n\ni think at this point we should just proceed with it as is and refine it\nlater based on the implemneation review.\n\ni think dan reached the same point in one of the recent revions\ntoo. so if they are happy with the current iteration then i think we can move back to the implmeation review and continue there.","commit_id":"4ea0b3177398fa9d16d0628ff0f7e190cc87d7c6"}],"specs/2024.2/approved/ephemeral-encryption-libvirt.rst":[{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"edaa33a6c2b37b17440fe6e9dd1b0d732feadbdc","unresolved":true,"context_lines":[{"line_number":120,"context_line":"``encryption_secret_uuid``"},{"line_number":121,"context_line":"    The UUID of the encryption secret associated with the disk"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":124,"context_line":"    The UUID of the encryption secret for the backing file associated with the"},{"line_number":125,"context_line":"    disk in the case of qcow2."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Handle ephemeral disk encryption within imagebackend"},{"line_number":128,"context_line":"----------------------------------------------------"},{"line_number":129,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"8b53bfaf_ae0f0a35","line":126,"range":{"start_line":123,"start_character":0,"end_line":126,"end_character":0},"updated":"2024-03-28 09:10:20.000000000","message":"this is new this reproposed patch from 2024.1 (C)","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":120,"context_line":"``encryption_secret_uuid``"},{"line_number":121,"context_line":"    The UUID of the encryption secret associated with the disk"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":124,"context_line":"    The UUID of the encryption secret for the backing file associated with the"},{"line_number":125,"context_line":"    disk in the case of qcow2."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Handle ephemeral disk encryption within imagebackend"},{"line_number":128,"context_line":"----------------------------------------------------"},{"line_number":129,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"f94ef22f_508c7c0b","line":126,"range":{"start_line":123,"start_character":0,"end_line":126,"end_character":0},"in_reply_to":"8b53bfaf_ae0f0a35","updated":"2024-05-23 10:55:08.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"edaa33a6c2b37b17440fe6e9dd1b0d732feadbdc","unresolved":true,"context_lines":[{"line_number":282,"context_line":"References"},{"line_number":283,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":".. [1] https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html"},{"line_number":286,"context_line":".. [2] https://docs.openstack.org/nova/victoria/configuration/config.html#workarounds.disable_native_luksv1"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":".. list-table:: Revisions"}],"source_content_type":"text/x-rst","patch_set":7,"id":"95c05de6_72c14bc6","line":285,"range":{"start_line":285,"start_character":7,"end_line":285,"end_character":103},"updated":"2024-03-28 09:10:20.000000000","message":"https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption-libvirt.html ?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":false,"context_lines":[{"line_number":282,"context_line":"References"},{"line_number":283,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":".. [1] https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html"},{"line_number":286,"context_line":".. [2] https://docs.openstack.org/nova/victoria/configuration/config.html#workarounds.disable_native_luksv1"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":".. list-table:: Revisions"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3001059f_e267792e","line":285,"range":{"start_line":285,"start_character":7,"end_line":285,"end_character":103},"in_reply_to":"95c05de6_72c14bc6","updated":"2024-05-14 14:29:07.000000000","message":"this is a link of eph-storage-encryption, which is updated again, so that why it was 2023.2, now its re-proposed and is 2024.2, which is yet to merge.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":302,"context_line":"     - Reproposed"},{"line_number":303,"context_line":"   * - 2024.1 Caracal"},{"line_number":304,"context_line":"     - Reproposed"},{"line_number":305,"context_line":"   * - 2024.2 Dalmation"},{"line_number":306,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8b5bfab7_1521d571","line":305,"range":{"start_line":305,"start_character":14,"end_line":305,"end_character":23},"updated":"2024-03-28 17:45:24.000000000","message":"Dalmatian","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":false,"context_lines":[{"line_number":302,"context_line":"     - Reproposed"},{"line_number":303,"context_line":"   * - 2024.1 Caracal"},{"line_number":304,"context_line":"     - Reproposed"},{"line_number":305,"context_line":"   * - 2024.2 Dalmation"},{"line_number":306,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":7,"id":"99f391bb_7fec8129","line":305,"range":{"start_line":305,"start_character":14,"end_line":305,"end_character":23},"in_reply_to":"8b5bfab7_1521d571","updated":"2024-05-15 11:37:48.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e7475ac99373df5c5c02ccd9bd40eab9aabb9b78","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"eb147064_8931b92c","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"updated":"2024-05-20 16:43:54.000000000","message":"This is sort of a nit, but it\u0027s something I\u0027ve seen used around this stuff. This is not the proper use of \"symmetric key\". I think what this is referencing is \"the same key for every instance\" but that has nothing to do with it being a symmetric key. AFAIK, all the keys we\u0027re talking about here are \"symmetric\" in that they\u0027re not \"asymmetric\" i.e. have a public/private pairing.\n\nhttps://en.wikipedia.org/wiki/Public-key_cryptography","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d892408f6f0409886a04c5f8330faf43ce4793ae","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"7a630472_1c6e1396","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"04c621c3_925fecfb","updated":"2024-05-21 14:17:05.000000000","message":"Right, as I said, all of these keys are symmetric in that all of this cryptography is symmetric (i.e. one key for both encryption/decryption instead of a public/private pair). The thing I was trying to point out is that the wording here seems to imply a difference between the old implementation and the new one, and that the symmetry is one of those differences, which it\u0027s not.\n\nIn trying to figure out why \"symmetric\" was being used here, I was surmising that it might be because all the instances on a single host use the same key (symmetric, but the wrong use of it in this context). However, re-reading this today, I think the words are actually pointing to the fact that the legacy stuff stores the _actual_ key, where the new stuff stores the passphrase that _encrypts_ the _actual_key (which is just a difference between dmcrypt and LUKS in how they do things). That doesn\u0027t make it *not* symmetric key cryptography or make any of these keys not symmetric. The passphase is a symmetric key to encrypt some text, which is itself another symmetric key which is used to encrypt the actual disk contents.\n\nI think it\u0027s confusing to say it this way because of that implication and because \"symmetric\" has a specific meaning in cryptography. Like, if you mention nothing about the key types and then say \"this thing over here is different because it stores a symmetric key\" I think it\u0027s easy to imply that the difference _is_ the symmetric key.\n\nJust `s/a symmetric key/the actual key/` would remove that ambiguity for me and also properly mirror the last sentence, which says \"...and LUKS does not directly use the provided (i.e. stored in barbican) key\".","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"93680d3a325b82d18f4e5cccd2efe5a1a88c6231","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"dcc1adf2_7648eebc","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"04c621c3_925fecfb","updated":"2024-05-22 14:22:19.000000000","message":"the same key for all instnace on a host is only true if you use the fixed key keymanager instead of barbican in the context of lvm","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"932aafbcbb9f812b6e76e79166d96c03d2e2d5d3","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"282d8f95_c740a792","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"4d88e4e4_000a6aa8","updated":"2024-05-22 13:46:44.000000000","message":"\u003e Right, I know. I know they are all symmetric cryptography. What was trying to say is that neither legacy LVM encryption nor Cinder volume encryption use the same key for all instances on the same host. A new key is created per instance. A new key is created per volume. So there is no way that the use of the word \"symmetric\" here is about multiple instances using the same key.\n\nOh, perhaps I was misunderstanding the current situation and applied that here, my bad. I was sure elsewhere in this spec (pair) it said that the legacy ephemeral encryption used the same key for each instance on the host and that was one of the specific reasons to be re-implementing it with this much more complex scheme. Looking over, I guess it was saying \"same type\", which doesn\u0027t really seem like a problem to me (we\u0027re only really supporting one type with the new stuff to). Perhaps I took that non-problem and removed \"type\" to arrive at \"same key.\" I dunno 🤷\n\nI guess that makes me wonder if this effort is really worthwhile, as the core bit of what Sean seems most concerned about (i.e. an instance\u0027s disk is encrypted at rest) with a unique key is already done. I guess this gets us out of it needing to be backed by LVM.\n\n\u003e That said, I spent some time reading through the code and docs about cryptsetup and LUKS and arrive at the same conclusion that most likely the point this paragraph was trying to make is about direct vs indirect use of the Barbican data for the encryption.\n\n\u003e Based on that I don\u0027t think \"the actual key\" is exactly correct either because dm-crypt plain uses a non-salted hash of the provided passphrase (unless you go out of your way to tell it not to hash it) but it\u0027s much closer to the actual key than what LUKS does.\n\nYeah, you could say that\u0027s not the actual key, but at that point, the hash is almost just an encoding -- a direct 1:1 way of transforming one thing into another, like hexlifying it.\n\n\u003e I agree that the word \"symmetric\" in the existing text is not really adding value and may be adding confusion, so I\u0027ll remove it and adjust the text a bit.\n\nYeah, I mean, regardless of what I thought it was trying to call out, and then later the different thing I thought it was trying to call out, the use of symmetric here as if it\u0027s something different is still a point of confusion. So, let\u0027s change it and pretend this never happened :)","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"44a10a5048c5a0e88a8377fd76f47a543175e8bf","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"4d88e4e4_000a6aa8","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"7a630472_1c6e1396","updated":"2024-05-22 04:07:39.000000000","message":"\u003e Right, as I said, all of these keys are symmetric in that all of this cryptography is symmetric (i.e. one key for both encryption/decryption instead of a public/private pair). The thing I was trying to point out is that the wording here seems to imply a difference between the old implementation and the new one, and that the symmetry is one of those differences, which it\u0027s not.\n\nRight, I know. I know they are all symmetric cryptography. What was trying to say is that neither legacy LVM encryption nor Cinder volume encryption use the same key for all instances on the same host. A new key is created per instance. A new key is created per volume. So there is no way that the use of the word \"symmetric\" here is about multiple instances using the same key.\n\nI think the use of the word \"symmetric\" here refers to the Barbican \"symmetric\" secret type.\n\n\u003e In trying to figure out why \"symmetric\" was being used here, I was surmising that it might be because all the instances on a single host use the same key (symmetric, but the wrong use of it in this context). However, re-reading this today, I think the words are actually pointing to the fact that the legacy stuff stores the _actual_ key, where the new stuff stores the passphrase that _encrypts_ the _actual_key (which is just a difference between dmcrypt and LUKS in how they do things). That doesn\u0027t make it *not* symmetric key cryptography or make any of these keys not symmetric. The passphase is a symmetric key to encrypt some text, which is itself another symmetric key which is used to encrypt the actual disk contents.\n\u003e \n\u003e I think it\u0027s confusing to say it this way because of that implication and because \"symmetric\" has a specific meaning in cryptography. Like, if you mention nothing about the key types and then say \"this thing over here is different because it stores a symmetric key\" I think it\u0027s easy to imply that the difference _is_ the symmetric key.\n\u003e \n\u003e Just `s/a symmetric key/the actual key/` would remove that ambiguity for me and also properly mirror the last sentence, which says \"...and LUKS does not directly use the provided (i.e. stored in barbican) key\".\n\nThat said, I spent some time reading through the code and docs about cryptsetup and LUKS and arrive at the same conclusion that most likely the point this paragraph was trying to make is about direct vs indirect use of the Barbican data for the encryption.\n\nIn all cases (LVM, Cinder volume, local disk) the Barbican data is used as a passphrase. I read this doc to learn the difference between passphrase processing in dm-crypt plain vs LUKS: https://man7.org/linux/man-pages/man8/cryptsetup.8.html#NOTES.\n\nBased on that I don\u0027t think \"the actual key\" is exactly correct either because dm-crypt plain uses a non-salted hash of the provided passphrase (unless you go out of your way to tell it not to hash it) but it\u0027s much closer to the actual key than what LUKS does.\n\nI agree that the word \"symmetric\" in the existing text is not really adding value and may be adding confusion, so I\u0027ll remove it and adjust the text a bit.\n\nAside: I\u0027m not sure it\u0027s fair of the existing text to say \"a long running piece of technical debt in the encrypted volume implementation\" given that Cinder actively supports both dm-crypt plain and LUKS, so their implementation should still do what it\u0027s currently doing in the dm-crypt plain case. And they\u0027re just using the same method to create secrets in either case. I guess one could argue they should add an additional method to use the Barbican \"passphrase\" secret type in the LUKS case.","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b67913a6ddf9d2d6fabdb89104ee8af671222072","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"2f965ce1_31ba39c3","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"dcc1adf2_7648eebc","updated":"2024-06-04 14:12:30.000000000","message":"Ah perhaps that was stuck in my head.","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"df6ac68990c713bef9853210a1a4903fcf2f9f2c","unresolved":true,"context_lines":[{"line_number":136,"context_line":"encryption secret within the configured key manager. The initial ``LUKSv1``"},{"line_number":137,"context_line":"support will store a passphrase for each disk within the key manager. This is"},{"line_number":138,"context_line":"unlike the current ephemeral storage encryption or encrypted volume"},{"line_number":139,"context_line":"implementations that currently store a symmetric key in the key manager. This"},{"line_number":140,"context_line":"remains a long running piece of technical debt in the encrypted volume"},{"line_number":141,"context_line":"implementation as ``LUKSv1`` does not directly encrypt data with the provided"},{"line_number":142,"context_line":"key."}],"source_content_type":"text/x-rst","patch_set":10,"id":"04c621c3_925fecfb","line":139,"range":{"start_line":139,"start_character":39,"end_line":139,"end_character":48},"in_reply_to":"eb147064_8931b92c","updated":"2024-05-21 02:44:17.000000000","message":"I checked the legacy LVM ephemeral encryption code last week and found it uses a different key per instance. Cinder volume encryption also uses a different key per volume. So \"symmetric\" here must be referring to something else.\n\nAfter doing some searching I think this may be talking about the Barbican \"symmetric\" secret type:\n\nhttps://docs.openstack.org/barbican/latest/api/reference/secret_types.html\n\nwhich is a byte array that has to be hexlified and unhexlified. In libvirt driver code for Cinder volume encryption, a comment notes the conversion (hex \u003d\u003e string) that has to take place before passing the secret to libvirt [1]. The os-brick LuksEncryptor code also has to convert the secret before use with cryptsetup [2].\n\nLegacy LVM encryption secret generation creates the same type of key [3] (Barbican secret type \"symmetric\").\n\nSo this paragraph may be pointing out that Nova local encryption will use the \"passphrase\" Barbican secret type which does not have to be converted instead of using the \"symmetric\" secret type.\n\n[1] https://github.com/openstack/nova/blob/61ad4f1f2731ec40fdd6a69b0b51380aca17e690/nova/virt/libvirt/driver.py#L2152-L2161\n[2] https://github.com/openstack/os-brick/blob/e81fc02105cd6370e615e2cea72b181ffc786297/os_brick/encryptors/luks.py#L163-L165\n[3] https://github.com/openstack/nova/blob/61ad4f1f2731ec40fdd6a69b0b51380aca17e690/nova/compute/api.py#L2088-L2091","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"}],"specs/2024.2/approved/ephemeral-storage-encryption.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"   Separate image properties have been documented in the"},{"line_number":85,"context_line":"   `Glance image encryption`_ and `Cinder image encryption`_ specs to cover"},{"line_number":86,"context_line":"   how images can be encrypted at rest within Glance."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Allow ephemeral encryption to be configured by flavor, image, or config"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6607da30_d1d9dd08","line":86,"updated":"2024-03-27 14:51:24.000000000","message":"I\u0027m not sure if this is right. First, the glance spec link is 404 for me, and it\u0027s also not completed on the glance side. Further, the `os_glance_*` properties are readonly from the outside, so nova won\u0027t be able to set them directly to communicate anything.\n\nIIRC from the code, you *are* using these `hw_ephemeral_encryption_*` keys to know if the image is encrypted and how, right? So what is this paragraph actually saying?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"   Separate image properties have been documented in the"},{"line_number":85,"context_line":"   `Glance image encryption`_ and `Cinder image encryption`_ specs to cover"},{"line_number":86,"context_line":"   how images can be encrypted at rest within Glance."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Allow ephemeral encryption to be configured by flavor, image, or config"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"80a5ca6e_8b64aef8","line":86,"in_reply_to":"5a444078_dc6e267f","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5ca8a2be2ba08d5268f3e18be67ecd0180abdb26","unresolved":true,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"   Separate image properties have been documented in the"},{"line_number":85,"context_line":"   `Glance image encryption`_ and `Cinder image encryption`_ specs to cover"},{"line_number":86,"context_line":"   how images can be encrypted at rest within Glance."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Allow ephemeral encryption to be configured by flavor, image, or config"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a444078_dc6e267f","line":86,"in_reply_to":"637fc33d_04bddaf0","updated":"2024-05-01 18:31:31.000000000","message":"are we just going to remove this paragraph.\n\ni dont think it adds much","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"   Separate image properties have been documented in the"},{"line_number":85,"context_line":"   `Glance image encryption`_ and `Cinder image encryption`_ specs to cover"},{"line_number":86,"context_line":"   how images can be encrypted at rest within Glance."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Allow ephemeral encryption to be configured by flavor, image, or config"},{"line_number":89,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"637fc33d_04bddaf0","line":86,"in_reply_to":"6607da30_d1d9dd08","updated":"2024-03-27 19:12:09.000000000","message":"Hm, yeah ... this was in the original spec proposal, back when it had no mention of snapshots of encrypted instances (and thus no `hw_ephemeral_encryption_secret_uuid` at the time).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"54eb5137_d989cb00","line":116,"updated":"2024-03-27 14:51:24.000000000","message":"I still question the utility of the format key on the flavor, but I think it\u0027s necessary on the image per above because it controls how or where we can use it.\n\nTBH, it kinda feels like maybe glance should have a different container_format for \"luks\" or something...","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5ca8a2be2ba08d5268f3e18be67ecd0180abdb26","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dce673e4_2927691d","line":116,"in_reply_to":"219dd2ba_f5f9077b","updated":"2024-05-01 18:31:31.000000000","message":"its kind of a trade off between flavor and image encyption\n\nin theory if we use luks or not is transparent to the guest.\n\nwe usually express things that are visible to the guest in image metadata\n\ni.e. hw_vif_model\u003de1000 because ti image need to have that driver to work\n\nbut if its not visable to the guest we supprot it in the flavor or both i.e cpu pinnig or hugepages as example\n\nim not sure if we have use case liek\n\n\"as an operator i want to charge more for disk encyption to accont for the addtioal cost in storage and oeprational overhaead\"\n\nor \n\n\"as a operator i want ot configure disk encyrpiton vai the flavor to be able to offer standard flavor that meet regeltorry requiremets for encyption at rest.\"\n\nthose type of usecase would avocate for allowing it in the flavor.\n\npersonaly i think of the 3 options the one i like lest is the config option as that requires us to recored the value that was used when the db was created in the db somewhre based on the host we boot on.\n\nso my prefernce list is flavor \u003e image \u003e host option \n\nbut im not aginst supproting all 3\n\nif its set to diffent values in teh flavor and image then that shoudl be a 400 or 409 error in the api.\n\nthe host option should only be used if its nto specified in the image or flavor\nand when the instance is botted we whoudl back populate the image proeprty in the instance_system_metadta just like we do for the machine type.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"799ba875407cf4f6f8e19f05c30b1766fbcd7a84","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"616830d0_378c24c7","line":116,"in_reply_to":"489575d3_d93d3e58","updated":"2024-05-15 18:31:59.000000000","message":"Yes, sorry, I didn\u0027t think we are suggesting anything different regarding the image properties that describe the image itself. We are going to set the Glance standardized image properties when producing an encrypted snapshot image. And we will also use them when we are creating a local disk from an encrypted image.\n\nI thought we were talking about the other side of it, like you pointed out, the format of the disk we will be creating from an image. I thought Dan was saying it may be sufficient and/or better to have that be a boolean \"encrypt this\" flavor/image property rather than allowing a choice of destination format. And that the destination format is internal to how Nova is configured to create images (`[ephemeral_storage_encryption]default_format`).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"219dd2ba_f5f9077b","line":116,"in_reply_to":"54eb5137_d989cb00","updated":"2024-03-27 19:12:09.000000000","message":"Yeah. I could see it making sense to have its own format from a Glance image perspective also.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"78b74ff7_17564a85","line":116,"in_reply_to":"616830d0_378c24c7","updated":"2024-05-20 16:28:30.000000000","message":"Right, I think the boolean flag for \"encrypt this instance\u0027s disk however the hypervisor does that\" is sufficient/desirable in the flavor. On the image (I don\u0027t distinguish between a snapshot and any other type of image, since they\u0027re not distinct), I think we should use the standard glance properties as being defined.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae8a303b9597835549a21d614091e382de4f03c2","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d10c0a72_ee041539","line":116,"in_reply_to":"78b74ff7_17564a85","updated":"2024-05-20 17:25:51.000000000","message":"so to me hw_ephemeral_encryption_format\u003dluks is not the same as os_glance_encrypt_format\u003dluks\n\nimage a with os_glance_encrypt_format\u003dluks means the image in glance is encypted in luks formate\n\nimage b  with hw_ephemeral_encryption_format\u003dluks means when creating an disk form this image it should be encypted with luks on the compute node.\n\n\nif the image has os_glance_encrypt_format\u003dluks  but not hw_ephemeral_encryption_format\u003dluks (assuming there is noting in the flavor or config) the i would expect use to decypt the image when creating the vm root disk.\n\n\nto me the os_glance* image properties defien how the image is stored in glance but nothing related to how the vm root disk is created form the image.\n\nif that is not the intent then we need to make that clear in the spec.\n\ni would not consider it correct today if os_glance_encrypt_format modifed the format of the vm disk.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"fd6987d5_177f3654","line":116,"in_reply_to":"b370135a_500fbe19","updated":"2024-05-14 20:51:55.000000000","message":"I see your point ... the utility of format in the flavor would seem to only apply in a multi-backend Nova deployment (since \"plain\" is the existing LVM backend stuff as I understand it). Otherwise it\u0027s implied by the one available backend in the deployment.\n\nAs far as I can tell, it is possible to snapshot LVM encrypted instances but I don\u0027t see the Barbican key UUID being recorded anywhere with the image. Shelve/unshelve works because the encryption key UUID is stored on the instance. But it doesn\u0027t seem like one could snapshot an encrypted LVM instance and then boot a new different instance from that encrypted image because there\u0027s no indication what Barbican secret is needed for the image.\n\nSo really it seems like the only purpose for flavor encryption format would be to decide where to schedule a new instance in a multi-backend Nova deployment. If the flavor requests plain format encryption, schedule to compute host with LVM backend, if flavor requests luks format encryption, schedule to compute host with qcow2|raw|rbd backend. And I\u0027m not sure how likely it is that this was the intended purpose of format in the flavor.\n\nI\u0027m leaning toward dropping format from the flavor pending discussion with sean-k-mooney and making really really sure we all agree and are not missing anything before removing it from the patch series.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8f1693a92796f0d66e2fd24ce57536061fe9fc81","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8714f815_4ecf10aa","line":116,"in_reply_to":"c4e18a2a_4d18b12c","updated":"2024-05-15 13:51:33.000000000","message":"\u003e hw:ephemeral_encryption_format\u003dluks in the flavor say regardless of what image is used I expect this VM to be booted with a luks encrypted root/ephemeral disks\n\nRight, except that it can\u0027t really (reasonably) conflict with (i.e. be independent of) the image format, if it has one.\n\n\u003e hw_ephemeral_encryption_format\u003dluks  means the same thing but it is expressed on the glance image.\n\u003e that however does not mean the glance image is luks encypted.\n\nI don\u0027t think that\u0027s true. If we don\u0027t have this on the image, we won\u0027t know *how* to interpret an image. Meaning if there\u0027s a glance image in some vmware-specific encryption format, or some post-LUKS future format, we need to know about it so we know what to tell qemu (and other tooling).\n\n\u003e we need separate image properties on the image to describe what format the encrypted image is in, we cannot share them otherwise we cant express the difference i described above.\n\nWell, I think your point is actually valid in that they do represent two different requests. If you have an image that isn\u0027t encrypted and you want encrypted disk in your instance, I guess you need a flavor property to say \"this should be encrypted\". However, I think maybe it would be easier and less confusing if that was a boolean, or at least something other than \"format\" and named differently from the glance property. That may actually come naturally based on another piece of feedback I left, which is that we should be using the agreed-upon generic image property names for these things instead of our own, as currently expressed in this spec.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bb3854c770b403ba3c61cef0c52bd5cb3ec628cd","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2260db86_570e45c7","line":116,"in_reply_to":"d10c0a72_ee041539","updated":"2024-05-20 17:37:20.000000000","message":"\u003e so to me hw_ephemeral_encryption_format\u003dluks is not the same as os_glance_encrypt_format\u003dluks\n\u003e \n\u003e image a with os_glance_encrypt_format\u003dluks means the image in glance is encypted in luks formate\n\u003e \n\u003e image b  with hw_ephemeral_encryption_format\u003dluks means when creating an disk form this image it should be encypted with luks on the compute node.\n\u003e \n\u003e \n\u003e if the image has os_glance_encrypt_format\u003dluks  but not hw_ephemeral_encryption_format\u003dluks (assuming there is noting in the flavor or config) the i would expect use to decypt the image when creating the vm root disk.\n\nSeriously? I do not think this is the behavior users would expect. I understand the distinction you\u0027re making here (format of the image vs. intent for the new instance) but I guess I don\u0027t think the users will \"appreciate\" that tripwire. Since I think users see openstack as one thing (even if it\u0027s a poorly-integrated box of parts) we should try not to create more things like this. The hoops one has to jump through to get an instance reachable over the network is a good example of that anti-pattern I think.\n\n\u003e to me the os_glance* image properties defien how the image is stored in glance but nothing related to how the vm root disk is created form the image.\n\u003e \n\u003e if that is not the intent then we need to make that clear in the spec.\n\u003e \n\u003e i would not consider it correct today if os_glance_encrypt_format modifed the format of the vm disk.\n\nBut above you say that if the `hw_` is not specified, then we should decrypt the disk even if `os_glance` says it\u0027s encrypted. That\u0027s sort of the same thing right?\n\nIf you take the example of snapshotting a cinder volume to use as a bootable image, someone would have an encrypted volume, snapshotted to an encrypted glance image, which would then boot in *cleartext* if they didn\u0027t go add the `hw_` property right? That seems confusing and error-prone to me. Designing something where it\u0027s easy (read not-default) to drop encryption if you fail to do something seems like a bad idea to me. Since you can boot from an encrypted image and then snapshot with \"make me a cleartext image from this\" as an option, that seems to me like the exit path, if so desired.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b370135a_500fbe19","line":116,"in_reply_to":"dce673e4_2927691d","updated":"2024-05-14 18:48:48.000000000","message":"AFAIK, The format *has* to be on the image, if the image is encrypted so that we know how to interpret what is inside.\n\nTo me, the flavor makes the least sense, and would only be relevant if you had two types of compute nodes that were otherwise compatible but provided different strategies. I don\u0027t think that\u0027s possible (or even conceivable) today and thus it seems superfluous and too complicated to have the flavor thing. To me, it seems like the image property is all that matters, and some host-based config that says \"use this kind\" that directs the compute node on what to do (and thus gets stamped on the image at snapshot) might make sense. However, if there\u0027s only one option at present, it too seems unnecessary to even have that.\n\nUnless \"plain\" (below) provides us a way to snapshot existing instances to glance and make those images reusable, but I think that\u0027s not actually going to work.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d802841be6cf8dd2bec10e4944c304b35d498610","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"489575d3_d93d3e58","line":116,"in_reply_to":"efe6e20a_dff42985","updated":"2024-05-15 18:12:50.000000000","message":"we do but we still need to be able to supprot \n\na glance encyped image that uses format X to boot a vm with Format Y\n\n\nhw_ephemeral_encryption  is the boolean ot say the vm created form this image should be encypted but it does not tell you if the image is encypted.\n\nsimialrly  hw_ephemeral_encryption_format woudl tell you want format to use for the local disk when creating it in nova but it tell you nothihng about the format of encyption used if any in the glance image.\n\nbased on this glance spec\n\nhttps://github.com/openstack/glance-specs/blob/master/specs/2024.1/approved/glance/image-encryption.rst?plain\u003d1#L89-L94\n\nthe encytion format of an encypted glance image should be specified by\n\n\n\n* \u0027os_glance_encrypt_format\u0027 - the main mechanism used, e.g. \u0027GPG\u0027\n* \u0027os_glance_encrypt_type\u0027   - encryption type, e.g. \u0027symmetric\u0027\n* \u0027os_glance_encrypt_cipher\u0027 - the cipher algorithm, e.g. \u0027AES256\u0027\n* \u0027os_glance_encrypt_key_id\u0027 - reference to key in the key manager\n* \u0027os_glance_decrypt_container_format\u0027 - format after payload decryption\n* \u0027os_glance_decrypt_size\u0027 - size after payload decryption\n\nso if we are creating a encypted snapshot we shoudl likely be setting those\nand if a non encypted snapshot we should leve them unset\n\nwe should probably copy hw_ephemeral_encryption and hw_ephemeral_encryption_format\nfrom the orginal image ro the cached image properties\nbut we have a choice there\n\nwe do filter some imgage peroperies when creating snapshots in other cases i belive so we could decied if we want to propagate them ot the snapshot or not.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"efe6e20a_dff42985","line":116,"in_reply_to":"fd6987d5_177f3654","updated":"2024-05-15 17:50:25.000000000","message":"Note to self: it seems like it would be possible to add the encryption secret UUID to the snapshot image properties for LVM so that it gets the same abilities as the new qcow2|raw|rbd scheme. I\u0027m not sure if there are any pitfalls with the idea of doing that.\n\n\u003e Well, I think your point is actually valid in that they do represent two different requests. If you have an image that isn\u0027t encrypted and you want encrypted disk in your instance, I guess you need a flavor property to say \"this should be encrypted\". However, I think maybe it would be easier and less confusing if that was a boolean, or at least something other than \"format\" and named differently from the glance property. That may actually come naturally based on another piece of feedback I left, which is that we should be using the agreed-upon generic image property names for these things instead of our own, as currently expressed in this spec.\n\nThere is actually already a boolean `hw:ephemeral_encryption` and `hw_ephemeral_encryption` in this spec to say, \"I want this to be encrypted\", so I think we\u0027re covered there.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"This could lead to requests against different clouds resulting in a different"},{"line_number":115,"context_line":"ephemeral encryption format being used but as this is transparent to the end"},{"line_number":116,"context_line":"user from within the instance it shouldn\u0027t have any real impact."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"The format will be provided as a string that maps to a"},{"line_number":119,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c4e18a2a_4d18b12c","line":116,"in_reply_to":"fd6987d5_177f3654","updated":"2024-05-15 11:37:48.000000000","message":"honsetly I think we are mixing two thing.\n\nspecifying the format to use when creating the local disk has noting to do with if the image is encrypted or what format the image is encrypted with.\n\nhw:ephemeral_encryption_format\u003dluks in the flavor say regardless of what image is used I expect this VM to be booted with a luks encrypted root/ephemeral disks\nhw_ephemeral_encryption_format\u003dluks  means the same thing but it is expressed on the glance image.\nthat however does not mean the glance image is luks encypted.\n\n\ndo we all agree that hw_ephemeral_encryption_format\u003dluks is valid on a non encypted glance image?\n\n\nwe need separate image properties on the image to describe what format the encrypted image is in, we cannot share them otherwise we cant express the difference i described above.\n\norginally i advocated for removing the format form this spec entirly and we did in antelope because we were exiplcity decarlign lvm out os scope.\nim ok wiht bring it back to support the upgrade path for existng lvm usage but\nAs I said i strongly dislike having the config option,\nthe image property is fine but the flavour is how I would configure this if i ever intended to specify a format explicitly.\n\ni really don\u0027t like the level config option that materially changes domain xml content. they cause interop and live migration problems espcially if we dont recored the values in the db to fix the values for the lifetime of the vm.\nso as we have done for machine type, when we use the defautl for mteh config option we need to populate the instance_system_metadata table with the resultant value.\n\ni have not had time to fully read the updated spec by the way som im really just responding to this conversation.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":false,"context_lines":[{"line_number":251,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":252,"context_line":"   |                    | disk.swap   | Secret 3                             |                                                      |"},{"line_number":253,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":254,"context_line":"   | Image Z (snapshot) | disk (root) | Secret 4 (copy of Secret 1 **or**    | Secret 4 will **not** be automatically deleted and   |"},{"line_number":255,"context_line":"   | created from       |             | new passphrase)                      | manual deletion will be needed if/when Image Z is    |"},{"line_number":256,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"}],"source_content_type":"text/x-rst","patch_set":7,"id":"975b5143_9db9edfc","line":254,"updated":"2024-03-27 14:51:24.000000000","message":"Okay, this is changed from the previous version to reflect the discussion about not making this obligatory, yeah? (talking to myself)","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1de52a31_fca67f38","line":260,"updated":"2024-03-27 14:51:24.000000000","message":"It\u0027s really hard to tell in this unrendered version, but how does instance B\u0027s disk have two keys, new secret 5 and secret 6, copy of secret 4?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d57210e8_abc3d71e","line":260,"in_reply_to":"1de52a31_fca67f38","updated":"2024-03-27 19:12:09.000000000","message":"Secret 6 is for the backing file in the case of qcow2. It will be a new secret in the key manager service but its content (the actual passphrase) will be the same as Secret 4 (i.e. Instance A and Instance B share the same encrypted backing file).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4c2915d4_64199dff","line":260,"in_reply_to":"22ac8780_0012ab12","updated":"2024-03-28 17:45:24.000000000","message":"I don\u0027t understand what you\u0027re asking. The disk for Instance B has to have a backing file if it\u0027s qcow2 and that backing file has Secret 4. If we want to be able to clean up secrets when instances are deleted, we need to make a copy Secret 6 that belongs only to the instance.\n\nSecret 6 is a \"reference\" to Secret 4. They contain the same password inside but they are different objects in Barbican. Secret 4 is tied to the Glance image (Image Z in this table) and Secret 6 is Instance B\u0027s reference to it. Secret 6 will be deleted when Instance B is deleted.\n\nAre you saying you don\u0027t think each instance should have their own allocated reference to the backing file secret? If they don\u0027t, then if/when someone deletes Image Z from Glance (along with its secret, Secret 4) then any instances using that backing file would have lost the secret for it. If Instance B has its own copy, Secret 6, then it can continue to work even if someone deletes Image Z/Secret 4.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9130ba67_29576256","line":260,"in_reply_to":"4c2915d4_64199dff","updated":"2024-03-28 18:28:18.000000000","message":"Aha, I see. So the answer to the question of who we\u0027re going to charge is \"everyone.\" So the secret for the base image will be duplicated for everyone that uses it. If the user goes into barbican and says \"wtf, this isn\u0027t mine\" and deletes it, they will effectively break their instance\u0027s ability to reboot, and likely end up with data loss right? Or maybe a migration will fix it I guess, since we don\u0027t send the base image and would re-download/re-construct it on the destination?\n\nNot sure where I asked but I don\u0027t think I saw an answer... What indication does the user have in barbican what each thing is for? They can see the consumer, which we\u0027re setting to something right? Just trying to think about how we can make this not a foot gun.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":false,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d9920983_ad808613","line":260,"in_reply_to":"5893274d_3697f2d3","updated":"2024-05-14 18:48:48.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6c11015bae8bf82433427972bdffe0cd31b6b0ad","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ce53cee5_365007ff","line":260,"in_reply_to":"9130ba67_29576256","updated":"2024-03-28 20:18:15.000000000","message":"\u003e Aha, I see. So the answer to the question of who we\u0027re going to charge is \"everyone.\" So the secret for the base image will be duplicated for everyone that uses it. If the user goes into barbican and says \"wtf, this isn\u0027t mine\" and deletes it, they will effectively break their instance\u0027s ability to reboot, and likely end up with data loss right? Or maybe a migration will fix it I guess, since we don\u0027t send the base image and would re-download/re-construct it on the destination?\n\nI don\u0027t think there will be data loss if the user deletes Secret 6 because if you don\u0027t have the password, the instance will not be able to boot. You won\u0027t be able to boot but you won\u0027t mess up the disk (it can\u0027t do anything with the disk). Libvirt is able to raise an error that says \"Unable to unlock any key slot\" or similar.\n\nWe could be smarter though and say, if backing_encryption_secret_uuid is not found in Barbican, we pull Secret 4 (we can get the secret UUID by looking up the base image in Glance) and copy it again to make Secret 7 and then update backing_encryption_secret_uuid in the BDM. If we did that we would auto fix it for the user if it happens.\n\n\u003e Not sure where I asked but I don\u0027t think I saw an answer... What indication does the user have in barbican what each thing is for? They can see the consumer, which we\u0027re setting to something right? Just trying to think about how we can make this not a foot gun.\n\nWe\u0027re not using the consumer mechanism in the current revision. It\u0027s meant as a reference counting mechanism so I didn\u0027t use it. But I could use it to add an extra layer beyond the name for identifying what the secret is for.\n\nThere is a `name` request parameter when you create a secret [1] and currently it will say one of:\n\n* \"Ephemeral encryption secret for instance \u003cinstance uuid\u003e BDM \u003cbdm uuid\u003e\" [2]\n\n* \"Ephemeral encryption secret for image \u003cimage uuid\u003e\" [3] (i.e. a snapshot image)\n\n* \"Ephemeral encryption secret for instance \u003cinstance uuid\u003e BDM \u003cbdm uuid\u003e backing file\" [4]\n\nThey won\u0027t know what BDM UUID is maybe but it\u0027s still clearly stated the secret(s) are for their instance (trying to avoid foot guns).\n\n[1] https://docs.openstack.org/barbican/latest/api/reference/secrets.html#post-v1-secrets\n[2] https://review.opendev.org/c/openstack/nova/+/912094/1/nova/crypto.py#296\n[3] https://review.opendev.org/c/openstack/nova/+/870937/38/nova/virt/libvirt/driver.py#3373\n[4] https://review.opendev.org/c/openstack/nova/+/907961/20/nova/virt/libvirt/driver.py#5094","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0548dd224bd8604eea3fdbd86e4bd9154cf4de42","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"fa435c1e_71f33cc3","line":260,"in_reply_to":"ce53cee5_365007ff","updated":"2024-03-28 20:33:07.000000000","message":"\u003e I don\u0027t think there will be data loss if the user deletes Secret 6 because if you don\u0027t have the password, the instance will not be able to boot. You won\u0027t be able to boot but you won\u0027t mess up the disk (it can\u0027t do anything with the disk). Libvirt is able to raise an error that says \"Unable to unlock any key slot\" or similar.\n\nYou won\u0027t end up with data loss because you deleted the key to the thing that is just the image, that\u0027s correct. What I meant was that without a detailed stitching back together of the puzzle, I\u0027m not sure that the *user* has any way to recover from that situation. They likely can\u0027t rescue or reboot, they *might* be able to resize to another host, if we don\u0027t choke on not being able to access the now-deleted secret on the host. It would probably require a skilled admin knowing what has happened and/or manually extracting their disk, re-basing it on a copy of the image and making it available for them. That\u0027s the scenario I was thinking of.\n\n\u003e We could be smarter though and say, if backing_encryption_secret_uuid is not found in Barbican, we pull Secret 4 (we can get the secret UUID by looking up the base image in Glance) and copy it again to make Secret 7 and then update backing_encryption_secret_uuid in the BDM. If we did that we would auto fix it for the user if it happens.\n\nAck, sounds better.\n\n\u003e We\u0027re not using the consumer mechanism in the current revision. It\u0027s meant as a reference counting mechanism so I didn\u0027t use it.\n\nOh, and you\u0027re not using it because of why, the confusion of ownership? To me, a refcounting scheme sounds better than copying all these secrets all the time, for a lot of reasons. But, I know that since we\u0027re using them across users (admins for admin things, regular users for base images, etc) it might not fit as well.\n\n\u003e But I could use it to add an extra layer beyond the name for identifying what the secret is for.\n\u003e \n\u003e There is a `name` request parameter when you create a secret [1] and currently it will say one of:\n\u003e \n\u003e * \"Ephemeral encryption secret for instance \u003cinstance uuid\u003e BDM \u003cbdm uuid\u003e\" [2]\n\u003e \n\u003e * \"Ephemeral encryption secret for image \u003cimage uuid\u003e\" [3] (i.e. a snapshot image)\n\u003e \n\u003e * \"Ephemeral encryption secret for instance \u003cinstance uuid\u003e BDM \u003cbdm uuid\u003e backing file\" [4]\n\u003e \n\u003e They won\u0027t know what BDM UUID is maybe but it\u0027s still clearly stated the secret(s) are for their instance (trying to avoid foot guns).\n\nAh, sorry I guess I missed that in the code then, that will help a lot. ISTR in my testing I wasn\u0027t seeing the name in the secret list commands I was doing, but perhaps it\u0027s there in a detail view or show on the secret? Or maybe I just missed it. In that case, that\u0027ll definitely help. A disclaimer on the foot-gun, so to speak.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"22ac8780_0012ab12","line":260,"in_reply_to":"d57210e8_abc3d71e","updated":"2024-03-28 14:37:36.000000000","message":"Okay, but why? And who are you going to \"charge\" that secret to? The first user that booted an instance on that compute node from that image? What happens if they delete it a week later not knowing what it\u0027s for?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"390f6388049f872cdcae4831ea112776f4befab7","unresolved":true,"context_lines":[{"line_number":257,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":258,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":259,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":260,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":261,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"},{"line_number":262,"context_line":"   |                    | disk.eph0   | Secret 7                             |                                                      |"},{"line_number":263,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5893274d_3697f2d3","line":260,"in_reply_to":"fa435c1e_71f33cc3","updated":"2024-03-28 22:37:28.000000000","message":"\u003e You won\u0027t end up with data loss because you deleted the key to the thing that is just the image, that\u0027s correct. What I meant was that without a detailed stitching back together of the puzzle, I\u0027m not sure that the *user* has any way to recover from that situation. They likely can\u0027t rescue or reboot, they *might* be able to resize to another host, if we don\u0027t choke on not being able to access the now-deleted secret on the host.\n\nYeah. I realized that the user\u0027s instance will continue to work normally as long as it stays on the compute host it\u0027s on because the secret is stored locally in libvirt. They won\u0027t however be able to move their instance because we\u0027ll try to query the secret from Barbican on the destination. So requests to move it will fail.\n\n\u003e It would probably require a skilled admin knowing what has happened and/or manually extracting their disk, re-basing it on a copy of the image and making it available for them. That\u0027s the scenario I was thinking of.\n\nIt would require an admin but I don\u0027t think rebasing the disk is necessary. What they would need to do is 1) pull the passphrase from Barbican using hw_ephemeral_encryption_secret_uuid from the image ref, 2) create a new Barbican secret with that passphrase, 3) update the BDM record with the new secret UUID, 4) virsh create a libvirt secret with the passphrase and the new secret UUID, 5) virsh delete the secret with the old UUID.\n\nNot a fun experience, I know. But if a user goes into Barbican and deletes a secret that says \"Ephemeral encryption secret for instance \u003cinstance uuid\u003e BDM \u003cbdm uuid\u003e backing file\" then I think it wouldn\u0027t be surprising that recovery would take some effort.\n\nBut all of that is probably moot because I think we could detect the problem and fix it automatically.\n\n\u003e Oh, and you\u0027re not using it because of why, the confusion of ownership? To me, a refcounting scheme sounds better than copying all these secrets all the time, for a lot of reasons. But, I know that since we\u0027re using them across users (admins for admin things, regular users for base images, etc) it might not fit as well.\n\nTo be clear, a copy only happens for an encrypted source image to generate a unique backing file secret object for an instance.\n\nI think depending entirely on the reference count feels too risky. The count is incremented and decremented by REST API calls and if that becomes wrong at any point, the count will be wrong.\n\nIn the best case, the count will be erroneously high and we\u0027ll never think we can clean up that secret because the ref count will never reach zero. In the worst case, the count will be erroneously low and someone will think it\u0027s safe to delete a secret that is still actively being used.\n\nIt just seems like it could become a big mess pretty easily, with data loss being a lot more likely if someone deletes something they shouldn\u0027t have. If they do that, the source of truth for the passphrase is gone and anything relying on it is going to be in trouble.\n\nAnd besides all of that, if the count ever becomes wrong, how is someone going to fix that? Do an audit of all instances and images referencing a secret and then correct it?\n\nIMHO I don\u0027t think the risk is worth it considering the stakes. I would prefer to be as defensive as possible and/or as conservative as possible, because a mistake in deleting Barbican secrets is one of the worst things that can happen or can cause the worst things that can happen. If we use copies, then it kind of insulates each instance and the blast radius is a lot smaller.\n\n\u003e Ah, sorry I guess I missed that in the code then, that will help a lot. ISTR in my testing I wasn\u0027t seeing the name in the secret list commands I was doing, but perhaps it\u0027s there in a detail view or show on the secret? Or maybe I just missed it. In that case, that\u0027ll definitely help. A disclaimer on the foot-gun, so to speak.\n\nI dunno, it shows it for me (note that the first two secrets are for something else, not ephemeral encryption, that I\u0027m not sure what it is):\n\n```\n$ openstack --os-cloud devstack secret list --sort-descending --sort-column Created --limit 50\n+----------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+---------------------------+--------+-----------------------------------------+-----------+------------+-------------+------+------------+\n| Secret href                                                                      | Name                                                                                                                                | Created                   | Status | Content types                           | Algorithm | Bit length | Secret type | Mode | Expiration |\n+----------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+---------------------------+--------+-----------------------------------------+-----------+------------+-------------+------+------------+\n| http://192.168.56.11/key-manager/v1/secrets/c5546ce5-8096-46dd-8972-a2aa665f70cd | None                                                                                                                                | 2024-03-18T23:58:34+00:00 | ACTIVE | {\u0027default\u0027: \u0027application/octet-stream\u0027} | aes       |        256 | symmetric   | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/a47d8e53-f45e-4051-8606-1902b90bfa32 | None                                                                                                                                | 2024-03-18T23:42:30+00:00 | ACTIVE | {\u0027default\u0027: \u0027application/octet-stream\u0027} | aes       |        256 | symmetric   | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/da8ea703-53a3-42a4-b7d1-5cdb55dfc43c | Ephemeral encryption secret for image 70a04d3c-e667-4def-9e18-2ccf27e4cb1a                                                          | 2024-03-02T01:14:53+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/43a73090-23c6-44f3-8d3a-f123fd676ec6 | Ephemeral encryption secret for instance 3bed2d08-197b-4881-9363-08c060e9352d BDM 60ed5ea3-f6ae-47c4-a334-270be25fc626              | 2024-03-02T01:12:26+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/60bc3c92-9faa-40f9-93ea-f95ef44aa78c | Ephemeral encryption secret for instance 3bed2d08-197b-4881-9363-08c060e9352d BDM 90c3aaef-c304-4dd9-a013-1710b9f2285d              | 2024-03-02T01:12:26+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/e0169705-36d0-4d7e-9924-caec831cf7a8 | Ephemeral encryption secret for instance 3bed2d08-197b-4881-9363-08c060e9352d BDM f361fd38-42d8-49df-941f-fcd7bcf2ba09              | 2024-03-02T01:12:26+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/01da7646-0175-4882-bb67-758307521489 | Ephemeral encryption secret for instance 52e339b9-cda8-4cf5-9e64-f40c352ac63c BDM 6851f58d-fb23-4d9a-a2d2-327c544d5d46              | 2024-02-29T05:54:50+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/c564dc90-4daa-46aa-9ec1-eb456fed1ab6 | Ephemeral encryption secret for instance 52e339b9-cda8-4cf5-9e64-f40c352ac63c BDM fe7cdece-557c-4fc7-bdb4-46a087d52b2c backing file | 2024-02-29T05:54:50+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n| http://192.168.56.11/key-manager/v1/secrets/d4483417-9d9e-487c-9c65-17004494ae32 | Ephemeral encryption secret for instance 52e339b9-cda8-4cf5-9e64-f40c352ac63c BDM 95750c94-55dc-4bfb-ba0c-0a3cb873f370              | 2024-02-29T05:54:50+00:00 | ACTIVE | {\u0027default\u0027: \u0027text/plain\u0027}               | None      |       None | passphrase  | None | None       |\n```","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c57acf40_40105344","line":280,"updated":"2024-03-27 14:51:24.000000000","message":"Why do we need to encrypt a rescue disk?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8747c928_4433dd4b","line":280,"in_reply_to":"170b5505_de86ed29","updated":"2024-03-28 17:45:24.000000000","message":"Like I said, I wasn\u0027t really sure what to do with rescue disk so I just did \"if instance encrypted then rescue disk encrypted\".\n\nIf a rescue disk doesn\u0027t need to be encrypted ever, then that would make it a lot simpler and I could delete some code.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a92299e5_a2382c07","line":280,"in_reply_to":"8747c928_4433dd4b","updated":"2024-03-28 18:28:18.000000000","message":"Yep, just MHO\u0027ing. Maybe we can get some feedback from others.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"170b5505_de86ed29","line":280,"in_reply_to":"a32ad2f3_81833dca","updated":"2024-03-28 14:37:36.000000000","message":"If the rescue *image* is encrypted already, then you need to use the secret provided anyway. But the actual disk for the instance does not need to be, IMHO, basically ever. The rescue disk is a throw-away thing (could even be readonly on a lot of OSes) with no sensitive data written to it, I\u0027m not really sure why we would want or need to go to the trouble to create/duplicate keys and encrypt the tiny delta that is involved in booting something, personally.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6c11015bae8bf82433427972bdffe0cd31b6b0ad","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f2df9b59_f12e964f","line":280,"in_reply_to":"a92299e5_a2382c07","updated":"2024-03-28 20:18:15.000000000","message":"I\u0027ll put it on the PTG topic list, just to make sure people are on the same page. It will be ideal if everyone agrees that rescue disks will never be encrypted because I would be able to simplify the code a lot.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a32ad2f3_81833dca","line":280,"in_reply_to":"c57acf40_40105344","updated":"2024-03-27 19:12:09.000000000","message":"This I wasn\u0027t sure about so I erred on the side of encrypting it. My thinking was if the instance is encrypted, maybe a user would expect if a rescue disk gets created (which by default is based on the instance image ref) it would be encrypted also (\"the principle of least surprise\").\n\nSo if we\u0027re using instance image ref as the basis for the new rescue disk and instance image ref has `hw_ephemeral_encryption` then treat it the same way as any other disk. (Though I note the currently proposed implementation is considering instance flavor as well, when maybe it probably shouldn\u0027t.)\n\nAre you thinking it would be more correct and/or more expected for a rescue disk to never be encrypted regardless of the image properties of the rescue image, or?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":277,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":278,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":279,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":280,"context_line":"   | Rescue disk        | disk (root) | Secret 12                            | Secret 12 is stashed in the instance\u0027s system        |"},{"line_number":281,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":282,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":283,"context_line":"   |                    |             |                                      | This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b6f97809_457c60ec","line":280,"in_reply_to":"f2df9b59_f12e964f","updated":"2024-05-23 10:55:08.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":285,"context_line":"   |                    |             |                                      | Secret 12 will be automatically deleted by Nova when |"},{"line_number":286,"context_line":"   |                    |             |                                      | Instance A is unrescued                              |"},{"line_number":287,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":288,"context_line":"   | Rescue disk        | disk (root) | Secret 13                            | Secret 13 is stashed in the instance\u0027s system        |"},{"line_number":289,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":290,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":291,"context_line":"   | using encrypted    |             +--------------------------------------+ This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"11f2922c_8e4b10a5","line":288,"updated":"2024-03-27 14:51:24.000000000","message":"Same here, this ends up with two keys?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":285,"context_line":"   |                    |             |                                      | Secret 12 will be automatically deleted by Nova when |"},{"line_number":286,"context_line":"   |                    |             |                                      | Instance A is unrescued                              |"},{"line_number":287,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":288,"context_line":"   | Rescue disk        | disk (root) | Secret 13                            | Secret 13 is stashed in the instance\u0027s system        |"},{"line_number":289,"context_line":"   | created by rescue  |             |                                      | metadata with key                                    |"},{"line_number":290,"context_line":"   | of Instance A      |             |                                      | ``rescue_disk_ephemeral_encryption_secret_uuid``.    |"},{"line_number":291,"context_line":"   | using encrypted    |             +--------------------------------------+ This is done because a BDM record for the rescue     |"}],"source_content_type":"text/x-rst","patch_set":7,"id":"be22e6c2_7b980892","line":288,"in_reply_to":"11f2922c_8e4b10a5","updated":"2024-03-27 19:12:09.000000000","message":"Secret 14 is for the encrypted disk backing file in the case of qcow2.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"An encrypted backing file uses the same passphrase as the source image from"},{"line_number":309,"context_line":"which it was created. This allows an encrypted backing file to be shared among"},{"line_number":310,"context_line":"multiple instances in the same project."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c9ecf2ab_b15365ba","line":310,"updated":"2024-03-27 14:51:24.000000000","message":"By this you just mean that we won\u0027t re-encrypt the image from which we booted an instance right? To me, the image (and thus the backing file) is basically to be considered immutable so I wouldn\u0027t see that it would work any other way.\n\nSo that rambling is to say, I guess I want to rewrite this to make it more assumed and not sound like a decision is being made here, but I also don\u0027t what I\u0027d say exactly :)","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"An encrypted backing file uses the same passphrase as the source image from"},{"line_number":309,"context_line":"which it was created. This allows an encrypted backing file to be shared among"},{"line_number":310,"context_line":"multiple instances in the same project."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"}],"source_content_type":"text/x-rst","patch_set":7,"id":"becd6cd4_4226fe13","line":310,"in_reply_to":"b592e02c_e80c077d","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":307,"context_line":""},{"line_number":308,"context_line":"An encrypted backing file uses the same passphrase as the source image from"},{"line_number":309,"context_line":"which it was created. This allows an encrypted backing file to be shared among"},{"line_number":310,"context_line":"multiple instances in the same project."},{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b592e02c_e80c077d","line":310,"in_reply_to":"c9ecf2ab_b15365ba","updated":"2024-03-27 19:12:09.000000000","message":"Yes that\u0027s what I mean. I think I see what you\u0027re saying though. Maybe it would come across better if I change the second sentence to something like, \"This is required for an encrypted backing file to be shared among multiple instances in the same project.\"\n\nI don\u0027t want it to be so assumed that it\u0027s not mentioned at all, perhaps because when I first started working on this project I didn\u0027t think of those details.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"},{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."}],"source_content_type":"text/x-rst","patch_set":7,"id":"b46a9704_847354e1","line":314,"updated":"2024-03-27 14:51:24.000000000","message":"This effectively means that there can be no public encrypted images right? Unless there is a way to literally grant everyone that is authenticated to the cloud read access to the secret I guess.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"},{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."}],"source_content_type":"text/x-rst","patch_set":7,"id":"cb4cc2b7_a0ed11a2","line":314,"in_reply_to":"b46a9704_847354e1","updated":"2024-03-27 19:12:09.000000000","message":"This actually depends on the key manager service API policy (and ACLs) and this sentence is stating what would be in the default case. Probably better if I reword this to be clear it\u0027s dictated only by the key manager service API policy and not give the impression that it\u0027s project owner no matter what.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":311,"context_line":""},{"line_number":312,"context_line":"Encrypted source images will have the ``hw_ephemeral_encryption_secret_uuid``"},{"line_number":313,"context_line":"image property in their image metadata. The project that owns the key manager"},{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dcf5882b_d8797f91","line":314,"in_reply_to":"cb4cc2b7_a0ed11a2","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Snapshots of instances with ephemeral encryption"},{"line_number":320,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f82a34c6_5d694002","line":317,"updated":"2024-03-27 14:51:24.000000000","message":"Do we even have backing files for these? I assumed they were unbacked qcow files (in the case of qcow).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Snapshots of instances with ephemeral encryption"},{"line_number":320,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9db30112_8f7a4833","line":317,"in_reply_to":"2209b0ba_65bdfe8a","updated":"2024-03-28 14:37:36.000000000","message":"Okay, weird, but they\u0027re always empty? That seems really strange to me, and maybe a bit of a risk (unrelated to this work). If someone\u0027s swap ever got `commit`-ed to the base then their memory contents would be visible to anyone after that happened, but for absolutely no reason.\n\nTo say it another way: being backed by an empty disk is the same as having no empty disk, but with the added security risk :)\n\nAnyway, unrelated to this I guess.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":false,"context_lines":[{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Snapshots of instances with ephemeral encryption"},{"line_number":320,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5a87d834_9352f152","line":317,"in_reply_to":"38fa7986_5d886567","updated":"2024-03-28 18:28:18.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Snapshots of instances with ephemeral encryption"},{"line_number":320,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"38fa7986_5d886567","line":317,"in_reply_to":"9db30112_8f7a4833","updated":"2024-03-28 17:45:24.000000000","message":"They have a filesystem or swap area on them, so they\u0027re not totally empty/blank, but yeah. I\u0027m not sure why it\u0027s done that way.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":314,"context_line":"secret will be allowed to create instances from the encrypted source image."},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"Backing files for ephemeral disks and swap disks are never encrypted as they"},{"line_number":317,"context_line":"are always created from blank disks."},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"Snapshots of instances with ephemeral encryption"},{"line_number":320,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2209b0ba_65bdfe8a","line":317,"in_reply_to":"f82a34c6_5d694002","updated":"2024-03-27 19:12:09.000000000","message":"We do in the case of qcow2, you will see them appear under `/opt/stack/data/nova/instances/_base/` in a devstack, for example.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":337,"context_line":"  that belongs to a different project or user (provided that project or user"},{"line_number":338,"context_line":"  has created the necessary `access control list`_ for the secret)"},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"* An instance owner wants to create an unencrypted public copy of their disk"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"New API microversion for Create Image (createImage Action)"},{"line_number":343,"context_line":"----------------------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"81675ffa_e521bb27","line":340,"updated":"2024-03-27 14:51:24.000000000","message":"Nice, thanks for listing these use cases, I think it\u0027s important and will help with understanding.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":false,"context_lines":[{"line_number":337,"context_line":"  that belongs to a different project or user (provided that project or user"},{"line_number":338,"context_line":"  has created the necessary `access control list`_ for the secret)"},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"* An instance owner wants to create an unencrypted public copy of their disk"},{"line_number":341,"context_line":""},{"line_number":342,"context_line":"New API microversion for Create Image (createImage Action)"},{"line_number":343,"context_line":"----------------------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"242459f1_5ebc105e","line":340,"in_reply_to":"81675ffa_e521bb27","updated":"2024-05-15 14:00:13.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":348,"context_line":"as the image being snapshotted (the default), have Nova generate a new key"},{"line_number":349,"context_line":"and use it to encrypt the image snapshot, provide their own key secret UUID"},{"line_number":350,"context_line":"to use to encrypt the image snapshot, or not encrypt the image snapshot at"},{"line_number":351,"context_line":"all."},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Request for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":354,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6a63864e_dd67cd6a","line":351,"updated":"2024-03-27 14:51:24.000000000","message":"Hmm just reading this made me think, maybe there\u0027s another case to add above:\n\n- An instance owner with an unencrypted disk wants to make an encrypted copy to facilitate secure exfiltration of their disk to another location","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":348,"context_line":"as the image being snapshotted (the default), have Nova generate a new key"},{"line_number":349,"context_line":"and use it to encrypt the image snapshot, provide their own key secret UUID"},{"line_number":350,"context_line":"to use to encrypt the image snapshot, or not encrypt the image snapshot at"},{"line_number":351,"context_line":"all."},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Request for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":354,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c007553a_452db008","line":351,"in_reply_to":"6a63864e_dd67cd6a","updated":"2024-03-27 19:12:09.000000000","message":"I agree, I\u0027ll add that to the example use cases.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":348,"context_line":"as the image being snapshotted (the default), have Nova generate a new key"},{"line_number":349,"context_line":"and use it to encrypt the image snapshot, provide their own key secret UUID"},{"line_number":350,"context_line":"to use to encrypt the image snapshot, or not encrypt the image snapshot at"},{"line_number":351,"context_line":"all."},{"line_number":352,"context_line":""},{"line_number":353,"context_line":"Request for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":354,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0f8476b4_3305b305","line":351,"in_reply_to":"c007553a_452db008","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":410,"context_line":"               \"meta_var\": \"meta_val\""},{"line_number":411,"context_line":"           },"},{"line_number":412,"context_line":"           \"encryption\": {"},{"line_number":413,"context_line":"               \"key\": \"same|new|\u003csecret uuid\u003e|none\""},{"line_number":414,"context_line":"           }"},{"line_number":415,"context_line":"       }"},{"line_number":416,"context_line":"   }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3a70723f_d3978426","line":413,"updated":"2024-03-27 14:51:24.000000000","message":"I like how tight this is, but I think it\u0027s a bad idea from a security perspective. Code that will use this will check to see if it\u0027s one of the special values, and if not, take the resulting value and put it into a URL or payload to the key manager. That sort of thing is a common pattern for bugs that end up with bad consequences. So I think it should be:\n```\n\"key\": \"same|new|existing|none\",\n\"secret_uuid\": \"\u003cuuid or absent\",\n```\nSo we can hard-reject anything with a key enum value that we don\u0027t know about and know that the secret_uuid needs to be in the form of a uuid (and nothing else).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":410,"context_line":"               \"meta_var\": \"meta_val\""},{"line_number":411,"context_line":"           },"},{"line_number":412,"context_line":"           \"encryption\": {"},{"line_number":413,"context_line":"               \"key\": \"same|new|\u003csecret uuid\u003e|none\""},{"line_number":414,"context_line":"           }"},{"line_number":415,"context_line":"       }"},{"line_number":416,"context_line":"   }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9974c1f3_f6d8de45","line":413,"in_reply_to":"3a70723f_d3978426","updated":"2024-03-27 19:12:09.000000000","message":"That\u0027s fair. I wondered about that too and your comment reassures that they should be separate. I\u0027ll update it.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":410,"context_line":"               \"meta_var\": \"meta_val\""},{"line_number":411,"context_line":"           },"},{"line_number":412,"context_line":"           \"encryption\": {"},{"line_number":413,"context_line":"               \"key\": \"same|new|\u003csecret uuid\u003e|none\""},{"line_number":414,"context_line":"           }"},{"line_number":415,"context_line":"       }"},{"line_number":416,"context_line":"   }"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9626def5_3aeb9e0a","line":413,"in_reply_to":"9974c1f3_f6d8de45","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":438,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Response for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":443,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":444,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"200f9e3d_54497020","line":441,"updated":"2024-03-27 19:12:09.000000000","message":"Open question: how will we reject support for this case? We would need to know what image backend is in use and what version of Ceph is in use in order to detect it and fail early.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":438,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Response for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":443,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":444,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"979f1f49_9e5c543c","line":441,"in_reply_to":"200f9e3d_54497020","updated":"2024-03-28 14:37:36.000000000","message":"Gotta fail late I guess. Or at least for the moment, maybe we can come up with something better.\n\nIs the snapshot RPC a cast?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":false,"context_lines":[{"line_number":438,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Response for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":443,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":444,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"129354ca_6335c02e","line":441,"in_reply_to":"85ea9e7c_bcfdb7e5","updated":"2024-03-28 18:28:18.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":438,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":439,"context_line":""},{"line_number":440,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":441,"context_line":""},{"line_number":442,"context_line":"Response for ``POST /servers/{server_id}/action`` with ``createImage``"},{"line_number":443,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":444,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"85ea9e7c_bcfdb7e5","line":441,"in_reply_to":"979f1f49_9e5c543c","updated":"2024-03-28 17:45:24.000000000","message":"Yes, snapshot RPC is a cast.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":471,"context_line":"   {"},{"line_number":472,"context_line":"      \"image_id\": \"0e7761dd-ee98-41f0-ba35-05994e446431\","},{"line_number":473,"context_line":"      \"encryption\": {"},{"line_number":474,"context_line":"          \"key\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":475,"context_line":"      }"},{"line_number":476,"context_line":"   }"},{"line_number":477,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"405f7357_d3ff183d","line":474,"updated":"2024-03-27 14:51:24.000000000","message":"Okay, so we\u0027ll check that we can access the current/provided key, or create a new one synchronously so we can return it to the user always right? That sounds reasonable (and a nice UX) to me.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":471,"context_line":"   {"},{"line_number":472,"context_line":"      \"image_id\": \"0e7761dd-ee98-41f0-ba35-05994e446431\","},{"line_number":473,"context_line":"      \"encryption\": {"},{"line_number":474,"context_line":"          \"key\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":475,"context_line":"      }"},{"line_number":476,"context_line":"   }"},{"line_number":477,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"7fd0487e_997e4f4c","line":474,"in_reply_to":"405f7357_d3ff183d","updated":"2024-03-27 19:12:09.000000000","message":"Yes that\u0027s what I was thinking.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":false,"context_lines":[{"line_number":471,"context_line":"   {"},{"line_number":472,"context_line":"      \"image_id\": \"0e7761dd-ee98-41f0-ba35-05994e446431\","},{"line_number":473,"context_line":"      \"encryption\": {"},{"line_number":474,"context_line":"          \"key\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":475,"context_line":"      }"},{"line_number":476,"context_line":"   }"},{"line_number":477,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"1c21c6de_3e3a05e4","line":474,"in_reply_to":"7fd0487e_997e4f4c","updated":"2024-03-28 14:37:36.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":531,"context_line":"``rescue_image_hw_ephemeral_encryption_format``. This is considered separate"},{"line_number":532,"context_line":"from ``image_hw_ephemeral_encryption_secret_uuid`` which means the encrypted"},{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1597d1b0_2a75c138","line":534,"updated":"2024-03-27 14:51:24.000000000","message":"FWIW, this seems a bit messy to me, and it seems like maybe justifying whatever we need to do to refactor things might be worth it. I\u0027d hate to end up with {rescue,image,shelve,migrate}_ephemeral_encryption_{secret_uuid,format}_{root,swap,ephemeral} all in sysmeta over time.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":531,"context_line":"``rescue_image_hw_ephemeral_encryption_format``. This is considered separate"},{"line_number":532,"context_line":"from ``image_hw_ephemeral_encryption_secret_uuid`` which means the encrypted"},{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"}],"source_content_type":"text/x-rst","patch_set":7,"id":"529a31c5_ef5ab3b7","line":534,"in_reply_to":"1597d1b0_2a75c138","updated":"2024-03-27 19:12:09.000000000","message":"I agree it\u0027s a bit messy and really the only reason for it is because rescue disks don\u0027t have persisted BDMs in the database. I wasn\u0027t sure if I should go in that direction so I started with this.\n\nIf I changed things to actually persist rescue BDMs (and delete them when rescue disk is deleted) then we wouldn\u0027t need all these things in sysmeta.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":531,"context_line":"``rescue_image_hw_ephemeral_encryption_format``. This is considered separate"},{"line_number":532,"context_line":"from ``image_hw_ephemeral_encryption_secret_uuid`` which means the encrypted"},{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7560ba4a_24e215de","line":534,"in_reply_to":"529a31c5_ef5ab3b7","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"},{"line_number":538,"context_line":"``rescue_disk_ephemeral_encryption_secret_uuid``. This is done because a block"},{"line_number":539,"context_line":"device mapping record for the rescue disk is not going to be persisted to the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0325eacc_aa7ab1bd","line":536,"updated":"2024-03-27 14:51:24.000000000","message":"This is my question from above - why do we ever need to actually create an encrypted rescue disk layer? If the image you use to rescue is encrypted, then fine, but do we need to encrypt the delta that we\u0027re just going to throw away when you unrescue?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"},{"line_number":538,"context_line":"``rescue_disk_ephemeral_encryption_secret_uuid``. This is done because a block"},{"line_number":539,"context_line":"device mapping record for the rescue disk is not going to be persisted to the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"efced3a5_4a56e6ee","line":536,"in_reply_to":"0325eacc_aa7ab1bd","updated":"2024-03-27 19:12:09.000000000","message":"Yeah, I think this is a good point. I had been thinking if the root disk is encrypted then encryption was important to the user and maybe they would expect any disk created for the instance to be encrypted.\n\nBut as I mentioned in reply to your comment above, it really only depends on what we\u0027re using as the rescue image i.e. whether or not the rescue image is encrypted.\n\nI\u0027ll change it to be only about the encryptedness of the rescue image.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"},{"line_number":538,"context_line":"``rescue_disk_ephemeral_encryption_secret_uuid``. This is done because a block"},{"line_number":539,"context_line":"device mapping record for the rescue disk is not going to be persisted to the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b378c537_f9a836d9","line":536,"in_reply_to":"a7b9cb71_2e09bc82","updated":"2024-05-15 17:50:25.000000000","message":"I agree and that is what will be in the next PS of the patches.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":533,"context_line":"image from which the instance was created. Another reason to keep it separate"},{"line_number":534,"context_line":"is to avoid confusion for those reading or working on the code."},{"line_number":535,"context_line":""},{"line_number":536,"context_line":"A new encryption secret is created when the rescue disk is created and its UUID"},{"line_number":537,"context_line":"is stashed in the instance\u0027s system metadata with key"},{"line_number":538,"context_line":"``rescue_disk_ephemeral_encryption_secret_uuid``. This is done because a block"},{"line_number":539,"context_line":"device mapping record for the rescue disk is not going to be persisted to the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a7b9cb71_2e09bc82","line":536,"in_reply_to":"efced3a5_4a56e6ee","updated":"2024-05-15 11:37:48.000000000","message":"i think if the glance image is encypted then its imporant that we encypte it when we use it for rescue. if the glance image is plain text then we dont need to encypt","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":564,"context_line":"Encryption secrets that are created when a snapshot is created are **never**"},{"line_number":565,"context_line":"deleted by Nova. It would only be acceptable to delete the secret if and when"},{"line_number":566,"context_line":"the image snapshot is deleted from Glance. Cleanup of secrets whose images have"},{"line_number":567,"context_line":"been deleted from Glance must be deleted manually by the user or an admin."},{"line_number":568,"context_line":""},{"line_number":569,"context_line":"BlockDeviceMapping changes"},{"line_number":570,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"89bf6b4d_fadb562e","line":567,"updated":"2024-03-27 14:51:24.000000000","message":"Yeah, I think this is some area that needs some overlap with the glance folks. If we\u0027re creating a new secret for every snapshot, then having glance delete the key with the snapshot makes sense to me. Otherwise, imagine I create 1000 snapshots of my instance (which would be easy with checkpointing software). Those get rotated out by the software and/or I delete a bunch of them from glance. Then I get a warning from the admin that I\u0027m overquota on my allowed secrets. I go to the manager and all I see is 1000 uuids with dates, but no real easy way for me to delete all the unused ones. It\u0027s quite likely I could screw up, delete the secret for my actual instance (still running) and shoot myself in the foot.\n\nI think maybe you\u0027ll tell me that we\u0027re setting the consumer in barbican to the instance uuid or something (right?) which definitely helps, but I think the above puts the user in a really precarious place to do the right thing. They don\u0027t care that nova, glance, and barbican are separate services, they care that we clean up after ourselves :)","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a06077af_88bc1ea7","line":591,"updated":"2024-03-27 14:51:24.000000000","message":"Is this not enough to obviate the need for the `image_` copy of the secret uuid stored in sysmeta? I guess I would expect that by the time the BDMs are created, we have access to image meta, and the BDMs are accessible fairly low in the stack when we\u0027re doing the image clone/snap stuff.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":false,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"db3ab9c2_98bcb739","line":591,"in_reply_to":"3d05cb42_d4589723","updated":"2024-05-15 11:37:48.000000000","message":"i think this is now resolved right since we are not creating any new secrete for rescue","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"390f6388049f872cdcae4831ea112776f4befab7","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3d05cb42_d4589723","line":591,"in_reply_to":"64c20f3c_f815ff8c","updated":"2024-03-28 22:37:28.000000000","message":"\u003e Okay, I guess it seems to me like we could need it for other things and end up with that proliferation, but I guess resize (which duplicates the new and old flavors, for example) wouldn\u0027t need to. Anyway, my point was just that it seems unfortunate to have to do that stuff, when the BDM seems like the right-er place to put it. If we can do away with the rescue requirement, at least now, that seems better to me. Certainly in support of a goal of reducing scope and knowing the complexity rescue brings, it seems like a good thing for the chopping block.\n\nNo other disk lacks a BDM record so I guess I don\u0027t see how we would need it for other things. If we need encryption for rescue, I could make a proper BDM record for it. If we don\u0027t need encryption for rescue, I can delete that part altogether. I hope we can do the latter.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0548dd224bd8604eea3fdbd86e4bd9154cf4de42","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"64c20f3c_f815ff8c","line":591,"in_reply_to":"75949c97_b61ede2e","updated":"2024-03-28 20:33:07.000000000","message":"\u003e To be clear, the only prefix/mess we have [in the current revision] is for rescue.\n\nYep, understand.\n\n\u003e We are able to use the secret_uuid and format from the BDM records for everything except rescue. And that\u0027s because rescue does not get a BDM record today. If we were to support encrypted rescue disks (which hopefully we won\u0027t need to after PTG discussion), the cleanest way to deal with it would be to start creating a proper BDM record for a rescue disk. And then just delete it after unrescue. Then all of the necessary attributes will be in the BDM and we don\u0027t need to stash them in sysmeta.\n\u003e \n\u003e I did the sysmeta thing as a first draft to avoid introducing additional change to start managing a BDM record for the rescue disk.\n\nOkay, I guess it seems to me like we could need it for other things and end up with that proliferation, but I guess resize (which duplicates the new and old flavors, for example) wouldn\u0027t need to. Anyway, my point was just that it seems unfortunate to have to do that stuff, when the BDM seems like the right-er place to put it. If we can do away with the rescue requirement, at least now, that seems better to me. Certainly in support of a goal of reducing scope and knowing the complexity rescue brings, it seems like a good thing for the chopping block.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8bf5e820_45864935","line":591,"in_reply_to":"7a7a2833_2f97c351","updated":"2024-03-28 18:28:18.000000000","message":"Yeah, sorry I was just trying to make a point, but I *did* say the `image_` one. What I meant was the unfortunate proliferation of all the various prefixes we\u0027ll get there, which I detailed above by saying:\n\n\u003e {rescue,image,shelve,migrate}_ephemeral_encryption_{secret_uuid,format}_{root,swap,ephemeral}\n\nBut should have linked with one of the new prefixes here for clarity, sorry.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6c11015bae8bf82433427972bdffe0cd31b6b0ad","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"75949c97_b61ede2e","line":591,"in_reply_to":"8bf5e820_45864935","updated":"2024-03-28 20:18:15.000000000","message":"To be clear, the only prefix/mess we have [in the current revision] is for rescue.\n\nWe are able to use the secret_uuid and format from the BDM records for everything except rescue. And that\u0027s because rescue does not get a BDM record today. If we were to support encrypted rescue disks (which hopefully we won\u0027t need to after PTG discussion), the cleanest way to deal with it would be to start creating a proper BDM record for a rescue disk. And then just delete it after unrescue. Then all of the necessary attributes will be in the BDM and we don\u0027t need to stash them in sysmeta.\n\nI did the sysmeta thing as a first draft to avoid introducing additional change to start managing a BDM record for the rescue disk.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"cae4f797_482e4573","line":591,"in_reply_to":"93211b26_b417b339","updated":"2024-03-28 14:37:36.000000000","message":"Yeah,I know they are, it\u0027s the duplication or added keys for the other pieces that seems undesirable to me.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"93211b26_b417b339","line":591,"in_reply_to":"a06077af_88bc1ea7","updated":"2024-03-27 19:12:09.000000000","message":"Something I learned from working on this is that _all_ image properties are always stashed in sysmeta. So that part isn\u0027t a departure from what we have today. The messy part is the `rescue_` keys due to the lack of a persisted rescue BDM, which we could consider avoiding by creating a proper BDM record in the database for rescue disks.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":588,"context_line":""},{"line_number":589,"context_line":"``backing_encryption_secret_uuid``"},{"line_number":590,"context_line":"    This will contain the UUID of the associated encryption secret for the"},{"line_number":591,"context_line":"    backing file for the disk in the case of qcow2."},{"line_number":592,"context_line":""},{"line_number":593,"context_line":"``encryption_format``"},{"line_number":594,"context_line":"    A new ``BlockDeviceEncryptionFormatType`` enum and associated"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7a7a2833_2f97c351","line":591,"in_reply_to":"cae4f797_482e4573","updated":"2024-03-28 17:45:24.000000000","message":"Ack, I thought you were saying that you also thought we shouldn\u0027t have `image_` of the secret UUID.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"482b5406_d3a331fd","line":615,"updated":"2024-03-27 14:51:24.000000000","message":"Even if not exposed to the user, there are definite upgrade implications here. I wonder if we need to define (in code) an enum of available options here, so we can make sure that we don\u0027t drop support for one cipher (etc) when we bump a libvirt or qemu version? And/or what happens if we get a new libvirt/qemu and gain a new value, that we take as a default and then make an instance that is not migrateable to another compute still running the older one?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6e236efe_64b62f3d","line":615,"in_reply_to":"482b5406_d3a331fd","updated":"2024-03-27 19:12:09.000000000","message":"Hm, yeah. I think defining the options in an enum would be a good idea.\n\nAnd the `encryption_options` attribute on BDM records should not be completely unused, i.e. maybe we should put the cipher etc that we used in there so we know what options were originally specified when the disk was created.\n\nAs for the old + new compute having different or dropped defaults scenario, I\u0027m thinking you can\u0027t migrate to a compute running the older version. IIRC we have had some things like that in the past where migration is only supported in one direction for instances using certain features.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6c11015bae8bf82433427972bdffe0cd31b6b0ad","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a060bf70_09ed6052","line":615,"in_reply_to":"4b2d2a54_b7edfb1c","updated":"2024-03-28 20:18:15.000000000","message":"To be clear, I agree we need the enum to be able to detect these kinds of issues and I will add it.\n\nI was just saying that apart from checking the enum and giving better error messages or blocking actions that we know aren\u0027t going to work or re-encrypting automatically when we can, I wasn\u0027t seeing what else we could really do.\n\nSo yeah, maybe I\u0027ll make a table showing the possible conflicts we can think of and what we will do in each case.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b4330112_d832cb38","line":615,"in_reply_to":"6e236efe_64b62f3d","updated":"2024-03-28 14:37:36.000000000","message":"Well, clearly that will have to be the case, but I\u0027m calling it out because we might want to have a more helpful behavior than just it failing in whatever way. Also, it\u0027s quite possible for new versions to drop support for a cipher, so even upgrading and migrating from old to new could bring problems.\n\nFurther, this not just about old and new nova, because we support a range of libvirt/qemu versions in a single release and lots of deployers are much less rigid about upgrading everything about a node all at once. Meaning, they could have upgraded their OS (or even just their libvirt container) without having moved nova, such that we don\u0027t have a service version or anything else to go on.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"b5fe6095_de85ec87","line":615,"in_reply_to":"b4330112_d832cb38","updated":"2024-03-28 17:45:24.000000000","message":"What is your suggestion then? To re-encrypt stuff if an option is removed in a newer libvirt/qemu or re-encrypt if the move request is specifying a specific host and that host doesn\u0027t have the option or cipher or whatever it was originally encrypted with?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":true,"context_lines":[{"line_number":612,"context_line":""},{"line_number":613,"context_line":"    Encryption options could be exposed to end users in the future when a"},{"line_number":614,"context_line":"    proper design which addresses security and handles all upgrade scenarios is"},{"line_number":615,"context_line":"    developed."},{"line_number":616,"context_line":""},{"line_number":617,"context_line":"Populate ephemeral encryption BlockDeviceMapping attributes during build"},{"line_number":618,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4b2d2a54_b7edfb1c","line":615,"in_reply_to":"b5fe6095_de85ec87","updated":"2024-03-28 18:28:18.000000000","message":"My suggestion is what I said above, that we should enumerate the allowed values right now and object if we see any that we don\u0027t know about. That could be done by making this *not* an unversioned dict, or with just some sanity checking when we load/traverse them.\n\nThe rest of what I\u0027m saying is just that I think we need to consider both the migrate and upgrade cases and not just punt until later. For example, if I enable FIPS on my host and reboot, a bunch of ciphers that were allowed before are suddenly not available in the libraries below us. It would certainly be unfortunate if the only way we report that to the operator is \"qemu failed to start\" or worse, qemu starting but the instance doesn\u0027t boot because we can\u0027t read the disk. That probably won\u0027t happen for a while for the defaults we\u0027re going to choose here, but because it results in unreadable disks, I think it\u0027s worth the extra diligence.\n\nSimilarly, I think the recent spate of live migration-with-* features have left us with situations where we have to add a bunch of info to the migration objects later to enable such migration, because we don\u0027t know what is supported. Maybe that\u0027s not as big of a deal in this case because the actual attributes we\u0027re worried about are stored in the DB, and we could abort during a pre migrate phase on either end. But, having the \"this is the list of cipher/format/keysize/etc\" in a list makes it easy to just go ahead and check for that in those kinds of places. I do think that re-encrypting the disk if we resize to a different setup is what the user will expect, but we\u0027ll probably need a way for the destination to tell us what it requires, which goes back to the enum thing.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":667,"context_line":"requested and may optionally include one of the format specific traits if a"},{"line_number":668,"context_line":"format is included in the request."},{"line_number":669,"context_line":""},{"line_number":670,"context_line":"Expose ephemeral encryption attributes via block_device_info"},{"line_number":671,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":672,"context_line":""},{"line_number":673,"context_line":"Once the ``BlockDeviceMapping`` objects have been updated and the instance"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bb56a304_46d860d6","line":670,"updated":"2024-03-27 14:51:24.000000000","message":"TBH, I\u0027m, not really sure what the point of this section is. Highlighting that the existing API isn\u0027t very helpful in exposing these new attributes?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":667,"context_line":"requested and may optionally include one of the format specific traits if a"},{"line_number":668,"context_line":"format is included in the request."},{"line_number":669,"context_line":""},{"line_number":670,"context_line":"Expose ephemeral encryption attributes via block_device_info"},{"line_number":671,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":672,"context_line":""},{"line_number":673,"context_line":"Once the ``BlockDeviceMapping`` objects have been updated and the instance"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ef7cafc5_7f6f5f4b","line":670,"in_reply_to":"bb56a304_46d860d6","updated":"2024-03-27 19:12:09.000000000","message":"This is from the original spec proposal and I think the point of it was just to explain how encryption details will be communicated to/from the virt layer, perhaps to aid reviewers later when they look at the code. I think these details likely make review of the implementation make more sense if the reviewer isn\u0027t already that familiar the block device mapping stuff in general.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":false,"context_lines":[{"line_number":667,"context_line":"requested and may optionally include one of the format specific traits if a"},{"line_number":668,"context_line":"format is included in the request."},{"line_number":669,"context_line":""},{"line_number":670,"context_line":"Expose ephemeral encryption attributes via block_device_info"},{"line_number":671,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":672,"context_line":""},{"line_number":673,"context_line":"Once the ``BlockDeviceMapping`` objects have been updated and the instance"}],"source_content_type":"text/x-rst","patch_set":7,"id":"fe2e6a68_7ea9beaf","line":670,"in_reply_to":"ef7cafc5_7f6f5f4b","updated":"2024-05-20 17:36:30.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":773,"context_line":"    }"},{"line_number":774,"context_line":""},{"line_number":775,"context_line":"This should also be extended to cover disks provided by encrypted volumes but"},{"line_number":776,"context_line":"this is obviously out of scope for this implementation."},{"line_number":777,"context_line":""},{"line_number":778,"context_line":"Block resize between flavors with different ``hw:ephemeral_encryption`` values"},{"line_number":779,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c00c1427_32dc5c60","line":776,"updated":"2024-03-27 14:51:24.000000000","message":"So this section is saying we *should* expose that information, but we don\u0027t/won\u0027t as a result of this spec?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":773,"context_line":"    }"},{"line_number":774,"context_line":""},{"line_number":775,"context_line":"This should also be extended to cover disks provided by encrypted volumes but"},{"line_number":776,"context_line":"this is obviously out of scope for this implementation."},{"line_number":777,"context_line":""},{"line_number":778,"context_line":"Block resize between flavors with different ``hw:ephemeral_encryption`` values"},{"line_number":779,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2e2b02a2_093d22b7","line":776,"in_reply_to":"9dc15400_e99bd7ad","updated":"2024-05-23 10:55:08.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":773,"context_line":"    }"},{"line_number":774,"context_line":""},{"line_number":775,"context_line":"This should also be extended to cover disks provided by encrypted volumes but"},{"line_number":776,"context_line":"this is obviously out of scope for this implementation."},{"line_number":777,"context_line":""},{"line_number":778,"context_line":"Block resize between flavors with different ``hw:ephemeral_encryption`` values"},{"line_number":779,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9dc15400_e99bd7ad","line":776,"in_reply_to":"a4f476f9_a41d1a37","updated":"2024-03-28 14:37:36.000000000","message":"Ah okay, I guess I missed the distinction between \"volumes\" and \"Volumes\" (i.e. volume as a general term for a disk and Volume as an actual cinder volume).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":773,"context_line":"    }"},{"line_number":774,"context_line":""},{"line_number":775,"context_line":"This should also be extended to cover disks provided by encrypted volumes but"},{"line_number":776,"context_line":"this is obviously out of scope for this implementation."},{"line_number":777,"context_line":""},{"line_number":778,"context_line":"Block resize between flavors with different ``hw:ephemeral_encryption`` values"},{"line_number":779,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"a4f476f9_a41d1a37","line":776,"in_reply_to":"c00c1427_32dc5c60","updated":"2024-03-27 19:12:09.000000000","message":"I think this is saying that encrypted Cinder volumes are not returning encryption info in the metadata API today but they should. And this spec is only going to cover exposing encryption info for local disks, so doing the same thing for Cinder volumes would be a separate change and/or spec.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9b18234b_9e6c0aa7","line":785,"updated":"2024-03-27 14:51:24.000000000","message":"But, we were going to re-encrypt the disk every time we snapshotted before? 😊\n\nThis is saying resize won\u0027t be supported between say format\u003dluks and format\u003dfoobar right? Otherwise it will be supported, and since we only support luks currently, no restriction?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4a06bee3_3314bdf7","line":785,"in_reply_to":"1fcebc9d_d568d673","updated":"2024-03-28 14:37:36.000000000","message":"Yeah, I\u0027m just saying that things that prevent users from doing operations that are expected to work suck. So, especially if the user doesn\u0027t grok that two flavors have two different encryption schemes, it will suck to just strand their instance in the old configuration for no real reason. I get that there\u0027s no second format now, but \"unencrypted\" is a sort of shadow extra format.\n\nSo, someone says \"ooh, I\u0027d like this new secure flavor, boot an instance\" then a week later realizes \"oh the disk encryption is probably why we\u0027re having perf problems, let me resize to a non-secure flavor\" and then is stuck.\n\nNot a huge deal necessarily, but it does kinda suck to have those sorts of bait-and-switch pitfalls.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9061ca0d_c49132c9","line":785,"in_reply_to":"4a06bee3_3314bdf7","updated":"2024-03-28 17:45:24.000000000","message":"Yeah. It does say \"This isn\u0027t trivial and so for this initial implementation\nresizing between flavors that differ will be blocked.\" so to me that makes it sound like it is something that is thought of as desirable but is considered future work.\n\nThe scope of this feature is large and it just keeps getting larger. I\u0027m guessing this was one of the ways to do things more iteratively.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6c11015bae8bf82433427972bdffe0cd31b6b0ad","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d7d2420e_bc422d87","line":785,"in_reply_to":"7bf42818_330b68a8","updated":"2024-03-28 20:18:15.000000000","message":"OK, sure. I\u0027ll add this point to the PTG topic also. Definitely something I want to hear consensus on before I go changing all of that.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"95582f71d3420543be1f05dc1f2a3799af271293","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7bf42818_330b68a8","line":785,"in_reply_to":"9061ca0d_c49132c9","updated":"2024-03-28 18:28:18.000000000","message":"Yeah, understand, and not having another format helps this be an obvious place to limit the initial scope. My point is that we really already have two formats, luks and none, so the problem isn\u0027t just a future one.\n\nGiven the potential that after this series is merged we don\u0027t come back and fill in these details, it does become one of those things where \"oh that diagonal cross section of features don\u0027t work when X is enabled\" and resize being out of scope is a bummer, that\u0027s all.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1fcebc9d_d568d673","line":785,"in_reply_to":"9b18234b_9e6c0aa7","updated":"2024-03-27 19:12:09.000000000","message":"I know you\u0027re really onto that point 🙂 but I did it that way to default to the most secure approach. My thought was that if every snapshot used the same password and you end up with say 30 images are using the same password then that would not be a great position to put the user in by default. I was thinking about users snapshots being accessed by other users in the project and if you are giving access to that disk to someone else, you don\u0027t want or expect it to be using your personal password. For a resize, this isn\u0027t an issue so there is no reason to consider re-encrypting it.\n\nNow, we\u0027ve had discussions since then about giving users options in the snapshot API, and I think that makes things a lot clearer for a user perspective as to what will happen by default and being able to specify how they want the snapshot to be done.\n\nYes, this is saying resize from format\u003dluks to format\u003dfoobar is not supported but format\u003dluks to format\u003dluks is supported and since there are no other format options at this time, there will be no restriction (provided that the flavor extra specs say `luks`).","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":false,"context_lines":[{"line_number":782,"context_line":"between flavors that differed in their configuration of ephemeral encryption"},{"line_number":783,"context_line":"(one enabled, another disabled or formats etc) would cause us to convert this"},{"line_number":784,"context_line":"data in place. This isn\u0027t trivial and so for this initial implementation"},{"line_number":785,"context_line":"resizing between flavors that differ will be blocked."},{"line_number":786,"context_line":""},{"line_number":787,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":788,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"8ca3a5aa_31699c03","line":785,"in_reply_to":"d7d2420e_bc422d87","updated":"2024-05-20 17:36:30.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":802,"context_line":""},{"line_number":803,"context_line":"The ``nova-status`` command will simply report on the existence of any"},{"line_number":804,"context_line":"instances with ``ephemeral_key_uuid`` set that do not have the corresponding"},{"line_number":805,"context_line":"``BlockDeviceMapping`` attributes enabled etc."},{"line_number":806,"context_line":""},{"line_number":807,"context_line":"Deprecate the now legacy implementation"},{"line_number":808,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"820dc6e7_ef94f65d","line":805,"updated":"2024-03-27 14:51:24.000000000","message":"This means migration from the lvm-based approach currently supported right? Might be worth pointing out that this will not happen \"online\" and convert-at-instance-reboot would be the best we could hope for in terms of minimizing impact to the workloads.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":false,"context_lines":[{"line_number":802,"context_line":""},{"line_number":803,"context_line":"The ``nova-status`` command will simply report on the existence of any"},{"line_number":804,"context_line":"instances with ``ephemeral_key_uuid`` set that do not have the corresponding"},{"line_number":805,"context_line":"``BlockDeviceMapping`` attributes enabled etc."},{"line_number":806,"context_line":""},{"line_number":807,"context_line":"Deprecate the now legacy implementation"},{"line_number":808,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f6e22b99_2c0ab6d9","line":805,"in_reply_to":"65057910_c90b8661","updated":"2024-03-28 14:37:36.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":802,"context_line":""},{"line_number":803,"context_line":"The ``nova-status`` command will simply report on the existence of any"},{"line_number":804,"context_line":"instances with ``ephemeral_key_uuid`` set that do not have the corresponding"},{"line_number":805,"context_line":"``BlockDeviceMapping`` attributes enabled etc."},{"line_number":806,"context_line":""},{"line_number":807,"context_line":"Deprecate the now legacy implementation"},{"line_number":808,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"65057910_c90b8661","line":805,"in_reply_to":"820dc6e7_ef94f65d","updated":"2024-03-27 19:12:09.000000000","message":"Yes, this is about the LVM based ephemeral encryption. I\u0027ll add that detail.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":841,"context_line":"  instance disks."},{"line_number":842,"context_line":""},{"line_number":843,"context_line":"* The metadata API will be changed to allow users to determine if their"},{"line_number":844,"context_line":"  ephemeral storage is encrypted as discussed above."},{"line_number":845,"context_line":""},{"line_number":846,"context_line":"Security impact"},{"line_number":847,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9d36d70f_9d32da8c","line":844,"updated":"2024-03-27 14:51:24.000000000","message":"I thought \"above\" said that was out of scope?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5e08192c9e8aade444c31b231fbab6c3e60a555e","unresolved":false,"context_lines":[{"line_number":841,"context_line":"  instance disks."},{"line_number":842,"context_line":""},{"line_number":843,"context_line":"* The metadata API will be changed to allow users to determine if their"},{"line_number":844,"context_line":"  ephemeral storage is encrypted as discussed above."},{"line_number":845,"context_line":""},{"line_number":846,"context_line":"Security impact"},{"line_number":847,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"154d9e81_6a0a97ec","line":844,"in_reply_to":"1f92668c_9640e3ef","updated":"2024-03-28 14:37:36.000000000","message":"Acknowledged","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":841,"context_line":"  instance disks."},{"line_number":842,"context_line":""},{"line_number":843,"context_line":"* The metadata API will be changed to allow users to determine if their"},{"line_number":844,"context_line":"  ephemeral storage is encrypted as discussed above."},{"line_number":845,"context_line":""},{"line_number":846,"context_line":"Security impact"},{"line_number":847,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1f92668c_9640e3ef","line":844,"in_reply_to":"9d36d70f_9d32da8c","updated":"2024-03-27 19:12:09.000000000","message":"Doing it for encrypted Cinder volumes is out of scope.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fee1d254f3de3556297faae861ff616489008712","unresolved":true,"context_lines":[{"line_number":862,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":863,"context_line":""},{"line_number":864,"context_line":"Users will now need to opt-in to ephemeral storage encryption being used by"},{"line_number":865,"context_line":"their instances through their choice of image or flavor."},{"line_number":866,"context_line":""},{"line_number":867,"context_line":"Performance Impact"},{"line_number":868,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"134652bd_6e285af5","line":865,"updated":"2024-03-27 14:51:24.000000000","message":"Above you also kinda said operators could force the issue (as they can today) with flavors, so maybe change \"will need\" to \"may be able to\" or something?","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d7c24d9fe2c30d4b1d4ecdec73ec1f26da96a855","unresolved":true,"context_lines":[{"line_number":862,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":863,"context_line":""},{"line_number":864,"context_line":"Users will now need to opt-in to ephemeral storage encryption being used by"},{"line_number":865,"context_line":"their instances through their choice of image or flavor."},{"line_number":866,"context_line":""},{"line_number":867,"context_line":"Performance Impact"},{"line_number":868,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"13f8a211_604cbdd5","line":865,"in_reply_to":"134652bd_6e285af5","updated":"2024-03-27 19:12:09.000000000","message":"Yeah, that\u0027s true. I\u0027ll update the wording.","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcc3f535ff74a7ca4bf5dba7bd5550d118ee96cd","unresolved":false,"context_lines":[{"line_number":862,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":863,"context_line":""},{"line_number":864,"context_line":"Users will now need to opt-in to ephemeral storage encryption being used by"},{"line_number":865,"context_line":"their instances through their choice of image or flavor."},{"line_number":866,"context_line":""},{"line_number":867,"context_line":"Performance Impact"},{"line_number":868,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0934954d_cca30d96","line":865,"in_reply_to":"13f8a211_604cbdd5","updated":"2024-05-14 05:23:26.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"75e88677a35544c7abd81f76fc12f5ae6cd754c3","unresolved":true,"context_lines":[{"line_number":1006,"context_line":"     - Reproposed"},{"line_number":1007,"context_line":"   * - 2024.1 Caracal"},{"line_number":1008,"context_line":"     - Reproposed"},{"line_number":1009,"context_line":"   * - 2024.2 Dalmation"},{"line_number":1010,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ff77fa3f_540357ed","line":1009,"range":{"start_line":1009,"start_character":14,"end_line":1009,"end_character":23},"updated":"2024-03-28 17:45:24.000000000","message":"Dalmatian","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":false,"context_lines":[{"line_number":1006,"context_line":"     - Reproposed"},{"line_number":1007,"context_line":"   * - 2024.1 Caracal"},{"line_number":1008,"context_line":"     - Reproposed"},{"line_number":1009,"context_line":"   * - 2024.2 Dalmation"},{"line_number":1010,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bd2bd219_3aacc8eb","line":1009,"range":{"start_line":1009,"start_character":14,"end_line":1009,"end_character":23},"in_reply_to":"ff77fa3f_540357ed","updated":"2024-05-14 20:51:55.000000000","message":"Done","commit_id":"6940b7f76b9e415fd0ab75cbea9c0b001a68272a"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Flavour and Image defined ephemeral storage encryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption"}],"source_content_type":"text/x-rst","patch_set":9,"id":"8e0a2f14_2d2dc06a","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":7},"updated":"2024-05-14 14:29:07.000000000","message":"nit:Flavor","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Flavour and Image defined ephemeral storage encryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption"}],"source_content_type":"text/x-rst","patch_set":9,"id":"795c2cc4_bb26099e","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":7},"in_reply_to":"6630bb3c_68f04d89","updated":"2024-05-14 20:51:55.000000000","message":"Haha FINE I\u0027ll change it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Flavour and Image defined ephemeral storage encryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9b249e35_a2a26215","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":7},"in_reply_to":"795c2cc4_bb26099e","updated":"2024-05-15 11:37:48.000000000","message":"ya for better or worse we use dto have a docs guide that specificaly said for offical docs we shoudl default to the spelling defiend in https://www.merriam-webster.com/ \n\nwith that said that does not apply to specs and never has.\ni relaly dont care however so Flavor is fine and for the anything related to the api then we should match what the api uses explcitly which is also Flavor.\n\n\nfor what its workth i ment to add code spell to this repo a while ago and never got around to it.\n\nby default codespell would also enfoce US spelling.\nyou can turn that of but if we were to add it i dont see why we would disabel that.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Flavour and Image defined ephemeral storage encryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption"}],"source_content_type":"text/x-rst","patch_set":9,"id":"6630bb3c_68f04d89","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":7},"in_reply_to":"8e0a2f14_2d2dc06a","updated":"2024-05-14 18:48:48.000000000","message":"This comes from the original author, but long ago we agreed to use US spelling of these things, and it\u0027s definitely \"flavor\" in the API and other docs. So I\u0027m happy to support your nit :)","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Flavour and Image defined ephemeral storage encryption"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c97ec9e5_151496f9","line":8,"range":{"start_line":8,"start_character":0,"end_line":8,"end_character":7},"in_reply_to":"9b249e35_a2a26215","updated":"2024-05-20 16:28:30.000000000","message":"Done","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":true,"context_lines":[{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"-------------------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"At present the only in-tree ephemeral storage encryption support is provided by"},{"line_number":31,"context_line":"the libvirt virt driver when using the lvm imagebackend. The current"},{"line_number":32,"context_line":"implementation provides basic operator controlled and configured host specific"},{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"}],"source_content_type":"text/x-rst","patch_set":9,"id":"ce532585_06253786","line":30,"range":{"start_line":30,"start_character":15,"end_line":30,"end_character":57},"updated":"2024-05-14 14:29:07.000000000","message":"here you meant below only right ?\n[ephemeral_storage_encryption].enable\u003dtrue","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"-------------------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"At present the only in-tree ephemeral storage encryption support is provided by"},{"line_number":31,"context_line":"the libvirt virt driver when using the lvm imagebackend. The current"},{"line_number":32,"context_line":"implementation provides basic operator controlled and configured host specific"},{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"}],"source_content_type":"text/x-rst","patch_set":9,"id":"d5a2206f_ac9fd0fe","line":30,"range":{"start_line":30,"start_character":15,"end_line":30,"end_character":57},"in_reply_to":"ce532585_06253786","updated":"2024-05-14 20:51:55.000000000","message":"Right, the only ephemeral encryption that is available today in the Nova tree is the LVM `[ephemeral_storage_encryption]` stuff.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"ac5a35f6ba23f2daa0e5e47ebf40f34d5c087ca0","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Problem description"},{"line_number":28,"context_line":"-------------------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"At present the only in-tree ephemeral storage encryption support is provided by"},{"line_number":31,"context_line":"the libvirt virt driver when using the lvm imagebackend. The current"},{"line_number":32,"context_line":"implementation provides basic operator controlled and configured host specific"},{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"}],"source_content_type":"text/x-rst","patch_set":9,"id":"274d5ad8_43080650","line":30,"range":{"start_line":30,"start_character":15,"end_line":30,"end_character":57},"in_reply_to":"d5a2206f_ac9fd0fe","updated":"2024-05-15 11:55:49.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":true,"context_lines":[{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"},{"line_number":34,"context_line":"compute are forced to use encrypted ephemeral storage using the dm-crypt"},{"line_number":35,"context_line":"``PLAIN`` encryption format."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"This is not ideal and makes ephemeral storage encryption completely opaque"},{"line_number":38,"context_line":"to the end user as opposed to the block storage encryption support provided by"},{"line_number":39,"context_line":"Cinder where users are able to opt-in to using admin defined encrypted volume"}],"source_content_type":"text/x-rst","patch_set":9,"id":"234b24f3_de98828f","line":36,"updated":"2024-05-14 14:29:07.000000000","message":"apart from LVM image-backend, there are qcow2, raw, flat and ceph (ceph might have its own enryption way). for which nova can\u0027t encrypt ephmeral at present.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"},{"line_number":34,"context_line":"compute are forced to use encrypted ephemeral storage using the dm-crypt"},{"line_number":35,"context_line":"``PLAIN`` encryption format."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"This is not ideal and makes ephemeral storage encryption completely opaque"},{"line_number":38,"context_line":"to the end user as opposed to the block storage encryption support provided by"},{"line_number":39,"context_line":"Cinder where users are able to opt-in to using admin defined encrypted volume"}],"source_content_type":"text/x-rst","patch_set":9,"id":"a2aaab72_0070e90d","line":36,"in_reply_to":"234b24f3_de98828f","updated":"2024-05-14 18:48:48.000000000","message":"What\u0027s your point? I think by saying \"the only ... support ... via LVM\" implies that none of the other mechanisms support it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"ac5a35f6ba23f2daa0e5e47ebf40f34d5c087ca0","unresolved":true,"context_lines":[{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"},{"line_number":34,"context_line":"compute are forced to use encrypted ephemeral storage using the dm-crypt"},{"line_number":35,"context_line":"``PLAIN`` encryption format."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"This is not ideal and makes ephemeral storage encryption completely opaque"},{"line_number":38,"context_line":"to the end user as opposed to the block storage encryption support provided by"},{"line_number":39,"context_line":"Cinder where users are able to opt-in to using admin defined encrypted volume"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c85d6d7a_5ee9276c","line":36,"in_reply_to":"a2aaab72_0070e90d","updated":"2024-05-15 11:55:49.000000000","message":"yes, I was just listing the other backends for clearity, and if I understand correctly.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":false,"context_lines":[{"line_number":33,"context_line":"support for ephemeral disk encryption at rest where all instances on a given"},{"line_number":34,"context_line":"compute are forced to use encrypted ephemeral storage using the dm-crypt"},{"line_number":35,"context_line":"``PLAIN`` encryption format."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"This is not ideal and makes ephemeral storage encryption completely opaque"},{"line_number":38,"context_line":"to the end user as opposed to the block storage encryption support provided by"},{"line_number":39,"context_line":"Cinder where users are able to opt-in to using admin defined encrypted volume"}],"source_content_type":"text/x-rst","patch_set":9,"id":"bec826b4_8866d9d2","line":36,"in_reply_to":"c85d6d7a_5ee9276c","updated":"2024-05-20 16:28:30.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* As an admin/operator I want to provide sane choices to my end users regarding"},{"line_number":59,"context_line":"  how their ephemeral storage is encrypted at rest."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* As a virt driver maintainer/developer I want to indicate that my driver"},{"line_number":62,"context_line":"  supports ephemeral storage encryption using a specific encryption format."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"31681ea9_1fe30d26","line":60,"updated":"2024-05-14 14:29:07.000000000","message":"so user/operator will be able to opt-in for other encryption?\nbut LUKS and dm-crypt are from linux kernel. so others need implementation in future on usage ?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* As an admin/operator I want to provide sane choices to my end users regarding"},{"line_number":59,"context_line":"  how their ephemeral storage is encrypted at rest."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* As a virt driver maintainer/developer I want to indicate that my driver"},{"line_number":62,"context_line":"  supports ephemeral storage encryption using a specific encryption format."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"5216aab3_a9ea4916","line":60,"in_reply_to":"31681ea9_1fe30d26","updated":"2024-05-14 18:48:48.000000000","message":"I don\u0027t know what this means. LUKS is not provided by the kernel. It\u0027s a strategy/standard more than a thing. dm-crypt can provide LUKS, but in this case, it\u0027s qemu that is providing LUKS support. Not sure if you were suggesting a change, but what is here seems fine to me.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"ac5a35f6ba23f2daa0e5e47ebf40f34d5c087ca0","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* As an admin/operator I want to provide sane choices to my end users regarding"},{"line_number":59,"context_line":"  how their ephemeral storage is encrypted at rest."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* As a virt driver maintainer/developer I want to indicate that my driver"},{"line_number":62,"context_line":"  supports ephemeral storage encryption using a specific encryption format."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"cfa903c6_c67adfe6","line":60,"in_reply_to":"5216aab3_a9ea4916","updated":"2024-05-15 11:55:49.000000000","message":"I was not suggesting any change.\n\u003e  LUKS is not provided by the kernel.  It\u0027s a strategy/standard.\n\u003eIt\u0027s a strategy/standard more than a thing. dm-crypt can provide LUKS, but in this case, it\u0027s qemu that is providing LUKS support.\n\nack, thanks for clearing, I thought LUKS, dm-crypt is something linux already provide and nova is going to enable it for our linux VM\u0027s.\nI understand now, qemu will provide LUKS support.\n\napart from this, regarding the config var default_format as luks,\nif user wants to use other encryption ex: bitlocker, nova will require separate implementation for it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":false,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* As an admin/operator I want to provide sane choices to my end users regarding"},{"line_number":59,"context_line":"  how their ephemeral storage is encrypted at rest."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* As a virt driver maintainer/developer I want to indicate that my driver"},{"line_number":62,"context_line":"  supports ephemeral storage encryption using a specific encryption format."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"0da660c9_3b05ff83","line":60,"in_reply_to":"cfa903c6_c67adfe6","updated":"2024-05-20 16:28:30.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7adce97b_71f2258e","line":118,"updated":"2024-05-14 18:48:48.000000000","message":"So, per above: when is plain ever going to be used or allowed? Unless we\u0027re going to upload the host key into barbican so the image can be decryptable elsewhere, will plain ever make sense?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c4c7513e_8ddd0033","line":118,"in_reply_to":"1883a953_a9dd9726","updated":"2024-05-15 14:00:13.000000000","message":"Sean\u0027s suggestion of \u0027plain\u0027 for \u0027not encryped\u0027 reminded me to come back and comment on this. Shouldn\u0027t we s/plain/legacy/ or something here? \"Plain\" is definitely confusing. People might think they would like encrypted disks, but not super complicated ones and thus they should choose \"plain\" as the \"simple\" option.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e7475ac99373df5c5c02ccd9bd40eab9aabb9b78","unresolved":false,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"86cd7693_4e6716a4","line":118,"in_reply_to":"625f612c_605d52a2","updated":"2024-05-20 16:43:54.000000000","message":"Done","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1883a953_a9dd9726","line":118,"in_reply_to":"7adce97b_71f2258e","updated":"2024-05-14 20:51:55.000000000","message":"The existing LVM ephemeral encryption does upload a key per instance into Barbican [1] but \"decryptable elsewhere than the instance\" does not appear to be possible.\n\n[1] https://github.com/openstack/nova/blob/50953366898e7d30ccfef46cd12305b3ce891a78/nova/compute/api.py#L2081-L2091","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"89cd897438a8bb3be28a9e3085fadbd4e6713721","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"625f612c_605d52a2","line":118,"in_reply_to":"c41bd96a_72080cdc","updated":"2024-05-20 16:28:30.000000000","message":"`dmcrypt_plain` would be much better than `plain` I agree. I still think it might be better to convey some \"legacy-ness\", but either way.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"d64c4da8_d5e6338d","line":118,"in_reply_to":"c4c7513e_8ddd0033","updated":"2024-05-15 17:50:25.000000000","message":"Yeah, that\u0027s fair. When I first started working on this I also had to figure out what `plain` meant. So I\u0027ll plan on finding a better term for this.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"1b00a6a9a4856cce6ea596c9fd68277a09041ce1","unresolved":true,"context_lines":[{"line_number":115,"context_line":"``BlockDeviceEncryptionFormatTypeField`` oslo.versionedobjects field value:"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"* ``plain`` for the plain dm-crypt format"},{"line_number":118,"context_line":"* ``luks``  for the LUKSv1 format"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":121,"context_line":"of the encryption secret is stored in the key manager for the resultant image"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c41bd96a_72080cdc","line":118,"in_reply_to":"d64c4da8_d5e6338d","updated":"2024-05-15 21:56:35.000000000","message":"Hah, so ... I have just learned that `plain` is the literal name of the format 😆 I did not realize that.\n\nhttps://gitlab.com/cryptsetup/cryptsetup#what-the-\nhttps://wiki.archlinux.org/title/dm-crypt/Device_encryption#Encryption_options_with_dm-crypt\n\nI did see it referred to as \"dm-crypt plain\" or \"plain dm-crypt\" several times while looking at search results, so maybe `dmcrypt_plain` could be an OK name for us to use instead of `plain`?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"18e216110b02810f73010f367efcd1864cd90396","unresolved":true,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"14451a87_2ecf5834","line":128,"updated":"2024-05-14 14:29:07.000000000","message":"so to encrypt, we need to do below?\n1- encrypt a instance i.e using extra-specs\nflavor: `hw:ephemeral_encryption\u003dtrue`, `hw:ephemeral_encryption_format\u003dluks`\nimage: `hw_ephemeral_encryption\u003dtrue`, `hw_ephemeral_encryption_format\u003dluks`\n\nOR\n\n2- encryot all (future)instance on particular compute node\nupdate nova.conf\n```\n[ephemeral_storage_encryption]\nenable\u003dtrue\ndefault_format\u003dluks\n```","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"ca9eb6ef_42f3841e","line":128,"in_reply_to":"14451a87_2ecf5834","updated":"2024-05-14 18:48:48.000000000","message":"\u003e 2- encryot all (future)instance on particular compute node\n\u003e update nova.conf\n\u003e ```\n\u003e [ephemeral_storage_encryption]\n\u003e enable\u003dtrue\n\u003e default_format\u003dluks\n\u003e ```\n\nI believe this is mixing two things, the old mechanism and the new one. AFAIK, if you specify `enable\u003dtrue` you\u0027re asking for the PLAIN LVM-based single-key implementation on the host, which only works if you\u0027re using LVM as your backend and in that case, `default_format\u003dluks` gets ignored.\n\nAm I wrong about that?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":34860,"name":"Amit Uniyal","email":"auniyal@redhat.com","username":"auniyal"},"change_message_id":"ac5a35f6ba23f2daa0e5e47ebf40f34d5c087ca0","unresolved":true,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"587de603_7f5f4089","line":128,"in_reply_to":"464c677d_1188a510","updated":"2024-05-15 11:55:49.000000000","message":"ack, so as of now operator should mention in config ?\n```\n[ephemeral_storage_encryption]\ndefault_format\u003dluks```\n\ncan we remove enable just say\n```\n[ephemeral_storage_encryption]\nencryption_format/method \u003d luks|plain| or others\n```\nand if method/format is defined as its respective value will say okay encryption is enabled and its of this format.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"59cedc78_acdd61d4","line":128,"in_reply_to":"587de603_7f5f4089","updated":"2024-05-15 17:50:25.000000000","message":"Yes I think that is the intention. That we would add the `deprecated_for_removal` keyword argument to the `[ephemeral_storage_encryption]enable` and related legacy options at the same time that we make LVM backend encryption work with the new scheme.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"8130aead_2a4c77a2","line":128,"in_reply_to":"59cedc78_acdd61d4","updated":"2024-05-23 10:55:08.000000000","message":"removal of enable makes sense but i dont think its required.\n\nwe can just remove both default_format and enable once we have implemented the upgrade support for the lvm driver. or rather we can remove them both after the subsequent slurp releas.\n\ni dont think it really hurts to keep enable untl we are also removign the format.\n\nfor what its worth its fine to menthion thses future plans but none of the removal will happen till at least the F release, which is assuming that the lvm support is added in E which may or may not happen.\n\nso the exect removal timeline and plans really are out of scope of this spec.\nwe just need to note that future intent and general direction but im sure there will be a v2 spec for the lvm and adoption and removal at somepoint in the E or F release that can capture the details.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"aedb3d950867c0f55a686323d13c93d8ef003b9a","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"c85186f9_8f794d5b","line":128,"in_reply_to":"8130aead_2a4c77a2","updated":"2024-05-23 16:37:23.000000000","message":"``[ephemeral_storage_encryption]default_format`` was actually added as part of the spec last cycle, so I don\u0027t think it was intended to remove it. If we think we just don\u0027t need it, obviously we can remove it. Just saying it\u0027s new and not part of the legacy LVM stuff.\n\nThe legacy config options are:\n```\n[ephemeral_storage_encryption]\nenabled \u003d true\ncipher \u003d aes-xts-plain64\nkey_size \u003d 512\n```\n\nIIUC the intent was ultimately later to remove these original options and the ``[ephemeral_storage_encryption]`` ends up representing only the new stuff.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":127,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Management of secret data with the Key Manager service"},{"line_number":130,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"464c677d_1188a510","line":128,"in_reply_to":"ca9eb6ef_42f3841e","updated":"2024-05-14 20:51:55.000000000","message":"Right, those are two different things. The existing LVM ephemeral encryption is enabled/requested per host via config option but the new qcow2|raw|rbd ephemeral encryption is requested per instance via flavor extra specs or image properties.\n\nAnd right, `default_format\u003dluks` is applicable only to the new qcow2|raw|rbd scheme. TBH I think having `default_format` under the LVM encryption config group is confusing ... maybe it would be worth making a new config group for it or renaming it or something.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":174,"context_line":"For admin-only APIs such as cold migration, live migration, and evacuate, the"},{"line_number":175,"context_line":"user calling Nova API to perform these server actions needs to be able to"},{"line_number":176,"context_line":"access the Barbican secrets of the owner of the server in addition to having"},{"line_number":177,"context_line":"the ``admin`` role. In a default Barbican configuration, secret ownership will"},{"line_number":178,"context_line":"be scoped to the project which created it, so in such an environment a user"},{"line_number":179,"context_line":"would need to be a `project administrator`_ or any user who has both project"},{"line_number":180,"context_line":"membership and the ``admin`` role."}],"source_content_type":"text/x-rst","patch_set":9,"id":"ec2237f5_ce0905e2","line":177,"range":{"start_line":177,"start_character":14,"end_line":177,"end_character":18},"updated":"2024-05-14 18:48:48.000000000","message":"Even though I know what this means, it took me a long time to unwrap this. You need a role on the project that owns the server/key for barbican, but you need \"admin\" in general to do the thing in nova. I kept reading this thinking you were saying that you needed admin-level permissions in barbican, which is not the case, you need admin for nova (for live migration or whatever).\n\nNot sure what to suggest without re-writing all this, but it might be good to try to clarify that so people don\u0027t think there\u0027s some other expectation here.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":false,"context_lines":[{"line_number":174,"context_line":"For admin-only APIs such as cold migration, live migration, and evacuate, the"},{"line_number":175,"context_line":"user calling Nova API to perform these server actions needs to be able to"},{"line_number":176,"context_line":"access the Barbican secrets of the owner of the server in addition to having"},{"line_number":177,"context_line":"the ``admin`` role. In a default Barbican configuration, secret ownership will"},{"line_number":178,"context_line":"be scoped to the project which created it, so in such an environment a user"},{"line_number":179,"context_line":"would need to be a `project administrator`_ or any user who has both project"},{"line_number":180,"context_line":"membership and the ``admin`` role."}],"source_content_type":"text/x-rst","patch_set":9,"id":"f91d2dcf_0a13d776","line":177,"range":{"start_line":177,"start_character":14,"end_line":177,"end_character":18},"in_reply_to":"07ad98d6_a8345697","updated":"2024-05-15 14:00:13.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":174,"context_line":"For admin-only APIs such as cold migration, live migration, and evacuate, the"},{"line_number":175,"context_line":"user calling Nova API to perform these server actions needs to be able to"},{"line_number":176,"context_line":"access the Barbican secrets of the owner of the server in addition to having"},{"line_number":177,"context_line":"the ``admin`` role. In a default Barbican configuration, secret ownership will"},{"line_number":178,"context_line":"be scoped to the project which created it, so in such an environment a user"},{"line_number":179,"context_line":"would need to be a `project administrator`_ or any user who has both project"},{"line_number":180,"context_line":"membership and the ``admin`` role."}],"source_content_type":"text/x-rst","patch_set":9,"id":"07ad98d6_a8345697","line":177,"range":{"start_line":177,"start_character":14,"end_line":177,"end_character":18},"in_reply_to":"ec2237f5_ce0905e2","updated":"2024-05-14 20:51:55.000000000","message":"Yeah, \"need access to the Barbican secrets of the server owner\" and \"need admin role\" as an additional thing was supposed to convey the separation but I can also understand why it may cause confusion. I think I can make this clearer by adding a couple of bullet points to separate Barbican permission vs Nova permission. I\u0027ll rewrite it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":221,"context_line":"Create a new key manager secret for each block device mapping"},{"line_number":222,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"The approach for disk image secrets that each disk image has a unique secret."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"For example:"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"059a3d38_2193bda2","line":224,"updated":"2024-05-14 18:48:48.000000000","message":"I think you\u0027re missing an \"is\" here or something.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":false,"context_lines":[{"line_number":221,"context_line":"Create a new key manager secret for each block device mapping"},{"line_number":222,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"The approach for disk image secrets that each disk image has a unique secret."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"For example:"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"21f34b45_1d804288","line":224,"in_reply_to":"0003c208_847c1343","updated":"2024-05-15 14:00:13.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":221,"context_line":"Create a new key manager secret for each block device mapping"},{"line_number":222,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"The approach for disk image secrets that each disk image has a unique secret."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"For example:"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"0003c208_847c1343","line":224,"in_reply_to":"059a3d38_2193bda2","updated":"2024-05-14 20:51:55.000000000","message":"Yes, I deleted some words and then missed the \"is\". I\u0027ll fix it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":264,"context_line":"   |                    | disk.swap   | Secret 3                             |                                                      |"},{"line_number":265,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":266,"context_line":"   | Image Z (snapshot) | disk (root) | Secret 4 (copy of Secret 1 by        | Secret 4 will **not** be automatically deleted and   |"},{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"dd22bd75_6607b4ec","line":267,"updated":"2024-05-14 18:48:48.000000000","message":"Something isn\u0027t quite rendering properly here.. half of the \"secret 4\" line is bold and the rest is not, but I expect none of it *should* be bold.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":false,"context_lines":[{"line_number":264,"context_line":"   |                    | disk.swap   | Secret 3                             |                                                      |"},{"line_number":265,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":266,"context_line":"   | Image Z (snapshot) | disk (root) | Secret 4 (copy of Secret 1 by        | Secret 4 will **not** be automatically deleted and   |"},{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"546d0d2d_8f2d3462","line":267,"in_reply_to":"b105afa0_aad73ac8","updated":"2024-05-15 14:00:13.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":264,"context_line":"   |                    | disk.swap   | Secret 3                             |                                                      |"},{"line_number":265,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":266,"context_line":"   | Image Z (snapshot) | disk (root) | Secret 4 (copy of Secret 1 by        | Secret 4 will **not** be automatically deleted and   |"},{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"b105afa0_aad73ac8","line":267,"in_reply_to":"dd22bd75_6607b4ec","updated":"2024-05-14 20:51:55.000000000","message":"Yeah it\u0027s not supposed to be bold. I\u0027ll figure out what\u0027s wrong with it and fix it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":271,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":272,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":273,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"f93eccce_36bcaaf9","line":270,"updated":"2024-05-14 18:48:48.000000000","message":"Secret 5 is for the root, and 6 is for the backing image, is that right? It seems confusing to list them in this order, but perhaps that\u0027s just me.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":false,"context_lines":[{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":271,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":272,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":273,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"062c8f69_0d691193","line":270,"in_reply_to":"5a27878c_431f4711","updated":"2024-05-15 14:00:13.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":267,"context_line":"   | created from       |             |           default)                   | manual deletion will be needed if/when Image Z is    |"},{"line_number":268,"context_line":"   | Instance A         |             |                                      | deleted from Glance                                  |"},{"line_number":269,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":270,"context_line":"   | Instance B         | disk (root) | Secret 5                             | Secret 5, 6, 7, and 8 will be automatically deleted  |"},{"line_number":271,"context_line":"   | created from       |             +--------------------------------------+ by Nova when Instance B is deleted and its disks are |"},{"line_number":272,"context_line":"   | Image Z (snapshot) |             | Secret 6 :sup:`*` (copy of Secret 4) | destroyed                                            |"},{"line_number":273,"context_line":"   |                    +-------------+--------------------------------------+                                                      |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"5a27878c_431f4711","line":270,"in_reply_to":"f93eccce_36bcaaf9","updated":"2024-05-14 20:51:55.000000000","message":"That\u0027s right. I can swap the order.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":289,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":290,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":291,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":292,"context_line":"   | Rescue disk        | disk (root) | None                                 | A rescue disk is only encrypted if an encrypted      |"},{"line_number":293,"context_line":"   | created by rescue  |             |                                      | rescue image was specified.                          |"},{"line_number":294,"context_line":"   | of Instance A      |             |                                      |                                                      |"},{"line_number":295,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":296,"context_line":"   | Rescue disk        | disk (root) | Secret of encrypted rescue image     | The secret of the encrypted rescue image will be     |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"59dc38ee_4d8c8d8f","line":293,"range":{"start_line":292,"start_character":79,"end_line":293,"end_character":106},"updated":"2024-05-15 11:37:48.000000000","message":"i tought at the ptg we agreed to encypt the rescue disk with the root disk secret?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":false,"context_lines":[{"line_number":289,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":290,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":291,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":292,"context_line":"   | Rescue disk        | disk (root) | None                                 | A rescue disk is only encrypted if an encrypted      |"},{"line_number":293,"context_line":"   | created by rescue  |             |                                      | rescue image was specified.                          |"},{"line_number":294,"context_line":"   | of Instance A      |             |                                      |                                                      |"},{"line_number":295,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":296,"context_line":"   | Rescue disk        | disk (root) | Secret of encrypted rescue image     | The secret of the encrypted rescue image will be     |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"bdb6c1a8_2c73a7b6","line":293,"range":{"start_line":292,"start_character":79,"end_line":293,"end_character":106},"in_reply_to":"4f477136_dfdfd864","updated":"2024-05-20 17:36:30.000000000","message":"fair im fine with not using the root image.\n\ni think the main intent was to not have to allocarte and track a sepreate secrete for the rescue disk while also not decypteing it when wrihting it to local storage\n\nso using the key form the encypted image or the root disk achive that goal.\n\nso lets go with what ever is simplest to implement.\n\nmel\u0027s point about recuing an unecypted instance with an encypted image is also a very good reason to use the encypted rescue image secret instead.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":true,"context_lines":[{"line_number":289,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":290,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":291,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":292,"context_line":"   | Rescue disk        | disk (root) | None                                 | A rescue disk is only encrypted if an encrypted      |"},{"line_number":293,"context_line":"   | created by rescue  |             |                                      | rescue image was specified.                          |"},{"line_number":294,"context_line":"   | of Instance A      |             |                                      |                                                      |"},{"line_number":295,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":296,"context_line":"   | Rescue disk        | disk (root) | Secret of encrypted rescue image     | The secret of the encrypted rescue image will be     |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"6fc3761f_b8dfa7d8","line":293,"range":{"start_line":292,"start_character":79,"end_line":293,"end_character":106},"in_reply_to":"59dc38ee_4d8c8d8f","updated":"2024-05-15 14:00:13.000000000","message":"I couldn\u0027t remember, but I think you\u0027re right. However, what\u0027s here makes sense I think. If the rescue image is encrypted the goal was to avoid writing some of it in non-encrypted format to the disk. Whether you use the root key or the rescue key doesn\u0027t much matter, IMHO, and there\u0027s no point in the overhead if the rescue image is not encrypted, IMHO.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":289,"context_line":"   |                    |             |                                      | we could create a new secret using the instance\u0027s    |"},{"line_number":290,"context_line":"   |                    |             |                                      | user/project rather than the shelver\u0027s user/project  |"},{"line_number":291,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":292,"context_line":"   | Rescue disk        | disk (root) | None                                 | A rescue disk is only encrypted if an encrypted      |"},{"line_number":293,"context_line":"   | created by rescue  |             |                                      | rescue image was specified.                          |"},{"line_number":294,"context_line":"   | of Instance A      |             |                                      |                                                      |"},{"line_number":295,"context_line":"   +--------------------+-------------+--------------------------------------+------------------------------------------------------+"},{"line_number":296,"context_line":"   | Rescue disk        | disk (root) | Secret of encrypted rescue image     | The secret of the encrypted rescue image will be     |"}],"source_content_type":"text/x-rst","patch_set":9,"id":"4f477136_dfdfd864","line":293,"range":{"start_line":292,"start_character":79,"end_line":293,"end_character":106},"in_reply_to":"6fc3761f_b8dfa7d8","updated":"2024-05-15 17:50:25.000000000","message":"Yes you are right, but what I realized while implementing it locally is that it\u0027s entirely possible to rescue an unencrypted instance using an encrypted image. I\u0027m not commenting on the usefulness of doing that but if someone does that, there won\u0027t be a root disk secret at all. So I just used the image secret instead, which is described in the next table row L296.\n\nOn this row we\u0027re commenting on now, this is saying that if an encrypted instance is rescued using an unencrypted image, the rescue disk will **not** be encrypted.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":408,"context_line":"       * ``existing``: The user will provide the UUID of an existing secret in"},{"line_number":409,"context_line":"         the key manager service to use to encrypt the image snapshot."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"       * ``none``: Do not encrypt the image snapshot."},{"line_number":412,"context_line":"   * - encryption.secret_uuid (Optional)"},{"line_number":413,"context_line":"     - body"},{"line_number":414,"context_line":"     - string"}],"source_content_type":"text/x-rst","patch_set":9,"id":"d472c8d6_3ec9d211","line":411,"range":{"start_line":411,"start_character":11,"end_line":411,"end_character":15},"updated":"2024-05-15 11:37:48.000000000","message":"nit: my personal prefernce would not be to use `none` but rather `unencrypted`\nor  something like `plain`, `clear`, `raw` ectra\n\neffectivly i dont like it when there is a delta between the meaning of python None\nand the string `none`\n\npython None i.e. this is not set because of an older microversion is going to be `same`","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":408,"context_line":"       * ``existing``: The user will provide the UUID of an existing secret in"},{"line_number":409,"context_line":"         the key manager service to use to encrypt the image snapshot."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"       * ``none``: Do not encrypt the image snapshot."},{"line_number":412,"context_line":"   * - encryption.secret_uuid (Optional)"},{"line_number":413,"context_line":"     - body"},{"line_number":414,"context_line":"     - string"}],"source_content_type":"text/x-rst","patch_set":9,"id":"b93a6ead_1dd68fcf","line":411,"range":{"start_line":411,"start_character":11,"end_line":411,"end_character":15},"in_reply_to":"084d83e4_de313c2d","updated":"2024-05-15 17:50:25.000000000","message":"\u003e ok none is fine  i had to fix \"unencrypted\" like 3 times to spell it right\n\n😂","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0a15c6e9527bda78882f2e0b6a487a5a215c8960","unresolved":true,"context_lines":[{"line_number":408,"context_line":"       * ``existing``: The user will provide the UUID of an existing secret in"},{"line_number":409,"context_line":"         the key manager service to use to encrypt the image snapshot."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"       * ``none``: Do not encrypt the image snapshot."},{"line_number":412,"context_line":"   * - encryption.secret_uuid (Optional)"},{"line_number":413,"context_line":"     - body"},{"line_number":414,"context_line":"     - string"}],"source_content_type":"text/x-rst","patch_set":9,"id":"084d83e4_de313c2d","line":411,"range":{"start_line":411,"start_character":11,"end_line":411,"end_character":15},"in_reply_to":"584d7313_4490b260","updated":"2024-05-15 15:15:44.000000000","message":"ok none is fine  i had to fix \"unencrypted\" like 3 times to spell it right","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":false,"context_lines":[{"line_number":408,"context_line":"       * ``existing``: The user will provide the UUID of an existing secret in"},{"line_number":409,"context_line":"         the key manager service to use to encrypt the image snapshot."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"       * ``none``: Do not encrypt the image snapshot."},{"line_number":412,"context_line":"   * - encryption.secret_uuid (Optional)"},{"line_number":413,"context_line":"     - body"},{"line_number":414,"context_line":"     - string"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1b296c6a_198b1d7a","line":411,"range":{"start_line":411,"start_character":11,"end_line":411,"end_character":15},"in_reply_to":"b93a6ead_1dd68fcf","updated":"2024-05-20 17:36:30.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8f1693a92796f0d66e2fd24ce57536061fe9fc81","unresolved":true,"context_lines":[{"line_number":408,"context_line":"       * ``existing``: The user will provide the UUID of an existing secret in"},{"line_number":409,"context_line":"         the key manager service to use to encrypt the image snapshot."},{"line_number":410,"context_line":""},{"line_number":411,"context_line":"       * ``none``: Do not encrypt the image snapshot."},{"line_number":412,"context_line":"   * - encryption.secret_uuid (Optional)"},{"line_number":413,"context_line":"     - body"},{"line_number":414,"context_line":"     - string"}],"source_content_type":"text/x-rst","patch_set":9,"id":"584d7313_4490b260","line":411,"range":{"start_line":411,"start_character":11,"end_line":411,"end_character":15},"in_reply_to":"d472c8d6_3ec9d211","updated":"2024-05-15 13:51:33.000000000","message":"My preference is \"none\". \"raw\" already has a meaning in the context of images. \"plain\" is not a type of encryption, IMHO. I *hate* typing the word \"encrypted\" and especially hate \"unencrypted\". I really don\u0027t think there\u0027s much worry of confusing python\u0027s None and this none, but even still, I would imagine this ends up with an *actual* None somewhere, which makes sense to me :)","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":451,"context_line":"    Ceph release Quincy (v17) and older do not support creating a cloned image"},{"line_number":452,"context_line":"    with an encryption key different from its parent. For this reason, the"},{"line_number":453,"context_line":"    ``encryption.key`` request parameter with a value of ``new`` will not be"},{"line_number":454,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":457,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"39a4511d_8cc5c9b9","line":454,"updated":"2024-05-14 18:48:48.000000000","message":"Since we won\u0027t know about this until the request is long since 202\u0027d what is the plan? Consider new-\u003eexisting for that case? Refuse the snapshot and error-out the action?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":true,"context_lines":[{"line_number":451,"context_line":"    Ceph release Quincy (v17) and older do not support creating a cloned image"},{"line_number":452,"context_line":"    with an encryption key different from its parent. For this reason, the"},{"line_number":453,"context_line":"    ``encryption.key`` request parameter with a value of ``new`` will not be"},{"line_number":454,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":457,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"c7da4451_dfe5c5fb","line":454,"in_reply_to":"0f104592_fdfad9ee","updated":"2024-05-20 17:36:30.000000000","message":"well in theory the user has to pool the instnace action event to see it succed/fail anyway.\n\ni now that does not really work right now but assuming we fixed that then i think the async error is ok.\n\nit would be nice to be able to detect it when we returned the 202 but we wont know the backend in use so the best we can do is fail late and notifiy the user that the snapshot failed via the instance action fault message.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":451,"context_line":"    Ceph release Quincy (v17) and older do not support creating a cloned image"},{"line_number":452,"context_line":"    with an encryption key different from its parent. For this reason, the"},{"line_number":453,"context_line":"    ``encryption.key`` request parameter with a value of ``new`` will not be"},{"line_number":454,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":457,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"cc54c789_2cc7e188","line":454,"in_reply_to":"39a4511d_8cc5c9b9","updated":"2024-05-14 20:51:55.000000000","message":"What do you mean by new-\u003eexisting? Or did you mean new-\u003esame? We won\u0027t be able to do \"existing\" if a secret UUID was not also specified in the request.\n\nI was thinking the latter, error the action with a message that explains that \"new\" is not supported in the deployment.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":451,"context_line":"    Ceph release Quincy (v17) and older do not support creating a cloned image"},{"line_number":452,"context_line":"    with an encryption key different from its parent. For this reason, the"},{"line_number":453,"context_line":"    ``encryption.key`` request parameter with a value of ``new`` will not be"},{"line_number":454,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":457,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"0f104592_fdfad9ee","line":454,"in_reply_to":"8b8baa81_48eed9d8","updated":"2024-05-15 17:50:25.000000000","message":"Yeah, I mean, I\u0027m not sure what\u0027s less user friendly -- failing the action to say \"I can\u0027t do what you have asked me to do\" vs performing the action giving the appearance of fulfilling the request while using something different than what was asked. If I were the user and if the action succeeded, I would think that the thing used the key that I told it to use. If I\u0027m in the minority opinion on that, then I guess I\u0027m open to the switcheroo.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":true,"context_lines":[{"line_number":451,"context_line":"    Ceph release Quincy (v17) and older do not support creating a cloned image"},{"line_number":452,"context_line":"    with an encryption key different from its parent. For this reason, the"},{"line_number":453,"context_line":"    ``encryption.key`` request parameter with a value of ``new`` will not be"},{"line_number":454,"context_line":"    supported with the ``rbd`` image backend for those versions of Ceph."},{"line_number":455,"context_line":""},{"line_number":456,"context_line":"    See https://github.com/ceph/ceph/commit/1d3de19 for reference."},{"line_number":457,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"8b8baa81_48eed9d8","line":454,"in_reply_to":"cc54c789_2cc7e188","updated":"2024-05-15 14:00:13.000000000","message":"\u003e What do you mean by new-\u003eexisting? Or did you mean new-\u003esame? We won\u0027t be able to do \"existing\" if a secret UUID was not also specified in the request.\n\nYep, I meant new-\u003esame for the obvious reason you note :)\n\n\u003e I was thinking the latter, error the action with a message that explains that \"new\" is not supported in the deployment.\n\nOkay. Feels like it\u0027s going to be not very user-friendly to do that, but I don\u0027t know what else to suggest. I think an error in whatever form is the right thing to do regardless.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":490,"context_line":"          \"secret_uuid\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":491,"context_line":"      }"},{"line_number":492,"context_line":"   }"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":".. _`create image API`: https://docs.openstack.org/api-ref/compute/#create-image-createimage-action"},{"line_number":495,"context_line":".. _`access control list`: https://docs.openstack.org/barbican/latest/admin/access_control.html"},{"line_number":496,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"88e9eb51_21d25444","line":493,"updated":"2024-05-14 18:48:48.000000000","message":"So, you\u0027re going to create the new secret in the API if requested and return it? That\u0027s probably nice for the user, but not necessary as long as it\u0027s stashed on the image right? Point being, if you\u0027re going to do this, I think you need to error out the snapshot in the ceph case so that you don\u0027t say \"It will be encrypted with this key\" and then .. actually use the existing one.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":true,"context_lines":[{"line_number":490,"context_line":"          \"secret_uuid\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":491,"context_line":"      }"},{"line_number":492,"context_line":"   }"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":".. _`create image API`: https://docs.openstack.org/api-ref/compute/#create-image-createimage-action"},{"line_number":495,"context_line":".. _`access control list`: https://docs.openstack.org/barbican/latest/admin/access_control.html"},{"line_number":496,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"d2ccd92a_d3a1a83b","line":493,"in_reply_to":"32a45566_cd59575e","updated":"2024-05-15 14:00:13.000000000","message":"Also, creating the secret in the API and returning it means you are more likely to leak it if we don\u0027t end up using it for some reason right?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":490,"context_line":"          \"secret_uuid\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":491,"context_line":"      }"},{"line_number":492,"context_line":"   }"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":".. _`create image API`: https://docs.openstack.org/api-ref/compute/#create-image-createimage-action"},{"line_number":495,"context_line":".. _`access control list`: https://docs.openstack.org/barbican/latest/admin/access_control.html"},{"line_number":496,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"32a45566_cd59575e","line":493,"in_reply_to":"88e9eb51_21d25444","updated":"2024-05-14 20:51:55.000000000","message":"Oh, yeah, I suppose it\u0027s not really necessary. Maybe I should remove it.\n\nTo your other point, I think either way I need to error out the snapshot action if I use a different key than was specified in the request and can\u0027t honor it.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":490,"context_line":"          \"secret_uuid\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":491,"context_line":"      }"},{"line_number":492,"context_line":"   }"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":".. _`create image API`: https://docs.openstack.org/api-ref/compute/#create-image-createimage-action"},{"line_number":495,"context_line":".. _`access control list`: https://docs.openstack.org/barbican/latest/admin/access_control.html"},{"line_number":496,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"edca7ecc_758ca59f","line":493,"in_reply_to":"d2ccd92a_d3a1a83b","updated":"2024-05-15 17:50:25.000000000","message":"Yeah ... I actually just realized it won\u0027t even be possible to return the secret UUID in the API response because a new secret will be generated after the RPC cast. So yeah, I\u0027ll remove this.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e7475ac99373df5c5c02ccd9bd40eab9aabb9b78","unresolved":false,"context_lines":[{"line_number":490,"context_line":"          \"secret_uuid\": \"\u003csecret uuid used to encrypt the image snapshot\u003e\""},{"line_number":491,"context_line":"      }"},{"line_number":492,"context_line":"   }"},{"line_number":493,"context_line":""},{"line_number":494,"context_line":".. _`create image API`: https://docs.openstack.org/api-ref/compute/#create-image-createimage-action"},{"line_number":495,"context_line":".. _`access control list`: https://docs.openstack.org/barbican/latest/admin/access_control.html"},{"line_number":496,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"b68ef7c1_eea176e1","line":493,"in_reply_to":"edca7ecc_758ca59f","updated":"2024-05-20 16:43:54.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"92a718ac5766f2af8af412e241aea5db7a3aad39","unresolved":true,"context_lines":[{"line_number":540,"context_line":""},{"line_number":541,"context_line":"When rescuing an instance and an encrypted rescue image is specified, the"},{"line_number":542,"context_line":"rescue image secret UUID from the image property will be used to encrypt the"},{"line_number":543,"context_line":"rescue disk. A new key manager secret will not be created."},{"line_number":544,"context_line":""},{"line_number":545,"context_line":"The new virt driver secret will be created for the rescue disk and is deleted"},{"line_number":546,"context_line":"when the instance is unrescued."}],"source_content_type":"text/x-rst","patch_set":9,"id":"10262362_0ada6d6a","line":543,"updated":"2024-05-15 11:37:48.000000000","message":"i guess that works the alternative was the root disks secret.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":540,"context_line":""},{"line_number":541,"context_line":"When rescuing an instance and an encrypted rescue image is specified, the"},{"line_number":542,"context_line":"rescue image secret UUID from the image property will be used to encrypt the"},{"line_number":543,"context_line":"rescue disk. A new key manager secret will not be created."},{"line_number":544,"context_line":""},{"line_number":545,"context_line":"The new virt driver secret will be created for the rescue disk and is deleted"},{"line_number":546,"context_line":"when the instance is unrescued."}],"source_content_type":"text/x-rst","patch_set":9,"id":"a42d4b4e_5025b253","line":543,"in_reply_to":"10262362_0ada6d6a","updated":"2024-05-15 17:50:25.000000000","message":"I mentioned in a comment on an earlier line that if an encrypted rescue image is specified but the instance does not have an encrypted root disk, there won\u0027t be a root disk secret at all. And similar to what Dan said earlier, I didn\u0027t think it matters too much which existing secret is used?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":false,"context_lines":[{"line_number":540,"context_line":""},{"line_number":541,"context_line":"When rescuing an instance and an encrypted rescue image is specified, the"},{"line_number":542,"context_line":"rescue image secret UUID from the image property will be used to encrypt the"},{"line_number":543,"context_line":"rescue disk. A new key manager secret will not be created."},{"line_number":544,"context_line":""},{"line_number":545,"context_line":"The new virt driver secret will be created for the rescue disk and is deleted"},{"line_number":546,"context_line":"when the instance is unrescued."}],"source_content_type":"text/x-rst","patch_set":9,"id":"f4e03c62_a3261f51","line":543,"in_reply_to":"a42d4b4e_5025b253","updated":"2024-05-20 17:36:30.000000000","message":"nope it doesn\u0027t, i had not considered using an encypted image to resuce an unencypted isntances.\n\nso let proceed with what you wrote","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2c8830465630e3f5b42ae807e0eb5a4d68210096","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"b7b8389f_76bd572e","line":570,"updated":"2024-05-14 18:48:48.000000000","message":"Right, so why aren\u0027t we specifying using the new generic ones in this spec instead of introducing new ones? AFAIK, cinder is the only one that has pre-existing art here that will have to handle their names and the new standard ones. Shouldn\u0027t this spec start using the common-named keys from the start?","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"93680d3a325b82d18f4e5cccd2efe5a1a88c6231","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"b29409cc_a6786cec","line":570,"in_reply_to":"38e57167_303c8359","updated":"2024-05-22 14:22:19.000000000","message":"if we are to use the new common keys which dont follow our api convention (project are not not ment ot use the project name in any user facing api i.e. glance should not use os_glance as the image property namespace the sameway nova shouldn not use nova we are ment ot use compute) i really think we should consider if the props names are correct before standardising on them.\n\nin anycase if its an image properly that nova will use we would need to extend the nova image_meta object to hold them.\n\nim also not sure that glance has completed standariseing them yet\n\ni dont see them in https://opendev.org/openstack/glance/src/branch/master/etc/metadefs/glance-common-image-props.json\nor\nhttps://opendev.org/openstack/glance/src/branch/master/etc/metadefs/operating-system.json\nor any other file\n\nso form my point of view they have not actully standardised anythign yet.\n\nthe spec that was defineing them is not even marked as implemented.\n\nso form my perspective there are several reaosn nto to use them most notable the os_glance prefix which should really be removed.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"723a9643_c323242b","line":570,"in_reply_to":"602994e6_29faf628","updated":"2024-05-23 10:55:08.000000000","message":"Acknowledged","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7977cd9f235b4aef9135fd258c6a53b744eb4a6d","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"602994e6_29faf628","line":570,"in_reply_to":"b29409cc_a6786cec","updated":"2024-05-22 19:31:47.000000000","message":"This is probably addressed by my other reply but the proposed properties no longer have the ``os_glance`` prefix, it was removed.\n\nThe new properties are not completed yet as the spec is not merged yet but these were discussed recently with the Glance team at the PTG and we had consensus on the names that are currently in the spec. To be safe we will Depends-On on the spec on the first patch that uses them, so we don\u0027t accidentally merge our use of them before the Glance spec merges.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cd331a80edb42e49d2c67f98c12664016f5bd6f9","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"e3c2376d_6e548733","line":570,"in_reply_to":"b7b8389f_76bd572e","updated":"2024-05-14 20:51:55.000000000","message":"I wasn\u0027t 100% sure as the Glance spec isn\u0027t approved yet, so I left it as-is for the moment. I assumed I would have to respin this spec for reasons other than this anyway.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8ccd1ac27431a7ca51154521211339576f719a68","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"fce62bd2_b29ea259","line":570,"in_reply_to":"e3c2376d_6e548733","updated":"2024-05-15 14:00:13.000000000","message":"Okay I think we should assume we will. We\u0027re not committed until we\u0027re ready to merge our API code. We could depends-on their spec to prevent am early merge and if we decide we need to go without, we at least have the reminder to remove the depends-on and change our code back (hope we don\u0027t do that, but...)","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ce32d258201e16be49a7ae87f9c72508b74b2828","unresolved":true,"context_lines":[{"line_number":567,"context_line":"   There is opportunity to create common image properties for all projects to"},{"line_number":568,"context_line":"   use when working with encrypted Glance images. Both Cinder and Nova have"},{"line_number":569,"context_line":"   encrypted image snapshot features. The common image properties and formats"},{"line_number":570,"context_line":"   are proposed in the following Glance spec:"},{"line_number":571,"context_line":""},{"line_number":572,"context_line":"   https://review.opendev.org/c/openstack/glance-specs/+/915726"},{"line_number":573,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"38e57167_303c8359","line":570,"in_reply_to":"fce62bd2_b29ea259","updated":"2024-05-15 17:50:25.000000000","message":"That sounds like a reasonable plan.","commit_id":"10bdb336863671a41104ea3b31b6cab98fafe899"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"20001e6b1ec2978d39498055eebec6be25c326f3","unresolved":true,"context_lines":[{"line_number":127,"context_line":"will be kept with the image using a standardized Glance image property:"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"* ``os_encrypt_key_id``"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":132,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":133,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"e54dd3b7_bd48aa44","line":130,"updated":"2024-05-20 17:36:30.000000000","message":"we shoudld refernce \n\n\n    \u0027os_glance_encrypt_format\u0027 - the main mechanism used, e.g. \u0027GPG\u0027\n    \u0027os_glance_encrypt_type\u0027 - encryption type, e.g. \u0027symmetric\u0027\n    \u0027os_glance_encrypt_cipher\u0027 - the cipher algorithm, e.g. \u0027AES256\u0027\n    \u0027os_glance_encrypt_key_id\u0027 - reference to key in the key manager\n    \u0027os_glance_decrypt_container_format\u0027 - format after payload decryption\n    \u0027os_glance_decrypt_size\u0027 - size after payload decryption\n\nhere also right\nsince that will be how we encode the format of the snapshot in glance?","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7977cd9f235b4aef9135fd258c6a53b744eb4a6d","unresolved":false,"context_lines":[{"line_number":127,"context_line":"will be kept with the image using a standardized Glance image property:"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"* ``os_encrypt_key_id``"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"The secret UUID is needed when creating an instance from an ephemeral encrypted"},{"line_number":132,"context_line":"snapshot or when unshelving an ephemeral encrypted instance."},{"line_number":133,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"cad141bf_6b8c06ae","line":130,"in_reply_to":"e54dd3b7_bd48aa44","updated":"2024-05-22 19:31:47.000000000","message":"Done","commit_id":"b585bb9dd1b9dfa07b6dc36a78499a1f5e75ce43"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":true,"context_lines":[{"line_number":79,"context_line":"   The following ``hw_ephemeral_encryption`` image properties do not relate to"},{"line_number":80,"context_line":"   if an image is encrypted at rest within the Glance service. They only relate"},{"line_number":81,"context_line":"   to how ephemeral storage will be encrypted at rest when used by a"},{"line_number":82,"context_line":"   provisioned instance within Nova."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Allow ephemeral encryption to be configured by flavor, image, or config"},{"line_number":85,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"2a13d7c8_7b95e8da","line":82,"updated":"2024-05-23 10:55:08.000000000","message":"+1","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"93680d3a325b82d18f4e5cccd2efe5a1a88c6231","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":101,"context_line":"of the encryption secret for the resultant image will be kept with the image"},{"line_number":102,"context_line":"using a standardized Glance image property |Glance spec|_:"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"* ``os_encrypt_key_id``"},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"a5209786_32e8ed08","line":102,"updated":"2024-05-22 14:22:19.000000000","message":"as noted elsehwere that spec was never fully implemented and there are no metadefs created for the “standardised” image properties and the propsoed one violate the api rule about not using the project name in api resoucces.\n\nso unless cinder is already using them i thinik we should revisit that with glance.\n\nwe should baiscally either remove the os_glance namespace or replace it with “standard” or “common”\n\nusing them in nova means codifying the names in our image_meta object so before that we should check with glance what the status of the standarisation is and is it too late to change the names.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":false,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":101,"context_line":"of the encryption secret for the resultant image will be kept with the image"},{"line_number":102,"context_line":"using a standardized Glance image property |Glance spec|_:"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"* ``os_encrypt_key_id``"},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"6ea0a4b2_55cf6637","line":102,"in_reply_to":"a4b3c058_4068e268","updated":"2024-05-23 10:55:08.000000000","message":"sweet that works for me.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7977cd9f235b4aef9135fd258c6a53b744eb4a6d","unresolved":true,"context_lines":[{"line_number":99,"context_line":""},{"line_number":100,"context_line":"To enable snapshot and shelve of instances using ephemeral encryption, the UUID"},{"line_number":101,"context_line":"of the encryption secret for the resultant image will be kept with the image"},{"line_number":102,"context_line":"using a standardized Glance image property |Glance spec|_:"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"* ``os_encrypt_key_id``"},{"line_number":105,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"a4b3c058_4068e268","line":102,"in_reply_to":"a5209786_32e8ed08","updated":"2024-05-22 19:31:47.000000000","message":"It\u0027s true they are not implemented yet -- so no one is using them yet. But the updated spec is proposed for Dalmatian here:\n\nhttps://review.opendev.org/c/openstack/glance-specs/+/915726\n\nThey have already removed the ``os_glance`` prefix from the properties in the proposal. They are now prefixed with ``os_encrypt``.\n\nThe plan is to go ahead and use the ``os_encrypt*`` names in our proposed patches and Depends-On the Glance spec. In the worst case of the Glance spec not merging at all, it will remind us to change back to our own names before merge.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"93680d3a325b82d18f4e5cccd2efe5a1a88c6231","unresolved":true,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"and if neither are specified, the format would be taken from"},{"line_number":134,"context_line":"``[ephemeral_storage_encryption]/default_format`` after an instance lands on"},{"line_number":135,"context_line":"a compute host."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Management of secret data with the Key Manager service"},{"line_number":138,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5719243b_48eee4b9","line":135,"updated":"2024-05-22 14:22:19.000000000","message":"or the glance image encyption image property if the source image is encypted","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7977cd9f235b4aef9135fd258c6a53b744eb4a6d","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"and if neither are specified, the format would be taken from"},{"line_number":134,"context_line":"``[ephemeral_storage_encryption]/default_format`` after an instance lands on"},{"line_number":135,"context_line":"a compute host."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Management of secret data with the Key Manager service"},{"line_number":138,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"016aab80_179ebcc2","line":135,"in_reply_to":"5719243b_48eee4b9","updated":"2024-05-22 19:31:47.000000000","message":"Done","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":true,"context_lines":[{"line_number":844,"context_line":"parameters is planned to be added in a separate patch later in the series."},{"line_number":845,"context_line":""},{"line_number":846,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":847,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":848,"context_line":""},{"line_number":849,"context_line":"New ``nova-manage`` and ``nova-status`` commands will be introduced to migrate"},{"line_number":850,"context_line":"any instances using the legacy libvirt virt driver implementation ahead of the"}],"source_content_type":"text/x-rst","patch_set":11,"id":"6f682a1e_bd9daf05","line":847,"updated":"2024-05-23 10:55:08.000000000","message":"so i dont really want to reopen this but i think we likely can do better then a nova mange command and just have init_host do everything that is requried to back populate the image properties in the instance_system_metadata table in the release that adds supprot for this to lvm.\n\nnova-manage is not really intneded to be run on compute nodes and it would need info form the nova.conf on the compute node to populate teh required info i belive.\n\nnova-compute on the ohter hand has all the requried info.\n\nwe can debate that however in the release that implementes this migration path which will not be this one so treat this as a nit.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"aedb3d950867c0f55a686323d13c93d8ef003b9a","unresolved":true,"context_lines":[{"line_number":844,"context_line":"parameters is planned to be added in a separate patch later in the series."},{"line_number":845,"context_line":""},{"line_number":846,"context_line":"Provide a migration path from the legacy implementation"},{"line_number":847,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":848,"context_line":""},{"line_number":849,"context_line":"New ``nova-manage`` and ``nova-status`` commands will be introduced to migrate"},{"line_number":850,"context_line":"any instances using the legacy libvirt virt driver implementation ahead of the"}],"source_content_type":"text/x-rst","patch_set":11,"id":"b8185b13_98293873","line":847,"in_reply_to":"6f682a1e_bd9daf05","updated":"2024-05-23 16:37:23.000000000","message":"Ack, understood. If we can do better than a nova-manage command, I\u0027m on board. TBH I haven\u0027t thought as deeply into this piece as there is a lot going on here in this monster spec 😆 Agree let\u0027s get into the details in the future when we implement migration.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9fa03cd0c90d81cb2ff64616746ba504374e3232","unresolved":true,"context_lines":[{"line_number":895,"context_line":"  options will be rejected."},{"line_number":896,"context_line":""},{"line_number":897,"context_line":"* Attempts to rebuild between images that differ in their ephemeral encryption"},{"line_number":898,"context_line":"  options will be allowed by the user who owns the instance. Requests to"},{"line_number":899,"context_line":"  rebuild between images that differ in their ephemeral encryption options will"},{"line_number":900,"context_line":"  be rejected. This is to prevent a change in the ownership of secrets for the"},{"line_number":901,"context_line":"  instance disks."},{"line_number":902,"context_line":""},{"line_number":903,"context_line":"* The metadata API will be changed to allow users to determine if their"}],"source_content_type":"text/x-rst","patch_set":11,"id":"7c761697_3135c349","line":900,"range":{"start_line":898,"start_character":61,"end_line":900,"end_character":13},"updated":"2024-05-23 10:55:08.000000000","message":"nit: this reads as a controdiction to the previos sentance.\n\ni assume you mean we will reject rebuilds to a diffent image if you are not the owner of the instance.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"aedb3d950867c0f55a686323d13c93d8ef003b9a","unresolved":true,"context_lines":[{"line_number":895,"context_line":"  options will be rejected."},{"line_number":896,"context_line":""},{"line_number":897,"context_line":"* Attempts to rebuild between images that differ in their ephemeral encryption"},{"line_number":898,"context_line":"  options will be allowed by the user who owns the instance. Requests to"},{"line_number":899,"context_line":"  rebuild between images that differ in their ephemeral encryption options will"},{"line_number":900,"context_line":"  be rejected. This is to prevent a change in the ownership of secrets for the"},{"line_number":901,"context_line":"  instance disks."},{"line_number":902,"context_line":""},{"line_number":903,"context_line":"* The metadata API will be changed to allow users to determine if their"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1e64904e_525c4c5c","line":900,"range":{"start_line":898,"start_character":61,"end_line":900,"end_character":13},"in_reply_to":"7c761697_3135c349","updated":"2024-05-23 16:37:23.000000000","message":"Yes, that is what I meant but the paragraph here got mixed up. I probably reworded or added something and forgot to delete something. Thanks for pointing it out.","commit_id":"974a79a1c28f8c0581060732356965b99b6b8c53"}]}