)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"11512ba7b698dba9f218427ede3015e5dcbe4084","unresolved":true,"context_lines":[{"line_number":5,"context_line":"CommitDate: 2025-10-01 20:49:09 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"TPM: support live migration of `host` secret security"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Related to blueprint vtpm-live-migration"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: I97e9dd454c793abcb1a20579b1ceaec627be4813"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":27,"id":"29a1b7d0_cad86636","line":8,"updated":"2025-10-02 22:29:22.000000000","message":"Note to self: need to add a reno to this patch.","commit_id":"c514d51c427c612099da7f7b217b959655151f37"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e15a37db60985e36afe1d1a5a861ae9badbae6a9","unresolved":false,"context_lines":[{"line_number":5,"context_line":"CommitDate: 2025-10-01 20:49:09 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"TPM: support live migration of `host` secret security"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Related to blueprint vtpm-live-migration"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: I97e9dd454c793abcb1a20579b1ceaec627be4813"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":27,"id":"e0ff06ab_3c2bc825","line":8,"in_reply_to":"29a1b7d0_cad86636","updated":"2025-10-10 03:34:53.000000000","message":"Acknowledged","commit_id":"c514d51c427c612099da7f7b217b959655151f37"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"5edd03262b723a9640a17afa4fdf8aedacd8a6c1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"33ad7b06_13f050d2","updated":"2025-03-30 03:44:28.000000000","message":"recheck","commit_id":"512252ad27506c8029a06fc78f6d3ff3c215f265"},{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"1c0c7c33c7d7771bcc778f810e8032dde0f98f92","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"a90bc6cc_e823047e","updated":"2025-06-16 06:25:04.000000000","message":"LGTM.","commit_id":"cdde3644ba265001ddd4986cc2270acf94928564"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0f8b6bb9f256753bd10ea719802a94a312066da7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":27,"id":"e3909ebc_fa2b762a","updated":"2025-10-03 05:43:25.000000000","message":"recheck ssh pubkey auth failed and guest kernel panic","commit_id":"c514d51c427c612099da7f7b217b959655151f37"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"55a038bd6c4cd601d3e74587a08b6bb7f192912a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":30,"id":"34227d4a_7af8f564","updated":"2025-10-15 15:16:56.000000000","message":"recheck instance unshelve failed due to timeout waiting for vif plugged event\n\n```\n[instance: 1b66ca69-b5e2-46d8-947d-3aeaa16b64b5] Timeout waiting for [\u0027network-vif-plugged-f99e3cb0-af16-44a0-b3dd-ac3476930a0e\u0027] for instance with vm_state shelved_offloaded and task_state spawning. Event states are: network-vif-plugged-f99e3cb0-af16-44a0-b3dd-ac3476930a0e: timed out after 300.00 seconds: eventlet.timeout.Timeout: 300 seconds\n```","commit_id":"05b2c28115badda934cb72b3194d725aceb65690"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"199d24ba81fc199b2de164d048387dbe9d743ffe","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":32,"id":"dddcbc9a_82ce6c95","updated":"2025-10-21 03:06:29.000000000","message":"recheck NoValidHost due to placement unable to find hosts with 1 DISK_GB, seems to be a problem with ceph","commit_id":"789e704304edc72692db8f5a97cdc6eb98a5070e"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ab29c653837e54fe22fb92decda4fabfda76bb20","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":37,"id":"814d97dd_24d4b76e","updated":"2025-11-10 23:25:02.000000000","message":"recheck guest kernel panic","commit_id":"5602db40bd67cefb47fbc6a607c09fcd094c5006"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"02bb671cc3426d7390e2397d7607683bb876e64d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":49,"id":"fe2efd64_e9d041bb","updated":"2026-02-06 19:20:31.000000000","message":"I haven\u0027t gone through the tests yet, but wanted to commit a few comments and the question about the secret encoding.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7036e03d17ec55ea9a73570975543085b7b60516","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"c7724382_f99b14c3","updated":"2026-02-09 20:20:07.000000000","message":"A couple comments in the tests, but I think those can go to a follow up. Otherwise this seems pretty comprehensively tested, nice job :)","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ac0f8ff031aef8c1d971fe5c4d5422f56b167431","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"7ff6d9e8_3fd14e56","updated":"2026-02-10 19:09:56.000000000","message":"As discussed, we are fully in control of the synthesis of the _passphrase_ secret which will always be text and thus always be encode/decode-able. We can punt some additional error checking to a follow-up and argue about the bounds of that later.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9626254c58e900fa87e2f30176ecd8527bcf6e64","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"950bb682_b49df124","updated":"2026-02-11 02:13:14.000000000","message":"Did these doc and release note changes in the service bump patch:\n\nhttps://review.opendev.org/c/openstack/nova/+/975724","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b0bf3f04ab59c7382619b4116bdfc6ccaea6ea22","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"fc4b2649_03292316","updated":"2026-02-10 22:23:40.000000000","message":"Fixups have been proposed in the next patch:\n\nhttps://review.opendev.org/c/openstack/nova/+/976316","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"3ecf0b14_2520735d","updated":"2026-02-10 11:14:40.000000000","message":"a bit afraid of the very poor interface definition we have for getting secrets but I don\u0027t want to hold the series for now, so leaving +1 to signal my reluctance and I could +2 it once we agree on the FUP.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"7326d950d811ac25ff90e58530956cc0915c8bbf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":50,"id":"28556cf4_f8a87e60","updated":"2026-02-10 17:45:56.000000000","message":"as we discussed on the channel, I don\u0027t want to hold this change because of my concern, we could have another follow-up and discuss about what we would prefer there.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"}],"doc/source/admin/emulated-tpm.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"02bb671cc3426d7390e2397d7607683bb876e64d","unresolved":true,"context_lines":[{"line_number":81,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":82,"context_line":"       the owner of the server (the user who initially created it). The libvirt"},{"line_number":83,"context_line":"       secret is both ``private`` and ``ephemeral``. A server with this"},{"line_number":84,"context_line":"       security mode cannot be live migrated. This is the default mode."},{"line_number":85,"context_line":"   * - ``host``"},{"line_number":86,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":87,"context_line":"       the owner of the server (the user who initially created it). The libvirt"}],"source_content_type":"text/x-rst","patch_set":49,"id":"dd61f208_df48f51d","line":84,"updated":"2026-02-06 19:20:31.000000000","message":"I wonder if we also want (here or in a ..note) that this is the mode anything created before 33.0.0 will be in. The fact that it\u0027s the default going forward is a good signal that it is, but since you call out the \"live migration after $ver\" above, it might be nice to have it explicitly here as well.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9626254c58e900fa87e2f30176ecd8527bcf6e64","unresolved":false,"context_lines":[{"line_number":81,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":82,"context_line":"       the owner of the server (the user who initially created it). The libvirt"},{"line_number":83,"context_line":"       secret is both ``private`` and ``ephemeral``. A server with this"},{"line_number":84,"context_line":"       security mode cannot be live migrated. This is the default mode."},{"line_number":85,"context_line":"   * - ``host``"},{"line_number":86,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":87,"context_line":"       the owner of the server (the user who initially created it). The libvirt"}],"source_content_type":"text/x-rst","patch_set":49,"id":"c7ee3bd4_724e88cc","line":84,"in_reply_to":"05d6907f_f9b5c7f2","updated":"2026-02-11 02:13:14.000000000","message":"Done","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f61b7a7820563666a759698da7fdb247ca1baa2a","unresolved":true,"context_lines":[{"line_number":81,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":82,"context_line":"       the owner of the server (the user who initially created it). The libvirt"},{"line_number":83,"context_line":"       secret is both ``private`` and ``ephemeral``. A server with this"},{"line_number":84,"context_line":"       security mode cannot be live migrated. This is the default mode."},{"line_number":85,"context_line":"   * - ``host``"},{"line_number":86,"context_line":"     - The passphrase in the key manager is associated with the credentials of"},{"line_number":87,"context_line":"       the owner of the server (the user who initially created it). The libvirt"}],"source_content_type":"text/x-rst","patch_set":49,"id":"05d6907f_f9b5c7f2","line":84,"in_reply_to":"dd61f208_df48f51d","updated":"2026-02-06 20:27:01.000000000","message":"Sure, I can mention that in here. Note that this doc change has moved to its own patch later in the series to go with the service version bump:\nhttps://review.opendev.org/c/openstack/nova/+/975724","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"02bb671cc3426d7390e2397d7607683bb876e64d","unresolved":true,"context_lines":[{"line_number":175,"context_line":"  device files on the host. Thus the admin may need to decide whether to grant"},{"line_number":176,"context_line":"  the user additional policy roles; if not, those operations are effectively"},{"line_number":177,"context_line":"  disabled. The exception is live migration, which can be performed if the"},{"line_number":178,"context_line":"  server has TPM secret security mode ``host``."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"* Rebuild, evacuate, shelve, and rescue of servers with vTPMs is not currently"},{"line_number":181,"context_line":"  supported. Live migration with vTPMs is only supported for the ``host``"}],"source_content_type":"text/x-rst","patch_set":49,"id":"b7291347_cba90bbc","line":178,"updated":"2026-02-06 19:20:31.000000000","message":"Even with host, start (after stop) and things like that are also accessible by the admin. I feel like maybe this needs a more substantial rewrite.. Sort of a \"limitations depend on the mode\" and then a description of each.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9626254c58e900fa87e2f30176ecd8527bcf6e64","unresolved":false,"context_lines":[{"line_number":175,"context_line":"  device files on the host. Thus the admin may need to decide whether to grant"},{"line_number":176,"context_line":"  the user additional policy roles; if not, those operations are effectively"},{"line_number":177,"context_line":"  disabled. The exception is live migration, which can be performed if the"},{"line_number":178,"context_line":"  server has TPM secret security mode ``host``."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"* Rebuild, evacuate, shelve, and rescue of servers with vTPMs is not currently"},{"line_number":181,"context_line":"  supported. Live migration with vTPMs is only supported for the ``host``"}],"source_content_type":"text/x-rst","patch_set":49,"id":"3d62d280_2cd6957c","line":178,"in_reply_to":"8b551c8d_c8c675c4","updated":"2026-02-11 02:13:14.000000000","message":"Done","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f61b7a7820563666a759698da7fdb247ca1baa2a","unresolved":true,"context_lines":[{"line_number":175,"context_line":"  device files on the host. Thus the admin may need to decide whether to grant"},{"line_number":176,"context_line":"  the user additional policy roles; if not, those operations are effectively"},{"line_number":177,"context_line":"  disabled. The exception is live migration, which can be performed if the"},{"line_number":178,"context_line":"  server has TPM secret security mode ``host``."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"* Rebuild, evacuate, shelve, and rescue of servers with vTPMs is not currently"},{"line_number":181,"context_line":"  supported. Live migration with vTPMs is only supported for the ``host``"}],"source_content_type":"text/x-rst","patch_set":49,"id":"8b551c8d_c8c675c4","line":178,"in_reply_to":"b7291347_cba90bbc","updated":"2026-02-06 20:27:01.000000000","message":"Sure I can write more details in here. I\u0027ll make the updates in the service bump patch where these changes have been moved.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"}],"nova/compute/api.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7abef2c00b4a08fc14fb376fcecf3fea9f938fe2","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"3919b67a_64c6f0ec","line":5585,"updated":"2025-08-06 18:03:28.000000000","message":"Hmm, so, if the instance has host, it has to be new enough to be on a compute that supports this stuff. And you\u0027re assuming that the scheduler has chosen a destination that also supports host, and thus removing this block and replacing it with just a block for !\u003d host will be safe? (i.e. safe to not check service version or similar like normal).","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b7ef7c8879c7b98e7ebde37d4b10398b15904c97","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"a192b371_c953e2a2","line":5585,"in_reply_to":"3919b67a_64c6f0ec","updated":"2025-08-06 18:55:06.000000000","message":"Right, only instances with \u0027host\u0027 or \u0027deployment\u0027 image_hw_tpm_secret_security in system metadata are eligible for live migration. (\u0027deployment\u0027 gets added to the check in the next patch after this one).\n\nAnd then for scheduling, eligible instances will require the corresponding compute host traits so they won\u0027t be attempted to send to old computes (unless force live migration is used). That (force) was the only place I thought maybe a service version bump could help is that then we could block force live migration to an old compute in this specific case.\n\nI\u0027m good with bumping the version to block that specific case but I wasn\u0027t sure what others might think about it.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f8bc46bbe27eeb78f1ec79040932d9e3fa2db062","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"9c3ad006_0182ba28","line":5585,"in_reply_to":"8fa4dc44_ef436ed2","updated":"2025-08-15 07:22:04.000000000","message":"* fine grained live migration: As that is used during upgrade to drain hosts when needed I would say it is pretty useful to have it. Especially if it is not require a whole bunch of new complexity top of the current series. (Without reading the whole series I think it is mostly in place already)\n\n* force migration checks: obviously force migration is pretty harsh measure especially as the admin requested to skip the scheduler safety checks. I\u0027m OK not to add extra checks in place for this as the admin already asked us to skip checks. But I\u0027m not sure what is the consequence of such forced live migration to an old host. Will the migration fail cleanly even if it fails late or we end up in a corrupted state?","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"979ab9790e3d663d7e8b898daf803c1f72ed0e03","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"adb2926f_5e89ea39","line":5585,"in_reply_to":"9c3ad006_0182ba28","updated":"2025-08-15 18:56:30.000000000","message":"Thanks gibi.\n\nYou are right, the fine-grained live migration is already in place in the series -- it is really quite automatic because the moves require the compute traits. I think it would be nice to keep it.\n\nFor force migration, for new computes I added a patch to the series to do a late check similar to the late affinity check on compute. So that part is covered.\n\nAs for the consequence of forcing a move to an old compute, I think it would qualify more as \"corrupted\". Some of the issues:\n\n* Once the instance goes to the old compute, it will not be able to live migrate again until the compute is upgraded\n\n* Once the instance goes to the old compute, if the instance was using secret security policy \u0027deployment\u0027, then its Barbican secret is owned by the Nova service user. So any action which would cause libvirt guest creation again (like hard reboot or suspend/resume, etc) would leave the guest unable to start until the compute is upgraded because the user token will not be able to access the Barbican secret owned by the Nova service user\n\nBased on this, I\u0027m thinking maybe the best thing to do is bump the service version and then do a service version check in nova-api and if the version of the destination is older, reject the force live migration request.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e2f541cbf0289b025c4ecbdc476c2a44014c4e69","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"e2240f0c_efb2d641","line":5585,"in_reply_to":"a192b371_c953e2a2","updated":"2025-08-06 19:01:45.000000000","message":"I mean, technically I think we should care about a service bump. And I think (typically) we\u0027d expect to just leave the always-block behavior until the whole cluster is upgraded and not try to determine if it\u0027s okay in a finer-grained way.\n\nBut, it\u0027s also live migration and not being able to move stuff until the upgrade completes also sucks. So yeah, maybe solicit some other opinions.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fedcb6367b131786b4e8ad83340524f1591392a2","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"e5e4e71d_4be2fdc8","line":5585,"in_reply_to":"adb2926f_5e89ea39","updated":"2025-08-18 08:38:41.000000000","message":"\u003e Based on this, I\u0027m thinking maybe the best thing to do is bump the service version and then do a service version check in nova-api and if the version of the destination is older, reject the force live migration request.\n\nI agree.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5ecffd83542d8a87d54c9609d4c3ae6a5fc065c4","unresolved":true,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"8fa4dc44_ef436ed2","line":5585,"in_reply_to":"e2240f0c_efb2d641","updated":"2025-08-06 20:54:01.000000000","message":"Yeah, I was thinking about that too. There isn\u0027t much info about a service bump in the spec and I concluded that the only way it would be useful (before I thought about force) is if we wanted to block live migration for vTPM instances entirely until minimum service version is current.\n\nBut like you say, I was thinking it might be overly harsh to not allow migrations between new computes, especially since it would not be that hard to allow it.\n\nI\u0027ll ask Sylvain/gibi/Sean since they\u0027ve reviewed some of this stuff already.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4d87b6e4883c9173cafd54ef36aaa35d35911442","unresolved":false,"context_lines":[{"line_number":5582,"context_line":"    @block_shares_not_supported()"},{"line_number":5583,"context_line":"    @block_extended_resource_request"},{"line_number":5584,"context_line":"    @block_port_accelerators()"},{"line_number":5585,"context_line":"    @reject_legacy_vtpm_live_migration"},{"line_number":5586,"context_line":"    @reject_vdpa_instances("},{"line_number":5587,"context_line":"        instance_actions.LIVE_MIGRATION,"},{"line_number":5588,"context_line":"        until\u003dMIN_COMPUTE_VDPA_HOTPLUG_LIVE_MIGRATION"}],"source_content_type":"text/x-python","patch_set":21,"id":"92abf324_dd5e5ec9","line":5585,"in_reply_to":"e5e4e71d_4be2fdc8","updated":"2025-10-17 23:32:36.000000000","message":"This thread is now obsolete -- the patches have drastically changed since this thread. See the spec re-proposal for summary of the current series: https://review.opendev.org/c/openstack/nova-specs/+/961564","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"}],"nova/objects/service.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ee8c0a3b8a275fcc839365e0281dfb2840f50130","unresolved":true,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"# NOTE(danms): This is the global service version counter"},{"line_number":40,"context_line":"SERVICE_VERSION \u003d 71"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"# NOTE(danms): This is our SERVICE_VERSION history. The idea is that any"}],"source_content_type":"text/x-python","patch_set":49,"id":"87d5b269_cbedfd81","line":40,"updated":"2026-02-03 17:03:07.000000000","message":"Okay so, melwitt and I discussed on IRC and it sounds like we need to move this to the next patch. Otherwise this will create a window where the API could think that compute supports deployment mode when it doesn\u0027t. That happens if the next patch in this series is deployed to API nodes while only this patch is deployed to computes.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9f0478a4f8cdb5e1e3b84fdffe8378fbdcf4fa64","unresolved":false,"context_lines":[{"line_number":37,"context_line":""},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"# NOTE(danms): This is the global service version counter"},{"line_number":40,"context_line":"SERVICE_VERSION \u003d 71"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"# NOTE(danms): This is our SERVICE_VERSION history. The idea is that any"}],"source_content_type":"text/x-python","patch_set":49,"id":"40f4c4f3_5ac13c4e","line":40,"in_reply_to":"87d5b269_cbedfd81","updated":"2026-02-05 20:24:59.000000000","message":"I have moved the service version bump into a standalone patch placed after the \u0027deployment\u0027 live migration patch. That way if we need to move it later, it will be easy.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"}],"nova/tests/functional/libvirt/test_vtpm.py":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3109fde8c3c57f93b430e4535a58cec0339b61f9","unresolved":true,"context_lines":[{"line_number":523,"context_line":"        self._assert_libvirt_has_secret(self.src, self.server[\u0027id\u0027])"},{"line_number":524,"context_line":"        # And no libvirt secret on the destination host."},{"line_number":525,"context_line":"        self._assert_libvirt_secret_missing(self.dest, self.server[\u0027id\u0027])"},{"line_number":526,"context_line":""},{"line_number":527,"context_line":"    def test_suspend_resume_server(self):"},{"line_number":528,"context_line":"        self.start_compute()"},{"line_number":529,"context_line":""}],"source_content_type":"text/x-python","patch_set":30,"id":"92333c9c_ec2a0be0","line":526,"updated":"2025-10-17 00:13:26.000000000","message":"A failure of this func test later in the stack exposed that waiting on the migration status is racy -- the call to driver rollback on the dest is an async call while the compute manager rollback goes ahead and marks the migration status as \u0027failed\u0027. So it\u0027s possible for us to see migration \u0027failed\u0027 _before_ the secrets are cleaned up.\n\nSo this needs to wait on something else that will be for sure happening after clean up is finished.","commit_id":"05b2c28115badda934cb72b3194d725aceb65690"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4d87b6e4883c9173cafd54ef36aaa35d35911442","unresolved":false,"context_lines":[{"line_number":523,"context_line":"        self._assert_libvirt_has_secret(self.src, self.server[\u0027id\u0027])"},{"line_number":524,"context_line":"        # And no libvirt secret on the destination host."},{"line_number":525,"context_line":"        self._assert_libvirt_secret_missing(self.dest, self.server[\u0027id\u0027])"},{"line_number":526,"context_line":""},{"line_number":527,"context_line":"    def test_suspend_resume_server(self):"},{"line_number":528,"context_line":"        self.start_compute()"},{"line_number":529,"context_line":""}],"source_content_type":"text/x-python","patch_set":30,"id":"35de6b82_ced7b536","line":526,"in_reply_to":"92333c9c_ec2a0be0","updated":"2025-10-17 23:32:36.000000000","message":"Done","commit_id":"05b2c28115badda934cb72b3194d725aceb65690"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7036e03d17ec55ea9a73570975543085b7b60516","unresolved":true,"context_lines":[{"line_number":562,"context_line":""},{"line_number":563,"context_line":"        # Try to recover the instance by hard-rebooting it."},{"line_number":564,"context_line":"        self._reboot_server(self.server, hard\u003dTrue)"},{"line_number":565,"context_line":""},{"line_number":566,"context_line":"        # This time the live migration should work because the libvirt secret"},{"line_number":567,"context_line":"        # should have been re-created by the hard reboot."},{"line_number":568,"context_line":"        self._live_migrate(self.server, migration_expected_state\u003d\u0027completed\u0027,"}],"source_content_type":"text/x-python","patch_set":50,"id":"6ee77f1a_43034909","line":565,"updated":"2026-02-09 20:20:07.000000000","message":"Can we assert the secret is back here like L538? It follows of course that the reason it succeeds the second time is that the secret is now present, but I think it\u0027s good to also assert that the _actual_ thing we expect to be solved by the hard reboot is indeed solved. Just in case the migrate succeeded after the reboot because we lost all vTPM configuration or something like that.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b0bf3f04ab59c7382619b4116bdfc6ccaea6ea22","unresolved":false,"context_lines":[{"line_number":562,"context_line":""},{"line_number":563,"context_line":"        # Try to recover the instance by hard-rebooting it."},{"line_number":564,"context_line":"        self._reboot_server(self.server, hard\u003dTrue)"},{"line_number":565,"context_line":""},{"line_number":566,"context_line":"        # This time the live migration should work because the libvirt secret"},{"line_number":567,"context_line":"        # should have been re-created by the hard reboot."},{"line_number":568,"context_line":"        self._live_migrate(self.server, migration_expected_state\u003d\u0027completed\u0027,"}],"source_content_type":"text/x-python","patch_set":50,"id":"711b009d_84c9ac78","line":565,"in_reply_to":"189e6c6a_81187ae5","updated":"2026-02-10 22:23:40.000000000","message":"Done","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":true,"context_lines":[{"line_number":562,"context_line":""},{"line_number":563,"context_line":"        # Try to recover the instance by hard-rebooting it."},{"line_number":564,"context_line":"        self._reboot_server(self.server, hard\u003dTrue)"},{"line_number":565,"context_line":""},{"line_number":566,"context_line":"        # This time the live migration should work because the libvirt secret"},{"line_number":567,"context_line":"        # should have been re-created by the hard reboot."},{"line_number":568,"context_line":"        self._live_migrate(self.server, migration_expected_state\u003d\u0027completed\u0027,"}],"source_content_type":"text/x-python","patch_set":50,"id":"189e6c6a_81187ae5","line":565,"in_reply_to":"6ee77f1a_43034909","updated":"2026-02-10 11:14:40.000000000","message":"agreed, it could be a FUP.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7036e03d17ec55ea9a73570975543085b7b60516","unresolved":true,"context_lines":[{"line_number":619,"context_line":"        # We should have a libvirt secret on the source host."},{"line_number":620,"context_line":"        self._assert_libvirt_has_secret(self.src, self.server[\u0027id\u0027])"},{"line_number":621,"context_line":"        # And no libvirt secret on the destination host."},{"line_number":622,"context_line":"        self._assert_libvirt_secret_missing(self.dest, self.server[\u0027id\u0027])"},{"line_number":623,"context_line":""},{"line_number":624,"context_line":"    def test_suspend_resume_server(self):"},{"line_number":625,"context_line":"        self.start_compute()"}],"source_content_type":"text/x-python","patch_set":50,"id":"6fd5eed0_61eb61b3","line":622,"updated":"2026-02-09 20:20:07.000000000","message":"Can we also assert that the instance is where we think it is, on the source? I know it shouldn\u0027t be able to be anywhere else, but the important part of the above assertions is that \"the secret is where the instance is\".","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":true,"context_lines":[{"line_number":619,"context_line":"        # We should have a libvirt secret on the source host."},{"line_number":620,"context_line":"        self._assert_libvirt_has_secret(self.src, self.server[\u0027id\u0027])"},{"line_number":621,"context_line":"        # And no libvirt secret on the destination host."},{"line_number":622,"context_line":"        self._assert_libvirt_secret_missing(self.dest, self.server[\u0027id\u0027])"},{"line_number":623,"context_line":""},{"line_number":624,"context_line":"    def test_suspend_resume_server(self):"},{"line_number":625,"context_line":"        self.start_compute()"}],"source_content_type":"text/x-python","patch_set":50,"id":"e8ed9618_49d037ef","line":622,"in_reply_to":"6fd5eed0_61eb61b3","updated":"2026-02-10 11:14:40.000000000","message":"ditto","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b0bf3f04ab59c7382619b4116bdfc6ccaea6ea22","unresolved":false,"context_lines":[{"line_number":619,"context_line":"        # We should have a libvirt secret on the source host."},{"line_number":620,"context_line":"        self._assert_libvirt_has_secret(self.src, self.server[\u0027id\u0027])"},{"line_number":621,"context_line":"        # And no libvirt secret on the destination host."},{"line_number":622,"context_line":"        self._assert_libvirt_secret_missing(self.dest, self.server[\u0027id\u0027])"},{"line_number":623,"context_line":""},{"line_number":624,"context_line":"    def test_suspend_resume_server(self):"},{"line_number":625,"context_line":"        self.start_compute()"}],"source_content_type":"text/x-python","patch_set":50,"id":"c737ba35_490db461","line":622,"in_reply_to":"e8ed9618_49d037ef","updated":"2026-02-10 22:23:40.000000000","message":"Done","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7abef2c00b4a08fc14fb376fcecf3fea9f938fe2","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"78c10147_da256f3a","line":10603,"updated":"2025-08-06 18:03:28.000000000","message":"Do we know that the secret is always a UTF-8 string? You can\u0027t just decode (defaulting to UTF-8) any binary string.\n\nAlso, what happens if we end up somehow in a situation where the secret hasn\u0027t been de-ephemeral-ed? I assume we won\u0027t be able to find it or won\u0027t be able to get the value, but.. shouldn\u0027t we handle that here?","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5ecffd83542d8a87d54c9609d4c3ae6a5fc065c4","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"cac287bc_5f2489ab","line":10603,"in_reply_to":"19ea4404_32694f38","updated":"2025-08-06 20:54:01.000000000","message":"\u003e \u003e It would be if we put it there (see L11716)\n\u003e \n\u003e That\u0027s not the only place we provide secret data to libvirt, right? That\u0027s only where we re-insert it into the target machine, correct?\n\u003e \n\u003e AFAICT, this code is pulling binary secret data from libvirt and decoding it as a UTF-8 string. Unless the only way that secret was ever generated was from a string we UTF-8 encoded, I think we can\u0027t assume it will be decode-able as such.\n\nLegacy vTPM libvirt secrets are not retrievable because they are always deleted immediately after the guest is running.\n\nThe only way retrievable vTPM libvirt secrets will be generated is by this series. The \"raw\" secret in Barbican is a base64 encoded bytestring [1] and that is provided to libvirt as-is [2].\n\nThis code needs to decode the bytestring to something that can be sent over RPC and the object field type is a String so we need to make it a string. Are you thinking the object field type should be different maybe? Can we use bytes as an object field type? Then we wouldn\u0027t need to decode before the RPC and encode on the other side.\n\n[1] https://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee1eb1/nova/crypto.py#L212\n[2] https://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee1eb1/nova/virt/libvirt/driver.py#L8216","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"96d61b232496f9f3c0f19412119a86475f05ccf4","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"c24f6a61_30ae5707","line":10603,"in_reply_to":"2c87a935_6b8c7d8a","updated":"2025-08-06 21:52:35.000000000","message":"\u003e I\u0027m not aware that libvirt un-base64\u0027s anything. It is apparently possible to create libvirt secrets that don\u0027t contain printable characters by using the `virSecretSetValue` API [1], but we (Nova) have always used the `virSecretDefineXML` API which has to be specified via XML [2].\n\nAh, see, I thought the fact that we were calling the separate method meant we were passing it the binary itself. Is this:\n\nhttps://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee1eb1/nova/virt/libvirt/host.py#L1124\n\n...not using the \"can have binary\" method? We use `secreteDefineXML()` first, but then set the actual value in the separate call. I (had) thought that was because we were passing it the binary directly.\n\n\u003e Yes that is how I understand it, we get a random string and use it as the secret passphrase. And we send it to Barbican/Castellan using their `Passphrase` object type [3].\n\u003e \n\u003e I\u0027m not so familiar with the Barbican object types so to me the words \"key\" and \"passphrase\" seemed interchangeable but I see now that they are specific different things in Castellan [4]. I think that was my confusion.\n\nTypically a \"passphrase\" means \"printable/type-able string\" and is often used to encrypt the actual key (usually binary, often treated as a number) which is used for the block encryption. This makes it easy to let the user \"change the password\" without having to re-encrypt the entire data set (which for something like LUKS would be very expensive, hence the use of this scheme). Anyway, that\u0027s how I tend to think about it so apologies if I was taking too much license with the words :)","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4d87b6e4883c9173cafd54ef36aaa35d35911442","unresolved":false,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"5112be4f_9850b3fb","line":10603,"in_reply_to":"4f80a950_7fd8fcbe","updated":"2025-10-17 23:32:36.000000000","message":"Acknowledged","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b7ef7c8879c7b98e7ebde37d4b10398b15904c97","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"a64701f1_84b542b2","line":10603,"in_reply_to":"78c10147_da256f3a","updated":"2025-08-06 18:55:06.000000000","message":"It would be if we put it there (see L11716) but still I think I imagine your point. Maybe we should use base64 encoding instead? I know that\u0027s what libvirt uses when encoding is needed: https://libvirt.org/formatsecret.html\n\nRight, there isn\u0027t really a way to de-ephemeral a secret because legacy implementation will undefine (delete) any TPM secret after the guest is running (the guest will still work obviously). So we would not be able to find the secret. Later on in the series when we need to confirm for example legacy to \u0027host\u0027 conversion, we have to pull the secret from Barbican, read it, create a new libvirt secret with the same passphrase and with ephemeral\u003dno and update the instance with the new secret UUID which will then be used to generate the XML etc.\n\nRegardless I think it would be best to handle that unexpected case to aid in debugging if it comes up. And also it\u0027s probably possible to fail the live migration gracefully at this point and maybe it would anyway but again better to be able to log and raise something specific. I\u0027ll add that.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e2f541cbf0289b025c4ecbdc476c2a44014c4e69","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"19ea4404_32694f38","line":10603,"in_reply_to":"a64701f1_84b542b2","updated":"2025-08-06 19:01:45.000000000","message":"\u003e It would be if we put it there (see L11716)\n\nThat\u0027s not the only place we provide secret data to libvirt, right? That\u0027s only where we re-insert it into the target machine, correct?\n\nAFAICT, this code is pulling binary secret data from libvirt and decoding it as a UTF-8 string. Unless the only way that secret was ever generated was from a string we UTF-8 encoded, I think we can\u0027t assume it will be decode-able as such.\n\n\u003e but still I think I imagine your point. Maybe we should use base64 encoding instead? I know that\u0027s what libvirt uses when encoding is needed: https://libvirt.org/formatsecret.html\n\nIf they do, then yeah we probably should just base64 it. At the very least, what we\u0027re trying to do here is \"copy the secret from one libvirt to another\" ... if libvirt thinks it can be any random binary data, then we probably better assume as much.\n\n\u003e Right, there isn\u0027t really a way to de-ephemeral a secret because legacy implementation will undefine (delete) any TPM secret after the guest is running (the guest will still work obviously). So we would not be able to find the secret. Later on in the series when we need to confirm for example legacy to \u0027host\u0027 conversion, we have to pull the secret from Barbican, read it, create a new libvirt secret with the same passphrase and with ephemeral\u003dno and update the instance with the new secret UUID which will then be used to generate the XML etc.\n\u003e \n\u003e Regardless I think it would be best to handle that unexpected case to aid in debugging if it comes up. And also it\u0027s probably possible to fail the live migration gracefully at this point and maybe it would anyway but again better to be able to log and raise something specific. I\u0027ll add that.\n\nYep, aid in debugging and aid in not creating a bad failure scenario.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b151c3b2618697e83952624e994df18e716095ff","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"4f80a950_7fd8fcbe","line":10603,"in_reply_to":"c24f6a61_30ae5707","updated":"2025-08-06 23:48:31.000000000","message":"\u003e Ah, see, I thought the fact that we were calling the separate method meant we were passing it the binary itself. Is this:\n\u003e \n\u003e https://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee1eb1/nova/virt/libvirt/host.py#L1124\n\u003e \n\u003e ...not using the \"can have binary\" method? We use `secreteDefineXML()` first, but then set the actual value in the separate call. I (had) thought that was because we were passing it the binary directly.\n\nOf course I missed the second part 😩 \n\n\u003e Typically a \"passphrase\" means \"printable/type-able string\" and is often used to encrypt the actual key (usually binary, often treated as a number) which is used for the block encryption. This makes it easy to let the user \"change the password\" without having to re-encrypt the entire data set (which for something like LUKS would be very expensive, hence the use of this scheme). Anyway, that\u0027s how I tend to think about it so apologies if I was taking too much license with the words :)\n\nLearn something new every day.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6ba11ad397106f52dc7e314eaa89b05f6e8eb4b0","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"cf5fe36e_bdf5edda","line":10603,"in_reply_to":"cac287bc_5f2489ab","updated":"2025-08-06 21:04:45.000000000","message":"\u003e Legacy vTPM libvirt secrets are not retrievable because they are always deleted immediately after the guest is running.\n\n..from libvirt, but they are from barbican, right?\n\n\u003e The only way retrievable vTPM libvirt secrets will be generated is by this series. The \"raw\" secret in Barbican is a base64 encoded bytestring [1] and that is provided to libvirt as-is [2].\n\nSure, but secrets generated yesterday, stored in barbican would come through this code once they\u0027ve been converted to host-managed. Further, unless this series changes how the secret is generated, you should not assume you can en/de-code it with UTF-8.\n\n\u003e This code needs to decode the bytestring to something that can be sent over RPC and the object field type is a String so we need to make it a string.\n\nRight. This:\n\nhttps://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee1eb1/nova/crypto.py#L212\n\nWill generate binary that you can\u0027t `decode()` into a python string, transport over the wire and then `encode()` to get the same thing. \n\n```\nos.urandom(1024).decode()\nTraceback (most recent call last):\n  File \"\u003cstdin\u003e\", line 1, in \u003cmodule\u003e\nUnicodeDecodeError: \u0027utf-8\u0027 codec can\u0027t decode bytes in position 1-2: invalid continuation byte\n```\n\nIs it possible that we\u0027re only ever dealing with the base64 string itself, and we just need to convert to and from basically an ASCII-compliant string/bytestring? If that\u0027s the case (and always the case) then just what is here is fine, I just assumed we were transporting the *actual* key here.\n\n\u003e Are you thinking the object field type should be different maybe? Can we use bytes as an object field type? Then we wouldn\u0027t need to decode before the RPC and encode on the other side.\n\nNope, you need to use a string for the object. The way to transport arbitrary binary in a string is with something like base64. We should probably have a field type that requires/enforces base64 (that might\u0027ve been added, we should look), but that validation aside, needs to be base64 one way or the other if it\u0027s just unstructured binary.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1b18f05e7e223bcada3a8da02822e7a710b05022","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"eaf85523_2b7a7bfa","line":10603,"in_reply_to":"cf5fe36e_bdf5edda","updated":"2025-08-06 21:15:21.000000000","message":"\u003e Is it possible that we\u0027re only ever dealing with the base64 string itself, and we just need to convert to and from basically an ASCII-compliant string/bytestring? If that\u0027s the case (and always the case) then just what is here is fine, I just assumed we were transporting the *actual* key here.\n\nAh, I see `ensure_secret` does return the base64\u0027d thing, which we pass directly to libvirt and I guess is what we\u0027re transporting here. Sorry I read this as libvirt gets the raw secret, but I think you meant it gets the base64 string:\n\n\u003e and that is provided to libvirt as-is [2].\n\nDoes libvirt un-base64 it? Or does it just treat the base64\u0027d version as if it\u0027s a passphrase (which means to me, a string)?\n\nSo we never un-base64 it anywhere, and we\u0027re just using the combination of `os.random()` plus `base64.encode()` to basically get \"a random string\" but we never convert that back to the original binary anywhere. Is that right? If so, a regular string field and treating it the way it is here is fine.\n\nSorry for the long walk, I just assumed we were providing the *actual* key to libvirt. Perhaps because of the conversation we had with cinder at the last PTG around what LUKS is looking for (a passphrase or a key).","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ebdc5ac59e314ab9314daedfb080a7c51805da54","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"18d219b8_e0caa90a","line":10603,"in_reply_to":"cf5fe36e_bdf5edda","updated":"2025-08-06 21:14:31.000000000","message":"Yes the legacy secrets are in Barbican and they are base64 bytestrings, same as what we provide to libvirt. The binary isn\u0027t passed to libvirt (even for legacy), it is instead `base64.b64encode(os.urandom(_VTPM_SECRET_BYTE_LENGTH))` in the existing code. This is the actual key.\n\nIt\u0027s always base64 encoded Python bytes type and we need to convert that to a regular string for the object, then convert it back on the other side of the RPC.","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"40a4ae10f7abbd7750eb0b47a8229f34d32be802","unresolved":true,"context_lines":[{"line_number":10600,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10601,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10602,"context_line":"            # SensitiveStringField type."},{"line_number":10603,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10604,"context_line":""},{"line_number":10605,"context_line":"        return dest_check_data"},{"line_number":10606,"context_line":""}],"source_content_type":"text/x-python","patch_set":21,"id":"2c87a935_6b8c7d8a","line":10603,"in_reply_to":"eaf85523_2b7a7bfa","updated":"2025-08-06 21:43:38.000000000","message":"Yes that is what I meant, that we (Nova) generate the base64 encoded thing and then hand it to libvirt as the base64 encoded thing (we don\u0027t do anything to change it).\n\nI\u0027m not aware that libvirt un-base64\u0027s anything. It is apparently possible to create libvirt secrets that don\u0027t contain printable characters by using the `virSecretSetValue` API [1], but we (Nova) have always used the `virSecretDefineXML` API which has to be specified via XML [2].\n\nYes that is how I understand it, we get a random string and use it as the secret passphrase. And we send it to Barbican/Castellan using their `Passphrase` object type [3].\n\nI\u0027m not so familiar with the Barbican object types so to me the words \"key\" and \"passphrase\" seemed interchangeable but I see now that they are specific different things in Castellan [4]. I think that was my confusion.\n\n[1] https://libvirt.org/formatsecret.html#usage-type-vtpm\n[2] https://libvirt.org/html/libvirt-libvirt-secret.html#virSecretDefineXML\n[3] https://github.com/openstack/castellan/blob/609f4ea667df386849930cf61d875b5c9e16abbb/castellan/common/objects/passphrase.py\n[4] https://github.com/openstack/castellan/tree/609f4ea667df386849930cf61d875b5c9e16abbb/castellan/common/objects","commit_id":"9b242a1495d0a9d4d83ac3d505a81713c1f4a583"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"02bb671cc3426d7390e2397d7607683bb876e64d","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":49,"id":"42e25da0_7ac1ff5a","line":10886,"updated":"2026-02-06 19:20:31.000000000","message":"Will this always be unicode-decodeable? I feel like maybe I\u0027ve asked this before...but why not use a hex string here? If we find out later (or something changes in how we generate them) that secrets are non-unicode binary, we\u0027ll be in a bit of trouble.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4ffd686548f346446a254a009b03387a1fdf99a0","unresolved":false,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":49,"id":"4c4c8aac_47a8ddcc","line":10886,"in_reply_to":"1c5c22e5_b8a2f546","updated":"2026-02-10 19:46:53.000000000","message":"For posterity, my statement here is wrong. SensitiveString is 100% right here since this is a _passphrase_ generated by us always in text format. The only time it\u0027s a `bytes` is when we\u0027re passing it over the C barrier to libvirt, but it\u0027s never binary data.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5eb77f14f2251ba48ab80e6ba0403f2626a1c94c","unresolved":false,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":49,"id":"c3e2056b_bf23b3dc","line":10886,"in_reply_to":"42e25da0_7ac1ff5a","updated":"2026-02-06 19:22:46.000000000","message":"Oh yeah, from PS21, and this has to always be text in our current use of how we define the secret. I guess I still have the concern that things could change in the future which will have RPC/object implications, but I guess we\u0027ll ignore that at this point.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8975ec71ab83256e037fe46b9d116d39d6911dcc","unresolved":false,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":49,"id":"1c5c22e5_b8a2f546","line":10886,"in_reply_to":"b31003ee_2ff1ec6b","updated":"2026-02-06 20:44:58.000000000","message":"If we had one then it would for sure. Unless someone has added a bytesfield already I don\u0027t think there\u0027s a better option right now and I don\u0027t want to hold this up for that. I should have worked on one between PS21 and now I guess, but it would introduce an o.vo bump dep.","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f61b7a7820563666a759698da7fdb247ca1baa2a","unresolved":false,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":49,"id":"b31003ee_2ff1ec6b","line":10886,"in_reply_to":"c3e2056b_bf23b3dc","updated":"2026-02-06 20:27:01.000000000","message":"Do you think it might help to use a different field type in the object for the secret value?","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":50,"id":"27d057df_3e02d833","line":10886,"updated":"2026-02-10 11:14:40.000000000","message":"the libvirt-python interface is super fragile and here we\u0027re blindly getting values from what it returns. Hard to figure out the exact details of the returned libvirt object since the C-binding shows it returns a pointer so I\u0027m afraid this could break in a subsequent libvirt upgrade.\n\nI\u0027d honestly like to have some kind of input validation here, but this can be done in a FUP.\n\nNote : I reviewed https://libvirt.org/html/libvirt-libvirt-secret.html#virSecretLookupByUUID and https://gitlab.com/libvirt/libvirt-python/-/blob/master/libvirt-override.c#L4263","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"7326d950d811ac25ff90e58530956cc0915c8bbf","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":50,"id":"8c675ba0_91b11d01","line":10886,"in_reply_to":"25d43389_7f9d2575","updated":"2026-02-10 17:45:56.000000000","message":"I was thinking we should return a better exception than something that could be  UnicodeDecodeError (maybe `VTPMSecretNotFound` or other specific VTPM exception) but let\u0027s not discuss it here for now.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"090b20109c5cc803d3639f3306f56e8d2b649417","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":50,"id":"5db27c70_3c920b26","line":10886,"in_reply_to":"2725afa0_daf9e093","updated":"2026-02-10 22:24:47.000000000","message":"s/setting/letting/","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f7f3561ed23a4e440d5d6632c9090aa902589629","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":50,"id":"25d43389_7f9d2575","line":10886,"in_reply_to":"27d057df_3e02d833","updated":"2026-02-10 14:40:13.000000000","message":"You\u0027ll note I\u0027ve also been concerned about this being so opaque. You might review some of the previous patchset comments on this file for reference, but it sounds like there\u0027s not much we can assert about this and that it\u0027s already base64\u0027d binary data in the usual case. We could assert that it\u0027s base64, but I don\u0027t think that we can always rely on that, as any other encoding could be used (and IIRC cinder uses hex for this).\n\nWhat are you thinking specifically?","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b0bf3f04ab59c7382619b4116bdfc6ccaea6ea22","unresolved":true,"context_lines":[{"line_number":10883,"context_line":"            dest_check_data.vtpm_secret_uuid \u003d secret.UUIDString()"},{"line_number":10884,"context_line":"            # Have to decode the bytes type to conform to the object\u0027s"},{"line_number":10885,"context_line":"            # SensitiveStringField type."},{"line_number":10886,"context_line":"            dest_check_data.vtpm_secret_value \u003d secret.value().decode()"},{"line_number":10887,"context_line":"        else:"},{"line_number":10888,"context_line":"            # If the instance has a vTPM, set the relevant fields to None in"},{"line_number":10889,"context_line":"            # order to convey that we are actively choosing not to pass any"}],"source_content_type":"text/x-python","patch_set":50,"id":"2725afa0_daf9e093","line":10886,"in_reply_to":"8c675ba0_91b11d01","updated":"2026-02-10 22:23:40.000000000","message":"As we discussed on IRC earlier today, raising VTPMSecretNotFound for a UnicodeDecodeError would be misleading because in this case the secret _was_ found and it exists.\n\nThe problem is rather with the attempt to decode the found value failing, and TBH I\u0027m not sure there\u0027s a better error than \"UnicodeDecodeError\" for indicating this. Further, IMHO it would also be a lot more helpful to have a stack trace available if that happens, to aid in debugging.\n\nI\u0027m not opposed to the idea of doing some type of different error handling here but so far I don\u0027t have a better idea than just setting it be UnicodeDecodeError with a stack trace that points to where in the code it happened.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"}],"nova/virt/libvirt/host.py":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":true,"context_lines":[{"line_number":1066,"context_line":"    def find_secret(self, usage_type, usage_id):"},{"line_number":1067,"context_line":"        \"\"\"Find a secret."},{"line_number":1068,"context_line":""},{"line_number":1069,"context_line":"        usage_type: one of \u0027iscsi\u0027, \u0027ceph\u0027, \u0027rbd\u0027 or \u0027volume\u0027"},{"line_number":1070,"context_line":"        usage_id: name of resource in secret"},{"line_number":1071,"context_line":"        \"\"\""},{"line_number":1072,"context_line":"        if usage_type \u003d\u003d \u0027iscsi\u0027:"}],"source_content_type":"text/x-python","patch_set":50,"id":"8f3ab379_b1c2fbac","line":1069,"updated":"2026-02-10 11:14:40.000000000","message":"hmmm, the docstring misses the vtpm value for usage_type, we forgot to add it in https://review.opendev.org/c/openstack/nova/+/941795","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b0bf3f04ab59c7382619b4116bdfc6ccaea6ea22","unresolved":false,"context_lines":[{"line_number":1066,"context_line":"    def find_secret(self, usage_type, usage_id):"},{"line_number":1067,"context_line":"        \"\"\"Find a secret."},{"line_number":1068,"context_line":""},{"line_number":1069,"context_line":"        usage_type: one of \u0027iscsi\u0027, \u0027ceph\u0027, \u0027rbd\u0027 or \u0027volume\u0027"},{"line_number":1070,"context_line":"        usage_id: name of resource in secret"},{"line_number":1071,"context_line":"        \"\"\""},{"line_number":1072,"context_line":"        if usage_type \u003d\u003d \u0027iscsi\u0027:"}],"source_content_type":"text/x-python","patch_set":50,"id":"0e5f416f_e682e1f4","line":1069,"in_reply_to":"8f3ab379_b1c2fbac","updated":"2026-02-10 22:23:40.000000000","message":"Done","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5c80bd68b1f55f25c61420614387e02ebbf6dfb8","unresolved":true,"context_lines":[{"line_number":1083,"context_line":""},{"line_number":1084,"context_line":"        try:"},{"line_number":1085,"context_line":"            conn \u003d self.get_connection()"},{"line_number":1086,"context_line":"            return conn.secretLookupByUsage(usage_type_const, usage_id)"},{"line_number":1087,"context_line":"        except libvirt.libvirtError as e:"},{"line_number":1088,"context_line":"            if e.get_error_code() \u003d\u003d libvirt.VIR_ERR_NO_SECRET:"},{"line_number":1089,"context_line":"                return None"}],"source_content_type":"text/x-python","patch_set":50,"id":"a0e1d1a5_fe18400d","line":1086,"updated":"2026-02-10 11:14:40.000000000","message":"hmmm, we\u0027re blindly returning the value here, hard to tell exactly what the libvirt python binding returns for vtpm type and in https://review.opendev.org/c/openstack/nova/+/941795/28/nova/virt/libvirt/driver.py we didn\u0027t had a specfic unittest for it.","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"7326d950d811ac25ff90e58530956cc0915c8bbf","unresolved":true,"context_lines":[{"line_number":1083,"context_line":""},{"line_number":1084,"context_line":"        try:"},{"line_number":1085,"context_line":"            conn \u003d self.get_connection()"},{"line_number":1086,"context_line":"            return conn.secretLookupByUsage(usage_type_const, usage_id)"},{"line_number":1087,"context_line":"        except libvirt.libvirtError as e:"},{"line_number":1088,"context_line":"            if e.get_error_code() \u003d\u003d libvirt.VIR_ERR_NO_SECRET:"},{"line_number":1089,"context_line":"                return None"}],"source_content_type":"text/x-python","patch_set":50,"id":"09388a75_5ef139e1","line":1086,"in_reply_to":"45aa337d_d9b9c996","updated":"2026-02-10 17:45:56.000000000","message":"not here I think, rather in the caller method","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f7f3561ed23a4e440d5d6632c9090aa902589629","unresolved":true,"context_lines":[{"line_number":1083,"context_line":""},{"line_number":1084,"context_line":"        try:"},{"line_number":1085,"context_line":"            conn \u003d self.get_connection()"},{"line_number":1086,"context_line":"            return conn.secretLookupByUsage(usage_type_const, usage_id)"},{"line_number":1087,"context_line":"        except libvirt.libvirtError as e:"},{"line_number":1088,"context_line":"            if e.get_error_code() \u003d\u003d libvirt.VIR_ERR_NO_SECRET:"},{"line_number":1089,"context_line":"                return None"}],"source_content_type":"text/x-python","patch_set":50,"id":"45aa337d_d9b9c996","line":1086,"in_reply_to":"a0e1d1a5_fe18400d","updated":"2026-02-10 14:40:13.000000000","message":"Are you looking for something more specific than \"a `bytes`\"?","commit_id":"3eae9477d26b490bfdb40e52129b30a793729cbb"}],"releasenotes/notes/vtpm-live-migration-4ef9ab54cd6e3a0b.yaml":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"02bb671cc3426d7390e2397d7607683bb876e64d","unresolved":true,"context_lines":[{"line_number":3,"context_line":"    The libvirt driver now supports live migration of servers with virtual"},{"line_number":4,"context_line":"    emulated TPM (vTPM) when the ``hw:tpm_secret_security`` flavor extra"},{"line_number":5,"context_line":"    spec is set to ``host``. Operators must create flavors"},{"line_number":6,"context_line":"    which set ``hw:tpm_secret_security`` in order to enable servers to select"},{"line_number":7,"context_line":"    TPM secret security mode. Pre-existing servers can opt-in to the ``host``"},{"line_number":8,"context_line":"    TPM secret security mode by resizing to a flavor which has set"},{"line_number":9,"context_line":"    ``hw:tpm_secret_security`` to ``host``."},{"line_number":10,"context_line":"    Operators may choose which TPM security modes they want to support by"}],"source_content_type":"text/x-yaml","patch_set":49,"id":"373b63c9_4b0596a9","line":7,"range":{"start_line":6,"start_character":14,"end_line":7,"end_character":28},"updated":"2026-02-06 19:20:31.000000000","message":"I think something is missing here. Perhaps s/select.*$/select a particular mode/? Otherwise it seems like you\u0027re saying \"must create flavors which set X to enable servers to select X\".","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9626254c58e900fa87e2f30176ecd8527bcf6e64","unresolved":false,"context_lines":[{"line_number":3,"context_line":"    The libvirt driver now supports live migration of servers with virtual"},{"line_number":4,"context_line":"    emulated TPM (vTPM) when the ``hw:tpm_secret_security`` flavor extra"},{"line_number":5,"context_line":"    spec is set to ``host``. Operators must create flavors"},{"line_number":6,"context_line":"    which set ``hw:tpm_secret_security`` in order to enable servers to select"},{"line_number":7,"context_line":"    TPM secret security mode. Pre-existing servers can opt-in to the ``host``"},{"line_number":8,"context_line":"    TPM secret security mode by resizing to a flavor which has set"},{"line_number":9,"context_line":"    ``hw:tpm_secret_security`` to ``host``."},{"line_number":10,"context_line":"    Operators may choose which TPM security modes they want to support by"}],"source_content_type":"text/x-yaml","patch_set":49,"id":"7066d5fd_6a962a7a","line":7,"range":{"start_line":6,"start_character":14,"end_line":7,"end_character":28},"in_reply_to":"373b63c9_4b0596a9","updated":"2026-02-11 02:13:14.000000000","message":"Done","commit_id":"490bacf5127a0379642095a13910d9cb0aea8cf1"}]}