)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06498fb14646d4c3f139dcac6a8e8218591ad744","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"53a38caa_06e0af8c","line":10,"updated":"2025-12-01 18:34:47.000000000","message":"Is the secret ID not also used in \u0027deployment\u0027?","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"374330ec60922beccee6eb6ecc037b26572dd79b","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"dd932149_2e36949a","line":10,"in_reply_to":"0a1fe50e_f700b7b2","updated":"2025-12-01 21:09:33.000000000","message":"It is both, when we create the secret in libvirt we use the same ID as it has in Barbican. Libvirt secrets have a \"uuid\" and a \"usage\". The \"usage\" does not have the be a valid UUID.\n\nSo when we create a libvirt secret for vTPM it has type\u003d\u0027vtpm\u0027, usage\u003d\u003cinstance uuid\u003e, uuid\u003d\u003cbarbican secret ID\u003e, password\u003d\u003cbarbican passphrase\u003e.","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"dc4426341b89f4a30d782f0399acbdf3e303e883","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"9cba377d_f5546324","line":10,"in_reply_to":"53a38caa_06e0af8c","updated":"2025-12-01 19:08:25.000000000","message":"No, it is not. The secret ID is (unrelated to this series) embedded in the instance system metadata, so it can be used from there anywhere the instance object is available (which is pretty much everywhere). Technically the \u0027host\u0027 mode only needs the secret value in order to create the libvirt secret on the destination, but would it be weird to only pass the value and not the ID alongside?","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4abf19d0faaecca4312a338ed2100b4e6091c28b","unresolved":false,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"1dfee3e0_94aed87e","line":10,"in_reply_to":"79f20dd5_2f30316a","updated":"2025-12-02 16:36:22.000000000","message":"OK I see you meant if the vtpm_secret_uuid field in LibvirtLiveMigrateData directly represents the secret uuid in Libvirt, yes that is correct.","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f20cdf897e3d65e956c393cd9acf77d9faa154a9","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"0a1fe50e_f700b7b2","line":10,"in_reply_to":"9cba377d_f5546324","updated":"2025-12-01 20:57:46.000000000","message":"Ah, I guess I keep thinking of this as the ID in barbican but it\u0027s more like the secret uuid in libvirt right?","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"27131fc8ec6f4347bb59bd9efe4fe0d84ad7648d","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is needed in order to pass TPM secret information to the"},{"line_number":10,"context_line":"destination over RPC to support the \u0027host\u0027 secret security mode."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"The fields are nullable so that secret security modes \u0027user\u0027 and"},{"line_number":13,"context_line":"\u0027deployment\u0027 may set them to None."}],"source_content_type":"text/x-gerrit-commit-message","patch_set":29,"id":"79f20dd5_2f30316a","line":10,"in_reply_to":"dd932149_2e36949a","updated":"2025-12-02 14:56:27.000000000","message":"Well, I know they\u0027re the actual same string :)","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"71b452283c0beda3639ed847f7bfa74d40185d08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b3086daa_da894b29","updated":"2025-06-16 06:17:09.000000000","message":"minor nits, otherwise LGTM.","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"9487f635ae88a63cc85a1649756b7508db431fe7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"2446db0e_c669c309","updated":"2025-06-17 04:43:12.000000000","message":"LGTM now.","commit_id":"744cc42da5263f9ab2680dbb099d13580e22773c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"04ee5b2ac402d3885279a17072e6cec8b976a577","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"8821d46d_6c011f47","updated":"2025-08-21 14:54:04.000000000","message":"Adding gibi and bauzas as reviewers here to make sure we get some eyes and opinions on this version bump thing.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"311a7e5cd2901ca2040d32a5da01707d2fc98083","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"a2149a2f_87725fa9","updated":"2025-08-11 13:46:13.000000000","message":"Yeah, no hash change in the libvirt object going back to non-inheritance means we could move this to the parent with no bump if we needed to. So I think that was the right call, thanks for changing.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f0bf13845931807c306b40e90bc65b24fa318318","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"7a95ad12_5b2b6a45","updated":"2025-09-24 00:35:47.000000000","message":"recheck nova-tox-py312-threading\n```\n  File \"/home/zuul/src/opendev.org/openstack/nova/nova/compute/api.py\", line 6264, in _service_get_all_cells\n    cell0_computes \u003d [\n                     ^\nTypeError: \u0027OperationalError\u0027 object is not iterable\n```","commit_id":"e5ca63b85cae3260455c39dcf6dd48420ef3cd92"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9396205335386fd876a2e9b4271e48b568c994b2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":19,"id":"ef35cd42_4ad567c6","updated":"2025-10-21 02:58:35.000000000","message":"recheck libvirt issues [instance: 8326c764-3cae-4788-a5a8-85ad16cb93ff] Cannot destroy instance, general system call failure: libvirt.libvirtError: Cannot recv data: Connection reset by peer","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3af3c33a3c357e116fbbbffa5ad52b5a2984d1b3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":20,"id":"aef82589_ffb3b6d0","updated":"2025-10-24 02:28:04.000000000","message":"recheck Failure synchronizing repos \"error\": \"Command \u0027[\u0027git\u0027, \u0027push\u0027, \u0027--quiet\u0027, \u0027--mirror\u0027, \u0027git+ssh://zuul@66.70.103.104:22//home/zuul/src/opendev.org/openstack/nova\u0027]\u0027 returned non-zero exit status 1. : b\\\"remote: error: inflate: data stream error (unknown compression method)","commit_id":"32d6b893f07207917693f442599a0125b556136b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a1915c58ec8fbbf7d59fd54b9499063ab168c437","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":23,"id":"ed39f691_65ae06b9","updated":"2025-11-10 23:23:43.000000000","message":"recheck guest kernel panic","commit_id":"73124b1a9b80bed3df3fc0430d6f1a51eb3df9b1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a49ebbc29a795a08f48b6dd42b2c0aebc8253f62","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":29,"id":"321e4a2e_9f3d38b0","updated":"2025-11-24 19:45:37.000000000","message":"recheck Volume 501cc4f4-0393-4e92-9e9d-467f56c0433e: create failed\n\nException during message handling: cinder.exception.ImageCopyFailure: Failed to copy image to volume: qemu-img: /opt/stack/data/cinder/conversion/tmpencz0alz.luks: error while converting luks: Unable to get accurate CPU usage","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"aa2f5fe96a682fbdb0da4846631b21028b1ee425","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":32,"id":"b6e87908_20922291","updated":"2026-01-26 15:53:23.000000000","message":"first glance looks good but I need to reinject the whole context into my brain before I can accept this patch.\nLet\u0027s start to review again this series !","commit_id":"dd4ea2fe658070907db190f6a72af9e671dbaef8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"505b3341ed64b683b438602ee892c42c5a6a9e4d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":33,"id":"2a7eea88_6dee0f7d","updated":"2026-02-10 19:10:20.000000000","message":"Okay I think I\u0027m good here. Sylvain, if you\u0027re okay with this based on the above, can you +W?","commit_id":"8b3701490eeab18b6e05b06151a1e13f2f811899"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cd02361f1832c4d97f480502abbcb2ef0d21435e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":33,"id":"d3f67f31_b9603a68","updated":"2026-02-10 15:10:25.000000000","message":"Since this isn\u0027t used past the host mechanism and I\u0027m +2 there, I\u0027m good with this now. However, it might have implications on bauzas\u0027 concerns about the secret format/type so I\u0027ll just +1 for the moment.","commit_id":"8b3701490eeab18b6e05b06151a1e13f2f811899"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"284d3c5e03a2729d34b388638685169af8e6ad3d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":33,"id":"b92db391_60a5edff","updated":"2026-02-16 16:06:31.000000000","message":"eventually done with the host support","commit_id":"8b3701490eeab18b6e05b06151a1e13f2f811899"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f506b6a57005cc29ec41909b45aef7857791df89","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":33,"id":"6bb44c41_83adcce1","updated":"2026-01-29 01:38:00.000000000","message":"recheck ERROR cinder.volume.volume_utils Stderr: \u0027qemu-img: /opt/stack/data/cinder/conversion/tmpen5v4o0t.luks: error while converting luks: Unable to get accurate CPU usage\\n\u0027","commit_id":"8b3701490eeab18b6e05b06151a1e13f2f811899"}],"nova/objects/migrate_data.py":[{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"71b452283c0beda3639ed847f7bfa74d40185d08","unresolved":true,"context_lines":[{"line_number":295,"context_line":"        super(LibvirtLiveMigrateData, self).obj_make_compatible("},{"line_number":296,"context_line":"            primitive, target_version)"},{"line_number":297,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":298,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":299,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 12)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027dst_cpu_shared_set_info\u0027, None)"},{"line_number":302,"context_line":"        if target_version \u003c (1, 11):"}],"source_content_type":"text/x-python","patch_set":1,"id":"9b094644_1d0748eb","line":299,"range":{"start_line":298,"start_character":0,"end_line":299,"end_character":54},"updated":"2025-06-16 06:17:09.000000000","message":"this check is missing for newly added version 1.14","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ddd2ea3b1f2d646c44c8780830489a87ddcb0159","unresolved":false,"context_lines":[{"line_number":295,"context_line":"        super(LibvirtLiveMigrateData, self).obj_make_compatible("},{"line_number":296,"context_line":"            primitive, target_version)"},{"line_number":297,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":298,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":299,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 12)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027dst_cpu_shared_set_info\u0027, None)"},{"line_number":302,"context_line":"        if target_version \u003c (1, 11):"}],"source_content_type":"text/x-python","patch_set":1,"id":"16b9f14e_93847100","line":299,"range":{"start_line":298,"start_character":0,"end_line":299,"end_character":54},"in_reply_to":"8fbcae72_ef0e3d83","updated":"2025-06-16 21:33:06.000000000","message":"Done","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fbea5baa0678e0b40a1ecb1eb6eb59a6458420c2","unresolved":true,"context_lines":[{"line_number":295,"context_line":"        super(LibvirtLiveMigrateData, self).obj_make_compatible("},{"line_number":296,"context_line":"            primitive, target_version)"},{"line_number":297,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":298,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":299,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 12)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027dst_cpu_shared_set_info\u0027, None)"},{"line_number":302,"context_line":"        if target_version \u003c (1, 11):"}],"source_content_type":"text/x-python","patch_set":1,"id":"8fbcae72_ef0e3d83","line":299,"range":{"start_line":298,"start_character":0,"end_line":299,"end_character":54},"in_reply_to":"9b094644_1d0748eb","updated":"2025-06-16 20:27:10.000000000","message":"Good catch, thanks. Looks like I completely forgot how to do versioned objects 😓 Will fix.","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"71b452283c0beda3639ed847f7bfa74d40185d08","unresolved":true,"context_lines":[{"line_number":360,"context_line":"        super(HyperVLiveMigrateData, self).obj_make_compatible("},{"line_number":361,"context_line":"            primitive, target_version)"},{"line_number":362,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":363,"context_line":"        if (target_version \u003c (1, 5)):"},{"line_number":364,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":365,"context_line":"        if target_version \u003c (1, 4) and \u0027vifs\u0027 in primitive:"},{"line_number":366,"context_line":"            del primitive[\u0027vifs\u0027]"},{"line_number":367,"context_line":"        if target_version \u003c (1, 3) and \u0027wait_for_vif_plugged\u0027 in primitive:"}],"source_content_type":"text/x-python","patch_set":1,"id":"52a463a6_7046d4e4","line":364,"range":{"start_line":363,"start_character":0,"end_line":364,"end_character":54},"updated":"2025-06-16 06:17:09.000000000","message":"same as above, for version 1.6","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ddd2ea3b1f2d646c44c8780830489a87ddcb0159","unresolved":false,"context_lines":[{"line_number":360,"context_line":"        super(HyperVLiveMigrateData, self).obj_make_compatible("},{"line_number":361,"context_line":"            primitive, target_version)"},{"line_number":362,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":363,"context_line":"        if (target_version \u003c (1, 5)):"},{"line_number":364,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":365,"context_line":"        if target_version \u003c (1, 4) and \u0027vifs\u0027 in primitive:"},{"line_number":366,"context_line":"            del primitive[\u0027vifs\u0027]"},{"line_number":367,"context_line":"        if target_version \u003c (1, 3) and \u0027wait_for_vif_plugged\u0027 in primitive:"}],"source_content_type":"text/x-python","patch_set":1,"id":"a5ed1b5a_0df07b3a","line":364,"range":{"start_line":363,"start_character":0,"end_line":364,"end_character":54},"in_reply_to":"52a463a6_7046d4e4","updated":"2025-06-16 21:33:06.000000000","message":"Done","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":20733,"name":"Rajesh Tailor","email":"ratailor@redhat.com","username":"rajesht"},"change_message_id":"71b452283c0beda3639ed847f7bfa74d40185d08","unresolved":true,"context_lines":[{"line_number":390,"context_line":"        super(VMwareLiveMigrateData, self).obj_make_compatible("},{"line_number":391,"context_line":"            primitive, target_version)"},{"line_number":392,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":393,"context_line":"        if (target_version \u003c (1, 1)):"},{"line_number":394,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"}],"source_content_type":"text/x-python","patch_set":1,"id":"738f3f6d_a9c0f978","line":394,"range":{"start_line":393,"start_character":0,"end_line":394,"end_character":54},"updated":"2025-06-16 06:17:09.000000000","message":"same as above, for version 1.2","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ddd2ea3b1f2d646c44c8780830489a87ddcb0159","unresolved":false,"context_lines":[{"line_number":390,"context_line":"        super(VMwareLiveMigrateData, self).obj_make_compatible("},{"line_number":391,"context_line":"            primitive, target_version)"},{"line_number":392,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":393,"context_line":"        if (target_version \u003c (1, 1)):"},{"line_number":394,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"}],"source_content_type":"text/x-python","patch_set":1,"id":"bd55fc47_517daa03","line":394,"range":{"start_line":393,"start_character":0,"end_line":394,"end_character":54},"in_reply_to":"738f3f6d_a9c0f978","updated":"2025-06-16 21:33:06.000000000","message":"Done","commit_id":"4f2880d384a558d0c8d717282d39c98fae9baea7"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6535f0bd81e7704788676e978410b88de2da6a56","unresolved":true,"context_lines":[{"line_number":174,"context_line":"        \u0027vifs\u0027: fields.ListOfObjectsField(\u0027VIFMigrateData\u0027),"},{"line_number":175,"context_line":"        \u0027pci_dev_map_src_dst\u0027: fields.DictOfStringsField(),"},{"line_number":176,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":177,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":178,"context_line":"    }"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"c3ca7b27_fcaf51eb","line":177,"updated":"2025-08-06 17:55:06.000000000","message":"I\u0027m not sure how i feel about putting this into the base object. On the one hand, it can/should/might be generic enough to be used by all the drivers. However, I suspect vmware is so integrated that it wouldn\u0027t even use this. And it makes us tweak the dead hyperv object, which also kinda makes no sense.\n\nI\u0027m sure this is from the original set, but...thoughts?","commit_id":"29b034c89d0f7d2b05db6e8a589254b241529726"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8cbd8744c922b73d98741b3bd8ab17fe9e7395ed","unresolved":false,"context_lines":[{"line_number":174,"context_line":"        \u0027vifs\u0027: fields.ListOfObjectsField(\u0027VIFMigrateData\u0027),"},{"line_number":175,"context_line":"        \u0027pci_dev_map_src_dst\u0027: fields.DictOfStringsField(),"},{"line_number":176,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":177,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":178,"context_line":"    }"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"0821a10f_7e8f6acc","line":177,"in_reply_to":"1e279758_a30e8aa1","updated":"2025-08-09 01:27:09.000000000","message":"Done","commit_id":"29b034c89d0f7d2b05db6e8a589254b241529726"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9385b656f69a960fc08b395ed67259a39735dbcc","unresolved":true,"context_lines":[{"line_number":174,"context_line":"        \u0027vifs\u0027: fields.ListOfObjectsField(\u0027VIFMigrateData\u0027),"},{"line_number":175,"context_line":"        \u0027pci_dev_map_src_dst\u0027: fields.DictOfStringsField(),"},{"line_number":176,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":177,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":178,"context_line":"    }"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"e37127b0_0022149c","line":177,"in_reply_to":"c3ca7b27_fcaf51eb","updated":"2025-08-06 18:36:02.000000000","message":"Yes it is but yeah, if vTPM only makes sense for libvirt, then it should go there.\n\nI wonder how does it work if something is originally thought to only be applicable for libvirt but later another driver wants to add it? Potentially duplicate the fields I guess? Maybe not the worst thing especially given the probably remote chance.\n\nI also notice NUMA live migration stuff is in LibvirtLiveMigrateData only. Maybe that one is more obvious that only libvirt has NUMA particulars. Mdevs are also only in there.\n\nI don\u0027t have a strong opinion about it, I would be OK with moving it to LibvirtLiveMigrateData. I agree that having to update HyperV here feels random.","commit_id":"29b034c89d0f7d2b05db6e8a589254b241529726"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"556f54579cb6694fcbd3011ccaf639f22afe00a6","unresolved":true,"context_lines":[{"line_number":174,"context_line":"        \u0027vifs\u0027: fields.ListOfObjectsField(\u0027VIFMigrateData\u0027),"},{"line_number":175,"context_line":"        \u0027pci_dev_map_src_dst\u0027: fields.DictOfStringsField(),"},{"line_number":176,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":177,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":178,"context_line":"    }"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":""}],"source_content_type":"text/x-python","patch_set":9,"id":"1e279758_a30e8aa1","line":177,"in_reply_to":"e37127b0_0022149c","updated":"2025-08-06 18:55:16.000000000","message":"Right, we add stuff that could potentially be universal to libvirt all the time because, let\u0027s be honest...unlikely to be implemented.\n\nSo, I\u0027m pretty sure that if we add it to libvirt and then later move it to the base object, the result will be exactly the same (as far as the fingerprint is concerned) for the libvirt object such that it would be a totally compatible move. Thus, I think I\u0027d lean towards worrying about the particulars if that unlikely thing happens.","commit_id":"29b034c89d0f7d2b05db6e8a589254b241529726"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"04ee5b2ac402d3885279a17072e6cec8b976a577","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"a8b88963_060a1d17","line":299,"updated":"2025-08-21 14:54:04.000000000","message":"So I had a realization today that this object is the only RPC/object change being made to support this feature. Right? Like, we don\u0027t have an RPC version bump to represent the very much different behavior a compute node expects from its neighbor (and no service bump as noted previously). Only the very weak \"the scheduler wouldn\u0027t have sent me here if not\" guarantee that two computes agree to do the extra stuff on either end, which does not seem strong enough to me.\n\nI think that is reinforced by this \"backport\" code, which just silently snips out the new fields, as if that makes it compatible in the sense that the target compute won\u0027t reject it. So, if we ever get to a place where we\u0027re asked to migrate an instance to another compute that doesn\u0027t support what we\u0027re doing here (like, say, someone uses an older microversion to force and bypass the scheduler), this object will arrive at the old compute, get bounced to conductor, which will snip off these two fields and send it to the old compute \"backported\".\n\nI\u0027m not sure where or if we\u0027d fail after that, but I\u0027m guessing that it\u0027s possible we might finish the migration with a fresh TPM and have deleted the old one before we realize what has happened?\n\nThis goes back to my desire to have this be stronger than just scheduler and traits to make sure we\u0027re doing this between compatible computes. One easy (and the strongest, I think) way to do that would just be to have an RPC bump which would prevent us from doing a migration if the pin version is too low. In auto pin mode, however, that would mean we\u0027re stuck until everything has been upgraded (and restarted).\n\nAnother might be to have this backport refuse to just blindly neuter the object and cause the sender to abort. However, that\u0027s probably also less ideal because the failure would be pretty obscure and an operator retrying this would likely get/choose the same host again and fail in the same way.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a945d5d52d71d25cacb245f445a60495f582f360","unresolved":false,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"1d613f8a_cfb23938","line":299,"in_reply_to":"1940ebb3_49604239","updated":"2025-10-20 20:07:12.000000000","message":"Done","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"81129b7becc9955de6fc86f257cce469303cec09","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"1940ebb3_49604239","line":299,"in_reply_to":"35243a3f_a4177180","updated":"2025-10-20 17:50:31.000000000","message":"Understood, sorry about that. I didn\u0027t think of this patch when I fixed the ImageMetaProps patch. I\u0027ll update this one similarly.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"84fd3a36dda51f35f131f4cb6d0fd11b5064c01e","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"c4130d19_8754133d","line":299,"in_reply_to":"492be908_5d6e7cdb","updated":"2025-08-21 21:15:52.000000000","message":"Ack on the RPC.\n\nYeah that\u0027s what I was thinking with the service version bump. However, we only need the service version check for the force live migration case for which the user is required to provide the destination host. So the lookup of the destination host service version can happen in nova-api and return 400 Bad Request if the dest is not new enough. I think it\u0027s pretty cool.\n\nI hear you regarding the existing instances have to resize before the first move, however the scenario I\u0027m imagining is a partially upgraded cluster that is active during this time and people can create new instances that could live migrate to other upgraded computes. I know it is not _recommended_ to stay in the mixed version state for long but if you are upgrading and have a couple of stragglers and it will take you awhile to fix it, it would be cool to still be able to live migrate among all the others that are upgraded.\n\nI still like the ability to live migrate among the new computes but I get your point about it being \"shadow\" RPC version. Trading off between API purity and operability or quality of life.\n\nMaybe another thing to get consensus with gibi and Sean and Sylvain.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1e76d9f6b89ceb17fb656474e5237d0777a7667d","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"492be908_5d6e7cdb","line":299,"in_reply_to":"6855f249_03b5dbb1","updated":"2025-08-21 20:44:04.000000000","message":"I think it would be better to do RPC from the perspective of a kinda direct correlation between the behavior of an RPC call and what we expect to happen behind it. What is here now is another sort of shadow RPC version. However...\n\nAssuming we want this to work even before the full cluster is upgraded, it\u0027s probably better to use a service version bump. BUT, instead of (or rather in addition to) the typical api-checks-service-version-before-action, I think we need to make the compute look up the service version of the other end and confirm it\u0027s new enough before expecting the new behavior. That will be the first such check of its kind, AFAIK.\n\nThe other option would be to just eliminate the expectation that we\u0027re going to allow this on a partially-upgraded cluster and just restrict it at the API until after the upgrade. I think it would be nice to be able to migrate them immediately, but you already can\u0027t move these instances, so maybe we should consider whether it\u0027s worth all the gymnastics.\n\nYou know...if the user has to be able to approve a non-user security mode anyway, especially if we\u0027re going to move to using resize to actually enable the first move, maybe we\u0027re optimizing for something that doesn\u0027t matter much (being able to live migrate these in the middle of an upgrade).","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"22701df1e6dafa457bc0596cf379082c6c5deb14","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"c89bf1fa_d5e9b260","line":299,"in_reply_to":"9146f28d_548af670","updated":"2025-08-25 15:46:41.000000000","message":"so i was chatting with dan elsewhere and ill not that this isnt really aligned with teh spec.\n\nthe spec says we would add a new rpc to transfer the secret\n\n```The instance can be live migrated because Nova can read the secret back from Libvirt on the source host and send it to the destination over RPC. ```\n\nnot extend the exisitn object ot carry it.\n\ni have not been reviewign this series but i was expecting there to be a new compute to compute rpc call to create the secret on the destination host the same way we claim pci device on the destination host.\n\ni was also expecting the deployment mode to be implemtned before the host mode because deploymetn shoudl nto requrie any RPC or obejct changes.\n\nin teh deployment mode the secret is owned by nova so it just download the secrete on teh destioant using it credetias.\n\nit woudl be incorrec to populate vtpm_secret_value int eh case of deployment\n\nit may be ok to have vtpm_secret_uuid althogh im not sure its strictly requried.\nit should not chnage betwen source and dest so im not sure why you are sending it.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"dc2934bb7bde6be169dfec0bb14cf718bcfcde83","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"6855f249_03b5dbb1","line":299,"in_reply_to":"a8b88963_060a1d17","updated":"2025-08-21 19:01:33.000000000","message":"I have a not-yet-uploaded patch that will bump the service version and refuse a force live migration if the service version is too old, so that would handle this case.\n\nDo you think it would be better to do an RPC bump instead or?","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a34851d1c1e19da3491e148a01770005006b2fe8","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"9146f28d_548af670","line":299,"in_reply_to":"b2545147_76d0bb7a","updated":"2025-08-22 00:08:10.000000000","message":"OK, I\u0027ll change it to check a version minimum after the version dump and disallow all vTPM live migration until it\u0027s met. I think that\u0027s what the spec intended anyway though I did not understand it at the time -- it assumed some knowledge that I didn\u0027t have. And since that\u0027s what it meant by bumping the service version, I guess that\u0027s why there was no mention of any RPC bumps being needed.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e969e84438d82ce40798049a441f9ff9d55fd030","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"b2545147_76d0bb7a","line":299,"in_reply_to":"c4130d19_8754133d","updated":"2025-08-21 22:36:58.000000000","message":"\u003e Yeah that\u0027s what I was thinking with the service version bump. However, we only need the service version check for the force live migration case for which the user is required to provide the destination host. So the lookup of the destination host service version can happen in nova-api and return 400 Bad Request if the dest is not new enough. I think it\u0027s pretty cool.\n\nThat\u0027s technically true, but it makes me very uncomfortable to rely only on that. That\u0027s basically saying that we don\u0027t have a strong RPC guarantee between computes anymore and the API services just decide if two things should be compatible and if so, tell them to talk. I definitely don\u0027t like the idea of having a one-off pre-check in the API for compatibility in the force case, separate from the normal scheduler/trait enforcement, which itself is all very fragile because the computes claim to be the same RPC version, but aren\u0027t really (because of the behavioral assumptions involved).\n\n\u003e I hear you regarding the existing instances have to resize before the first move, however the scenario I\u0027m imagining is a partially upgraded cluster that is active during this time and people can create new instances that could live migrate to other upgraded computes. I know it is not _recommended_ to stay in the mixed version state for long but if you are upgrading and have a couple of stragglers and it will take you awhile to fix it, it would be cool to still be able to live migrate among all the others that are upgraded.\n\nI dunno, I don\u0027t think it\u0027s that bad. We\u0027re saying:\n\n1. Instances created with no policy can\u0027t be migrated until they\u0027ve resized to a policy, and\n2. Migration of vTPM-having instances isn\u0027t allowed until the cluster is fully upgraded like many other feature gates.\n\nBoth of those things are pretty easy to grok and pretty conventional.\n\n\u003e Maybe another thing to get consensus with gibi and Sean and Sylvain.\n\nYep.","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f6afa9c1bd7db41f176caffcb968798d71c54640","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            primitive.pop(\u0027vtpm_secret_uuid\u0027, None)"},{"line_number":299,"context_line":"            primitive.pop(\u0027vtpm_secret_value\u0027, None)"},{"line_number":300,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":301,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":302,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":11,"id":"35243a3f_a4177180","line":299,"in_reply_to":"c89bf1fa_d5e9b260","updated":"2025-10-20 17:38:00.000000000","message":"So I think like my previous comment on these backports, this should not be a pop-and-continue operaton. If we\u0027re being asked to backport and these are set to something, we have to refuse as we\u0027re going to be either migrating to a compute that can\u0027t handle this, or we\u0027re going to delete the information it needs in order to do it...right?","commit_id":"98107c1b4cf2c1953b8cc4b719fa7f3b437189d8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d66fc398f399612bbb555aa597d6cb1b8a88bd19","unresolved":true,"context_lines":[{"line_number":287,"context_line":"        \u0027target_mdevs\u0027: fields.DictOfStringsField(),"},{"line_number":288,"context_line":"        \u0027dst_cpu_shared_set_info\u0027: fields.SetOfIntegersField(),"},{"line_number":289,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":290,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":291,"context_line":"    }"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":19,"id":"795a7aeb_3983de46","line":290,"updated":"2025-10-21 14:57:35.000000000","message":"So, will these ever be unset in normal use? In user mode we\u0027ll still pass the uuid but not the value, right? And in deployment we\u0027ll pass both? I assume in host mode we pass nothing? (I guess I need to read up further).\n\nPoint is, I wonder if it would be better to make these nullable\u003dTrue (and check for \u003dNone here). Typically None means \"I see your field and I explicitly say I have nothing to put in it\" which is a little nicer than always having to check for \"field in object\". If the thing is unset then the object will try to lazy-load it (and fail) if you try to access it. Here I think we want to explicitly convey None for each of these if we indeed don\u0027t have any value to send (like vnc and spice addrs above).","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"723be1ba6c753be22d6a7aae94875004c9634227","unresolved":true,"context_lines":[{"line_number":287,"context_line":"        \u0027target_mdevs\u0027: fields.DictOfStringsField(),"},{"line_number":288,"context_line":"        \u0027dst_cpu_shared_set_info\u0027: fields.SetOfIntegersField(),"},{"line_number":289,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":290,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":291,"context_line":"    }"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":19,"id":"f85d63c0_77f2f63c","line":290,"in_reply_to":"795a7aeb_3983de46","updated":"2025-10-21 15:42:52.000000000","message":"Yes they will be unset if not \u0027host\u0027 mode. For \u0027user\u0027 and \u0027deployment\u0027 modes we will not pass the UUID (the UUID is stored anyway in the instance system metadata as part of the original impl of vTPM).\n\nYeah that\u0027s a good point I think. Sorry, the raise-an-error-on-object-backport is not something I was familiar with and I am having trouble thinking about it ... I was getting confused about when the error would be raised when there is nothing to do with vTPM.\n\nI see what you mean, if it is not going to be always used/examined then it should be able to be None. I\u0027ll rework that.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ee725e36e2d54ade2b3a2bd0fccbf10344b149e2","unresolved":false,"context_lines":[{"line_number":287,"context_line":"        \u0027target_mdevs\u0027: fields.DictOfStringsField(),"},{"line_number":288,"context_line":"        \u0027dst_cpu_shared_set_info\u0027: fields.SetOfIntegersField(),"},{"line_number":289,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":290,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":291,"context_line":"    }"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":19,"id":"3ea2e0b1_059758a2","line":290,"in_reply_to":"95342e51_81cc3bc6","updated":"2025-10-23 23:05:33.000000000","message":"Done","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c1e6517027013cca33f0d9ac547b618f483d8a20","unresolved":true,"context_lines":[{"line_number":287,"context_line":"        \u0027target_mdevs\u0027: fields.DictOfStringsField(),"},{"line_number":288,"context_line":"        \u0027dst_cpu_shared_set_info\u0027: fields.SetOfIntegersField(),"},{"line_number":289,"context_line":"        \u0027vtpm_secret_uuid\u0027: fields.UUIDField(),"},{"line_number":290,"context_line":"        \u0027vtpm_secret_value\u0027: fields.SensitiveStringField(),"},{"line_number":291,"context_line":"    }"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    def obj_make_compatible(self, primitive, target_version):"}],"source_content_type":"text/x-python","patch_set":19,"id":"95342e51_81cc3bc6","line":290,"in_reply_to":"f85d63c0_77f2f63c","updated":"2025-10-21 15:50:17.000000000","message":"\u003e Yes they will be unset if not \u0027host\u0027 mode. For \u0027user\u0027 and \u0027deployment\u0027 modes we will not pass the UUID (the UUID is stored anyway in the instance system metadata as part of the original impl of vTPM).\n\nAck, so I think in those cases it would be better if these were nullable\u003dTrue and actually pass them as None in the cases (user and deployment) so it\u0027s clear that we\u0027re new enough to know about this, but we\u0027re specifically not sending them because of our security mode.\n\n\u003e Yeah that\u0027s a good point I think. Sorry, the raise-an-error-on-object-backport is not something I was familiar with and I am having trouble thinking about it ... I was getting confused about when the error would be raised when there is nothing to do with vTPM.\n\nI mean I think you mostly did the right thing with raising, it was just the \u0027in primitive\u0027 versus \u0027is None\u0027 check that made me realize these should be nullable. I think that if we have a 1.14 we only need to refuse to backport if they\u0027re set to something (including None), assuming we\u0027re always setting them to either known values or None in all three of our paths.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d66fc398f399612bbb555aa597d6cb1b8a88bd19","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"ad779d1d_aa0ed239","line":299,"updated":"2025-10-21 14:57:35.000000000","message":"Seeing this is what makes me wonder... will these ever be unset if we instantiate v1.14? Obviously right now they will be unset because we\u0027re not at the patch that sets these to anything, but I\u0027m wondering about cases for either of the three modes where we might need to allow for these to be set to None and not trigger this failure.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"77277d6d11a4e2d0d00810490de8efd45b163ec5","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"6fc36120_b6e79f7f","line":299,"in_reply_to":"48ca0942_5faadaed","updated":"2025-10-22 16:24:17.000000000","message":"Cool, OK. I will make these nullable and then set them for vTPM in later patches.\n\nFor \u0027user\u0027 and \u0027deployment\u0027 they will be set to None and they won\u0027t be used for anything. For \u0027host\u0027 they will be set to values and sent over RPC to the destination so that no call to Barbican will be needed on the destination.\n\nThen for object backleveling, if these are set to anything including None, the backlevel will be rejected raising ObjectActionError since older computes will never be able to support vTPM live migration.\n\nBetween the minimum service version check and the compute traits for scheduling, there should never be a request to backlevel a LibvirtLiveMigrateData for vTPM. But if there is a bug or something somehow gets through, this backlevel refusal will protect in such cases.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2a46e89fbae113d332cec22d94231d620673ab51","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"48ca0942_5faadaed","line":299,"in_reply_to":"55dd851b_6ca75365","updated":"2025-10-22 13:59:22.000000000","message":"Yeah I was primarily commenting on the nullable above and and then the comment here was just for \"any other cases where they would be unset that we would need to do the refusal?\"\n\nThe desired behavior for this backport depends on how it\u0027s used by later patches, so we\u0027re sort of discussing the future here in the present.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"15c065d1cf4c955488e38f6a0277fac494437050","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"a60304d4_4f213922","line":299,"in_reply_to":"57ef7338_fab7b812","updated":"2025-10-21 18:17:32.000000000","message":"Sorry, having gone to try and make this change, I\u0027m confused by seemingly conflicting comments: \"I think that if we have a 1.14 we only need to refuse to backport if they\u0027re set to something (including None), assuming we\u0027re always setting them to either known values or None in all three of our paths\" vs \"we might need to allow for these to be set to None and not trigger this failure\".\n\nIf we refuse to backport if they are set to anything including None, the code would need to be this because a field is only in the primitive if it has been set to something.\n\nIf we allow a value of None during a backport, then that means we would allow backport of \u0027user\u0027 and \u0027deployment\u0027 cases which I didn\u0027t think we wanted to? Or do we?","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ee725e36e2d54ade2b3a2bd0fccbf10344b149e2","unresolved":false,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"e2104e97_0808c2a1","line":299,"in_reply_to":"6fc36120_b6e79f7f","updated":"2025-10-23 23:05:33.000000000","message":"Done","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6537930f2bad3ad8241307eff2b06fd4e3453ed0","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"e9c59500_1d81e887","line":299,"in_reply_to":"a60304d4_4f213922","updated":"2025-10-21 18:32:16.000000000","message":"I think that if the fields are set to anything (including None), it means that the sending code is expecting the receiving code to do something, right? So if we\u0027re asked to backport to 1.14 we should refuse if anything is set - agree?\n\nIf they\u0027re not set, we could potentially just backport by changing the version because the sending code is not expecting any new behavior on the other side. Effectively the case when this patch merges before any of the following ones do. Right?\n\nNow, one way to do this is to just always refuse to backport to older versions, but that feels wrong for the case where we don\u0027t even have a vTPM in play (although now that I say that I wonder if you\u0027re actually going to know that at this layer, so maybe we need to think about that).\n\nI think the important part here is (a) the fields should be nullable so we\u0027re communicating explicitly when we don\u0027t have a secret to send and (b) we should not ever backport this object to the older versions if it would result in dropping information to be communicated to the other side about what the sender is expecting. I haven\u0027t looked at the later patches, so I\u0027m not sure all the cases where this is set and not. But basically I think (correct me if you disagree) the options for \"when to backport to \u003c1.14\" are:\n\n1. Instance in user mode -\u003e refuse (or might this have already worked?)\n2. Instance in host mode -\u003e refuse\n3. Instance in deployment mode -\u003erefuse\n4. Instance has no vTPM -\u003e agree\n\nright?","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"723be1ba6c753be22d6a7aae94875004c9634227","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"57ef7338_fab7b812","line":299,"in_reply_to":"ad779d1d_aa0ed239","updated":"2025-10-21 15:42:52.000000000","message":"Yeah, that makes sense.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3ac3765e03c107e7db83d5e63ad0c800c2888708","unresolved":true,"context_lines":[{"line_number":296,"context_line":"        target_version \u003d versionutils.convert_version_to_tuple(target_version)"},{"line_number":297,"context_line":"        if (target_version \u003c (1, 14)):"},{"line_number":298,"context_line":"            vtpm_fields \u003d [\u0027vtpm_secret_uuid\u0027, \u0027vtpm_secret_value\u0027]"},{"line_number":299,"context_line":"            if any(field in vtpm_fields for field in primitive):"},{"line_number":300,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":301,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":302,"context_line":"                # the TPM secret security policy required by the request."}],"source_content_type":"text/x-python","patch_set":19,"id":"55dd851b_6ca75365","line":299,"in_reply_to":"e9c59500_1d81e887","updated":"2025-10-21 22:28:44.000000000","message":"Yes I think that aligns with the first comment I quoted in my previous reply -- if anything is set, including None, refuse and raise the ObjectActionError.\n\nIf they\u0027re not set, then adjust `target_version` to (1, 13)? I guess I don\u0027t see how setting the target_version to 1.13 would change the behavior vs doing nothing and letting it fall through the way it currently is here in PS19?\n\nYes I agree we wouldn\u0027t want to refuse to backport to older versions unilaterally. In the code today, we know there is no vTPM in play because live migration is rejected at the API, so no vTPM instance will use this object. I don\u0027t see any other way to know it today than that assumption.\n\nAfter this patch, we could tell by the new fields being set.\n\nThe nullable makes sense to me. Currently in the patches the only time we set these at all is for \u0027host\u0027 mode, so I would also need to update the patches to set them for all vTPM instances. The \u0027user\u0027 mode won\u0027t reach LibvirtLiveMigrateData because of the API rejection but I agree with setting it anyway for consistency or for possible bugs. The \u0027deployment\u0027 mode could reach LibvirtLiveMigrateData.\n\nWhat I was confused about is that AFAICT this part of the code, the backport code, will not change from what is here in PS19 when I make the fields nullable and set to None. The only way the primitive can express that fields are not set is by their absence. If they are present, it means they are set. If we are not allowing backport if the field set to None, then it doesn\u0027t matter what it is set to, right? So the only thing we can check for is their presence in the primitive. Checking the value would not result in us doing anything different.","commit_id":"88afa152d22a6464e07337b1434cd1b95a8f9f9f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06498fb14646d4c3f139dcac6a8e8218591ad744","unresolved":true,"context_lines":[{"line_number":303,"context_line":"                # from newer compute which could support vTPM live migration."},{"line_number":304,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":305,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":306,"context_line":"                # the TPM secret security policy required by the request."},{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"}],"source_content_type":"text/x-python","patch_set":29,"id":"7425b18b_dbda684b","line":306,"updated":"2025-12-01 18:34:47.000000000","message":"The commit message says that the other modes will set these to None. However, this check is looking for if they\u0027re set at all. Your comment says \"if either is set, we know this was passed from [a] newer compute\" but the version \u003e\u003d1.14 tells us that straight away. It\u0027s been a while since I was at this point in the stack but... IIRC, we want to allow the backport (to do nothing) if we\u0027re migrating a non-vTPM instance but abort if it\u0027s a vTPM-having instance. Remind me, will these only be set (even to None) if the instance has a vTPM in any mode, but be completely unset if not?","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f20cdf897e3d65e956c393cd9acf77d9faa154a9","unresolved":false,"context_lines":[{"line_number":303,"context_line":"                # from newer compute which could support vTPM live migration."},{"line_number":304,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":305,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":306,"context_line":"                # the TPM secret security policy required by the request."},{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"}],"source_content_type":"text/x-python","patch_set":29,"id":"f20a2d7a_f1c60a73","line":306,"in_reply_to":"0db16999_9a01c770","updated":"2025-12-01 20:57:46.000000000","message":"Acknowledged","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"dc4426341b89f4a30d782f0399acbdf3e303e883","unresolved":true,"context_lines":[{"line_number":303,"context_line":"                # from newer compute which could support vTPM live migration."},{"line_number":304,"context_line":"                # We raise here instead of silently removing the fields during"},{"line_number":305,"context_line":"                # a backport because an older compute will not be able to honor"},{"line_number":306,"context_line":"                # the TPM secret security policy required by the request."},{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"}],"source_content_type":"text/x-python","patch_set":29,"id":"0db16999_9a01c770","line":306,"in_reply_to":"7425b18b_dbda684b","updated":"2025-12-01 19:08:25.000000000","message":"Yes these will only be set (even to None) if the instance has a vTPM in any mode. They will be completely unset if not.\n\nThey will also be completely unset for an old vTPM instance. But an old vTPM instance will not/should not ever have a `LibvirtLiveMigrateData` because live migration is blocked in the API for old vTPM instances.","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06498fb14646d4c3f139dcac6a8e8218591ad744","unresolved":true,"context_lines":[{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"},{"line_number":310,"context_line":"                       (\u0027 and \u0027.join(vtpm_fields), target_version))"},{"line_number":311,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":312,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":313,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":29,"id":"822575e7_bf89e679","line":310,"updated":"2025-12-01 18:34:47.000000000","message":"This is not super important, but the \"reason\" is not just that the fields aren\u0027t supported in the old version (which is true of everything here). Rather, it\u0027s that we can\u0027t backport to something compatible. \"No viable backport action\" or \"Unable to backport newer vTPM support to requested version\" or something like that would make more sense I think.","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"dc4426341b89f4a30d782f0399acbdf3e303e883","unresolved":true,"context_lines":[{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"},{"line_number":310,"context_line":"                       (\u0027 and \u0027.join(vtpm_fields), target_version))"},{"line_number":311,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":312,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":313,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":29,"id":"d748e44c_c4bffecc","line":310,"in_reply_to":"822575e7_bf89e679","updated":"2025-12-01 19:08:25.000000000","message":"OK, I can make the message better in the next respin.","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"37bfc6eb02e79a7e3cd381117ca3eba5c0987e4f","unresolved":false,"context_lines":[{"line_number":307,"context_line":"                raise exception.ObjectActionError("},{"line_number":308,"context_line":"                    action\u003d\u0027obj_make_compatible\u0027,"},{"line_number":309,"context_line":"                    reason\u003d\u0027%s are not supported in version %s\u0027 %"},{"line_number":310,"context_line":"                       (\u0027 and \u0027.join(vtpm_fields), target_version))"},{"line_number":311,"context_line":"        if (target_version \u003c (1, 13)):"},{"line_number":312,"context_line":"            primitive.pop(\u0027pci_dev_map_src_dst\u0027, None)"},{"line_number":313,"context_line":"        if (target_version \u003c (1, 12)):"}],"source_content_type":"text/x-python","patch_set":29,"id":"8ff6fe5f_993e2d22","line":310,"in_reply_to":"d748e44c_c4bffecc","updated":"2025-12-03 04:33:53.000000000","message":"Done","commit_id":"4b7d376e86db3bce639b58c03c46baf81ea8d51a"}]}