)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ec866edc028cf6e6a06b3e78fe41db0a697ccf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"08c28dfc_b3594855","updated":"2025-07-30 06:32:21.000000000","message":"I\u0027d want to have some docs in the same patch (and some relnote too) as it can change a scheduling behavior silently.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"dd9f9cb48777e87f2ba12e28f8c2a329d22dd981","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":19,"id":"e0c52788_7a677eb1","updated":"2025-10-07 16:54:06.000000000","message":"So in playing around with this, I have a devstack deployed at this patch only. I created an instance with a tpm-having flavor, but no security set (so default to user). Obviously the compute is defaulting to user because nothing is in the config:\n```\n$ grep secret_security /etc/nova/nova-cpu.conf\n$\n```\n\nIf I resize to another flavor that has tpm_security\u003dhost (which is allowed by the extra_spec patch below) I expected the resize to fail because there were no hosts yet available with host security. But, it let me confirm the resize to the new flavor. Now, I have an instance running on that host showing a flavor with security\u003dhost:\n```\n$ o server show test -f value -c flavor\n{\u0027name\u0027: \u0027ds512M\u0027, \u0027original_name\u0027: \u0027ds512M\u0027, \u0027description\u0027: None, \u0027disk\u0027: 5, \u0027is_public\u0027: True, \u0027ram\u0027: 512, \u0027vcpus\u0027: 1, \u0027swap\u0027: 0, \u0027ephemeral\u0027: 0, \u0027is_disabled\u0027: None, \u0027rxtx_factor\u0027: None, \u0027extra_specs\u0027: {\u0027hw:tpm_model\u0027: \u0027tpm-crb\u0027, \u0027hw:tpm_secret_security\u0027: \u0027host\u0027, \u0027hw:tpm_version\u0027: \u00272.0\u0027, \u0027hw_rng:allowed\u0027: \u0027True\u0027}, \u0027id\u0027: \u0027ds512M\u0027, \u0027location\u0027: None}\n```\n\nBut, the sysmeta shows still requesting user in the image (which isn\u0027t actually set on the image):\n```\nmysql\u003e select * from instance_system_metadata where instance_system_metadata.key\u003d\"image_hw_tpm_secret_security\";\n+---------------------+------------+------------+----+--------------------------------------+------------------------------+-------+---------+\n| created_at          | updated_at | deleted_at | id | instance_uuid                        | key                          | value | deleted |\n+---------------------+------------+------------+----+--------------------------------------+------------------------------+-------+---------+\n| 2025-10-07 16:31:30 | NULL       | NULL       | 13 | 0d3eb644-14c7-4946-8c65-597dd3c29d86 | image_hw_tpm_secret_security | user  |       0 |\n+---------------------+------------+------------+----+--------------------------------------+------------------------------+-------+---------+\n```\n\nI know I\u0027m testing in the middle of the series here (intentionally) but... is this expected behavior because we\u0027ve pinned the default during the initial boot with a fake image key and that wins over the flavor which conflicts? And, is the later resize flow patch going to change that such that we\u0027re not stuck?\n\nI can go look myself, but I want to make sure that this patch stands on its own if we were to merge it before the rest.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8213254e6812be8674a59fc1b93b7e286762ac3d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":19,"id":"f6d18c6d_2c83c954","updated":"2025-10-07 17:11:55.000000000","message":"Sounds like from IRC just now we need to","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ede3acbe7703fa9e779b8847974811d9622f4af8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":19,"id":"e0d29c11_dff416ad","updated":"2025-10-03 05:50:00.000000000","message":"recheck guest kernel panic","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"49d75807c594d4f65a9666b13b3a3fdab848310e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":19,"id":"c864ba04_67b5ad24","in_reply_to":"e0c52788_7a677eb1","updated":"2025-10-07 17:45:52.000000000","message":"We discussed on IRC but for other readers:\n\nThis is expected behavior at this point in the series (not saying that\u0027s good or bad, just that it is).\n\nIt is defaulting to \u0027user\u0027 because of the lack of specification in the initial create. But it allows the resize because it doesn\u0027t yet know anything about \u0027host\u0027 that is in a later patch. This will be fixed in the next respin.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"52a0b5fa35e276b8f2a9b8c3df06244bf4666835","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":20,"id":"972f2926_03893a34","updated":"2025-10-09 15:28:33.000000000","message":"Also want to note that I was testing this (and sort of the current state of things) by doing a server stop and start as the admin to prove that the admin can\u0027t access the user\u0027s secret. Unrelated to this patch I\u0027m sure, but we get a huge (like YUUGE) stack trace in the n-cpu log when you try and fail, ending in the message we actually care about:\n```\nOct 09 15:25:12 noble nova-compute[291371]: ERROR oslo_messaging.rpc.server   File \"/opt/stack/data/venv/lib/python3.12/site-packages/castellan/key_manager/\nbarbican_key_manager.py\", line 613, in get\nOct 09 15:25:12 noble nova-compute[291371]: ERROR oslo_messaging.rpc.server     raise exception.KeyManagerError(reason\u003de)\nOct 09 15:25:12 noble nova-compute[291371]: ERROR oslo_messaging.rpc.server castellan.common.exception.KeyManagerError: Key manager error: Forbidden: Secret\n payload retrieval attempt not allowed - please review your user/project privileges\n```\nWe should probably catch that and just log it instead of letting the exception bubble all the way up and log a trace. Somewhere around here I think:\n```\nOct 09 15:25:12 noble nova-compute[291371]: ERROR oslo_messaging.rpc.server   File \"/opt/stack/nova/nova/virt/libvirt/driver.py\", line 8269, in _create_guest_with_network\n```","commit_id":"26ae924a5d3e790bd6059e8501fe02c7b1228d1e"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"50ecbc5f91da75607a41b1d0b810a6891a9033c9","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":20,"id":"f27fa395_d3c86965","in_reply_to":"972f2926_03893a34","updated":"2025-10-09 15:35:31.000000000","message":"OK, thanks for pointing that out. I\u0027ll add that.","commit_id":"26ae924a5d3e790bd6059e8501fe02c7b1228d1e"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f84aae4bf67ab479e8ad616850077bd3e2cb5f13","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":20,"id":"15093025_ac6cdbd4","in_reply_to":"f27fa395_d3c86965","updated":"2025-10-10 03:34:15.000000000","message":"Done in https://review.opendev.org/c/openstack/nova/+/963648","commit_id":"26ae924a5d3e790bd6059e8501fe02c7b1228d1e"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8f2abfd13c273f8cb05692349eddfe33a5417f2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":22,"id":"f6e003bb_d49a439c","updated":"2025-10-15 15:13:37.000000000","message":"recheck keystone service did not start\n```\ndevstack@keystone.service[69003]: !!! uWSGI process 69003 got Segmentation Fault !!!\n```","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d0226e2e3714a9d59117ecd64935829de51939e4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":23,"id":"4be22dc3_6c08dbfc","updated":"2025-11-03 18:44:14.000000000","message":"re-adding my +2 after rebase","commit_id":"d7c6a248321a531e095ba790e7b5081136906b8c"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2101a67025aa8a1bb50cf11f31a4184e1a2d582b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":23,"id":"1a5bd085_b33653b7","updated":"2025-11-05 17:20:44.000000000","message":"was a rebase","commit_id":"d7c6a248321a531e095ba790e7b5081136906b8c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9ee31825351a06c75a09202ce4479cc9270242b6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":24,"id":"fc44aac8_d042dffd","updated":"2025-11-05 19:55:07.000000000","message":"Re-working due to spec review comment -- remove system metadata key vtpm_secret_security:\n\nhttps://review.opendev.org/c/openstack/nova-specs/+/961564/3/specs/2026.1/approved/vtpm-live-migration.rst#181","commit_id":"f9f0b24a2dc39c8d788c5de2c0490008d17221af"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b1c202529fa2f75cc2f2a5a2d278cc6a94bac32f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":25,"id":"3566fecb_407ec907","updated":"2025-11-06 09:46:31.000000000","message":"Want to see my DNM tempest results first","commit_id":"d75de5f8c5b8d430cf6cb10ed0ce547bd188e16b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c6290acba715bf69c50c4812aa4069b3fd00e2d7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":26,"id":"a750a6f8_ee323281","updated":"2025-11-17 16:47:29.000000000","message":"just a coverage question for the moment","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"}],"nova/compute/manager.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6bc3e09670a7056b2204cb927e6dae6a434eea0a","unresolved":true,"context_lines":[{"line_number":1104,"context_line":"            security \u003d \u0027user\u0027"},{"line_number":1105,"context_line":""},{"line_number":1106,"context_line":"        # Set the explicitly specified security in the instance system"},{"line_number":1107,"context_line":"        # metadata."},{"line_number":1108,"context_line":"        updates \u003d {\u0027image_hw_tpm_secret_security\u0027: security}"},{"line_number":1109,"context_line":""},{"line_number":1110,"context_line":"        instance.system_metadata.update(updates)"}],"source_content_type":"text/x-python","patch_set":17,"id":"ca8ba74b_10abc261","line":1107,"updated":"2025-09-30 18:43:54.000000000","message":"Okay so in the new scheme, being on a host with no requested policy means you\u0027re user (no per-host default), right? And then they resize out of it if they want to change.\n\nI think the \"explicitly specified security\" verbiage is not quite correct anymore right? It\u0027s either what they requested or what we\u0027re defaulting them to (because it was sort of the previous *implicit* default)...\n\nAnyway, not critical, but probably should go un the FUP patch at least.","commit_id":"55f663801b27ecfee88c90b383bb1c01232cc14f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d27d8dbb2bfe390af18751b0d390b5f6302a801c","unresolved":true,"context_lines":[{"line_number":1104,"context_line":"            security \u003d \u0027user\u0027"},{"line_number":1105,"context_line":""},{"line_number":1106,"context_line":"        # Set the explicitly specified security in the instance system"},{"line_number":1107,"context_line":"        # metadata."},{"line_number":1108,"context_line":"        updates \u003d {\u0027image_hw_tpm_secret_security\u0027: security}"},{"line_number":1109,"context_line":""},{"line_number":1110,"context_line":"        instance.system_metadata.update(updates)"}],"source_content_type":"text/x-python","patch_set":17,"id":"6476936e_22bf6127","line":1107,"in_reply_to":"4eefe710_7ad14220","updated":"2025-10-01 14:12:14.000000000","message":"ack, did this get skipped in the latest respin?","commit_id":"55f663801b27ecfee88c90b383bb1c01232cc14f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3f6fec5c36c0982e4215181aad5a27ccc3dc2931","unresolved":true,"context_lines":[{"line_number":1104,"context_line":"            security \u003d \u0027user\u0027"},{"line_number":1105,"context_line":""},{"line_number":1106,"context_line":"        # Set the explicitly specified security in the instance system"},{"line_number":1107,"context_line":"        # metadata."},{"line_number":1108,"context_line":"        updates \u003d {\u0027image_hw_tpm_secret_security\u0027: security}"},{"line_number":1109,"context_line":""},{"line_number":1110,"context_line":"        instance.system_metadata.update(updates)"}],"source_content_type":"text/x-python","patch_set":17,"id":"eabad756_97ad55c9","line":1107,"in_reply_to":"6476936e_22bf6127","updated":"2025-10-01 16:46:09.000000000","message":"Gahhh yes, sorry 😭 Will fix.","commit_id":"55f663801b27ecfee88c90b383bb1c01232cc14f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"932c6f5a55138628f199ae7ceaaca5a78bdae5de","unresolved":true,"context_lines":[{"line_number":1104,"context_line":"            security \u003d \u0027user\u0027"},{"line_number":1105,"context_line":""},{"line_number":1106,"context_line":"        # Set the explicitly specified security in the instance system"},{"line_number":1107,"context_line":"        # metadata."},{"line_number":1108,"context_line":"        updates \u003d {\u0027image_hw_tpm_secret_security\u0027: security}"},{"line_number":1109,"context_line":""},{"line_number":1110,"context_line":"        instance.system_metadata.update(updates)"}],"source_content_type":"text/x-python","patch_set":17,"id":"4eefe710_7ad14220","line":1107,"in_reply_to":"ca8ba74b_10abc261","updated":"2025-09-30 18:45:52.000000000","message":"Yes you are right. I will need to remove this comment. Will do in the next respin.","commit_id":"55f663801b27ecfee88c90b383bb1c01232cc14f"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ad61eeaa001f2a99e025dfb30abe25abd0c4498e","unresolved":false,"context_lines":[{"line_number":1104,"context_line":"            security \u003d \u0027user\u0027"},{"line_number":1105,"context_line":""},{"line_number":1106,"context_line":"        # Set the explicitly specified security in the instance system"},{"line_number":1107,"context_line":"        # metadata."},{"line_number":1108,"context_line":"        updates \u003d {\u0027image_hw_tpm_secret_security\u0027: security}"},{"line_number":1109,"context_line":""},{"line_number":1110,"context_line":"        instance.system_metadata.update(updates)"}],"source_content_type":"text/x-python","patch_set":17,"id":"1170fb00_46b89817","line":1107,"in_reply_to":"eabad756_97ad55c9","updated":"2025-10-01 20:51:27.000000000","message":"Done","commit_id":"55f663801b27ecfee88c90b383bb1c01232cc14f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"89f48102945caf819515c0efe37c25c7c9780aa6","unresolved":true,"context_lines":[{"line_number":1068,"context_line":"                )"},{"line_number":1069,"context_line":"                raise exception.InvalidConfiguration(msg)"},{"line_number":1070,"context_line":""},{"line_number":1071,"context_line":"    def _set_tpm_secret_security(self, instance: \u0027objects.Instance\u0027) -\u003e bool:"},{"line_number":1072,"context_line":"        \"\"\"Set TPM secret security attributes on an instance."},{"line_number":1073,"context_line":""},{"line_number":1074,"context_line":"        If the instance has a TPM device, set a TPM secret security policy,"}],"source_content_type":"text/x-python","patch_set":22,"id":"d80def1f_f24d42eb","line":1071,"range":{"start_line":1071,"start_character":47,"end_line":1071,"end_character":67},"updated":"2025-10-28 13:59:16.000000000","message":"if I were nitpicking, do we really need this ?\n(just saying, we have a doc description below...)","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f065983a09ab696bc335862232c58452cc8ec55a","unresolved":false,"context_lines":[{"line_number":1068,"context_line":"                )"},{"line_number":1069,"context_line":"                raise exception.InvalidConfiguration(msg)"},{"line_number":1070,"context_line":""},{"line_number":1071,"context_line":"    def _set_tpm_secret_security(self, instance: \u0027objects.Instance\u0027) -\u003e bool:"},{"line_number":1072,"context_line":"        \"\"\"Set TPM secret security attributes on an instance."},{"line_number":1073,"context_line":""},{"line_number":1074,"context_line":"        If the instance has a TPM device, set a TPM secret security policy,"}],"source_content_type":"text/x-python","patch_set":22,"id":"c6d59ebd_bce69600","line":1071,"range":{"start_line":1071,"start_character":47,"end_line":1071,"end_character":67},"in_reply_to":"d80def1f_f24d42eb","updated":"2025-11-10 23:29:25.000000000","message":"Done (obsolete now)","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"}],"nova/conf/libvirt.py":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"89f48102945caf819515c0efe37c25c7c9780aa6","unresolved":false,"context_lines":[{"line_number":1618,"context_line":"* \u0027user\u0027: The Barbican secret is owned by the instance owner and cannot be"},{"line_number":1619,"context_line":"  accessed by anyone else. The Libvirt secret is private and non-persistent."},{"line_number":1620,"context_line":"  The instance cannot be live-migrated or automatically resumed after host"},{"line_number":1621,"context_line":"  reboot."},{"line_number":1622,"context_line":"\"\"\"),"},{"line_number":1623,"context_line":"]"},{"line_number":1624,"context_line":""}],"source_content_type":"text/x-python","patch_set":22,"id":"702b1f36_bfb745a1","line":1621,"updated":"2025-10-28 13:59:16.000000000","message":"which is the legacy behaviour 😊","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"d22663934bb2c7a2c2d646bd6961b3be9bb66917","unresolved":true,"context_lines":[{"line_number":1615,"context_line":""},{"line_number":1616,"context_line":"Possible values are:"},{"line_number":1617,"context_line":""},{"line_number":1618,"context_line":"* \u0027user\u0027: The Barbican secret is owned by the instance owner and cannot be"},{"line_number":1619,"context_line":"  accessed by anyone else. The Libvirt secret is private and non-persistent."},{"line_number":1620,"context_line":"  The instance cannot be live-migrated or automatically resumed after host"},{"line_number":1621,"context_line":"  reboot."}],"source_content_type":"text/x-python","patch_set":23,"id":"6b46c72e_62a0127c","line":1618,"range":{"start_line":1618,"start_character":2,"end_line":1618,"end_character":8},"updated":"2025-10-31 21:36:04.000000000","message":"\\`\\`user\\`\\` for better docs rendering","commit_id":"d7c6a248321a531e095ba790e7b5081136906b8c"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9ee31825351a06c75a09202ce4479cc9270242b6","unresolved":false,"context_lines":[{"line_number":1615,"context_line":""},{"line_number":1616,"context_line":"Possible values are:"},{"line_number":1617,"context_line":""},{"line_number":1618,"context_line":"* \u0027user\u0027: The Barbican secret is owned by the instance owner and cannot be"},{"line_number":1619,"context_line":"  accessed by anyone else. The Libvirt secret is private and non-persistent."},{"line_number":1620,"context_line":"  The instance cannot be live-migrated or automatically resumed after host"},{"line_number":1621,"context_line":"  reboot."}],"source_content_type":"text/x-python","patch_set":23,"id":"ea876a6b_e76314b2","line":1618,"range":{"start_line":1618,"start_character":2,"end_line":1618,"end_character":8},"in_reply_to":"6b46c72e_62a0127c","updated":"2025-11-05 19:55:07.000000000","message":"Done","commit_id":"d7c6a248321a531e095ba790e7b5081136906b8c"}],"nova/scheduler/request_filter.py":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"000b7f36d6656acca3cf84d3d39a5847c21e593f","unresolved":true,"context_lines":[{"line_number":455,"context_line":"        request_spec.root_required.add("},{"line_number":456,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":457,"context_line":""},{"line_number":458,"context_line":"    return True"},{"line_number":459,"context_line":""},{"line_number":460,"context_line":""},{"line_number":461,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":5,"id":"8023daf9_4b5628e7","line":458,"updated":"2025-05-02 00:47:02.000000000","message":"I\u0027m wondering about the case where an instance did not have secret security policy specified in the flavor or image, but it receives the `default_tpm_secret_security` after being scheduled the first time. Wouldn\u0027t future scheduling need to know what is the policy in the instance system_metadata in order to make sure it can only move to a host that supports its policy?","commit_id":"c9477dd9d0828e28d7318f07e4a55b3bd50ece8d"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"1acfe2b676238ca438b15e1370f8ffe39e2cceb2","unresolved":false,"context_lines":[{"line_number":455,"context_line":"        request_spec.root_required.add("},{"line_number":456,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":457,"context_line":""},{"line_number":458,"context_line":"    return True"},{"line_number":459,"context_line":""},{"line_number":460,"context_line":""},{"line_number":461,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":5,"id":"ee58a319_89d45890","line":458,"in_reply_to":"8023daf9_4b5628e7","updated":"2025-07-25 07:37:52.000000000","message":"Done","commit_id":"c9477dd9d0828e28d7318f07e4a55b3bd50ece8d"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9ec866edc028cf6e6a06b3e78fe41db0a697ccf","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"655ae02c_7857885c","line":477,"updated":"2025-07-30 06:32:21.000000000","message":"there is a huge upgrade impact here : older Epoxy computes wouldn\u0027t support that policy, even if from the user pov, nothing changes from the legacy behaviour (I have my TPM credentials that I don\u0027t want to share and I\u0027m cool with not migrating to other hosts)\n\nI know that only happens if the operator modified the flavor or the image to mention the policy explicitely, but we need to clearly explain to the operators that they shouldn\u0027t modify their flavors until the cloud is fully upgrade IMHO.\n\nCan we have some docs addition in https://docs.openstack.org/nova/latest/admin/emulated-tpm.html ?","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4044d97115f1c9e64d5f68a4e09a3488feff8dcc","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"6c3297be_15c5c2fd","line":477,"in_reply_to":"42b68b1c_2b8bf848","updated":"2025-08-04 17:01:29.000000000","message":"I had to think about this more while trying to answer Dan\u0027s question.\n\nWhile live migration is currently blocked for all TPM instances, cold migration is not. TPM instances can cold migrate without restriction.\n\nSo if someone set the `tpm_secret_security` extra spec or image property prematurely to `user` and created a new instance with it, then because of this filter it _would_ get restricted to only new computes that support the `user` policy. So maybe this patch should have this added to the docs?\n\n\u003e But.. doesn\u0027t this need to do something a little smarter? Meaning, shouldn\u0027t this check to see if the flavor has a TPM at all, and if so, consider security\u003d\u003dNone the same way it does security\u003d\u003d\u0027user\u0027 on L475?\n\nI\u0027m not 100% sure I understand the question, but do you mean, \"should TPM with `security \u003d\u003d None` (legacy TPM instances) be considered another case in which to add the trait?\" I was thinking no because doing that would cause legacy TPM instances to not be able to schedule to old computes for cold migration which would be a regression in behavior. Let me know if I misunderstood what you were asking.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8e7cbe3de915939eb0a32c6f8124a0ee56bb9f9b","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"b0a069e4_6716c355","line":477,"in_reply_to":"50631fc9_3193d85b","updated":"2025-08-04 19:10:16.000000000","message":"Hmm, yeah I guess so. I think we probably want to highlight this to gibi when he\u0027s back in case he objects to that. And I guess if he doesn\u0027t, I want to know why. TBH, the whole \"users must be able to refuse\" thing doesn\u0027t resonate strongly with me, but I guess it seems weird to go so hard on that for existing instances without similar considerations for the later ones.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"73108805f321044d75207139d23b9806d1fd9cd5","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"7f4fd02a_ecfc2023","line":477,"in_reply_to":"655ae02c_7857885c","updated":"2025-07-30 15:33:57.000000000","message":"This situation is different in that the legacy behavior is that live migration for vTPM is not allowed at all. It is blocked in the API [1]. Even if it were not, the absence of the TPM secret security traits on old computes simply prevents new instances from being able to migrate to old computes, which is what we want and which is the current behavior today. The scheduling behavior is not changed.\n\nAlso, this patch is not doing anything to enable live migration for new instances either -- that occurs later in the series. So if we want to anyway add docs and/or release note to explain that live migration is now available for certain new instances and can only schedule to new computes, it would be on a later patch, not this one.\n\n[1] https://github.com/openstack/nova/blob/6c03f9d1dade6146897a95d61d9202b6db0fe90d/nova/compute/api.py#L5575","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d3a128bba37e835beafd91a54253e855005497ef","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"b45ea779_b07cc7d6","line":477,"in_reply_to":"6c3297be_15c5c2fd","updated":"2025-08-04 17:49:49.000000000","message":"Okay, but still, even after all the computes have been upgraded, a flavor leftover from legacy TPM times would need to be considered to be in policy\u003duser mode for this right? Else, using one of those older flavors (or images I guess) would not request anything here and then could land on a compute that will assume no policy means user, which it may not be configured to support, right?","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c2084952eb5ed0cd6d1dadaafd80c1de2372e22f","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"42b68b1c_2b8bf848","line":477,"in_reply_to":"7f4fd02a_ecfc2023","updated":"2025-08-04 14:45:54.000000000","message":"Agree with melwitt\u0027s assessment of the (non-)upgrade impact.\n\nBut.. doesn\u0027t this need to do something a little smarter? Meaning, shouldn\u0027t this check to see if the flavor has a TPM at all, and if so, consider `security\u003d\u003dNone` the same way it does `security\u003d\u003d\u0027user\u0027` on L475?","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf59c0d4f875b19c85c544c81fa76210786ca184","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"bf680aa1_5223d9f7","line":477,"in_reply_to":"8c865f1e_eb2a2bfb","updated":"2025-08-19 19:28:06.000000000","message":"I\u0027m low on technical details and unfortunately also low on brain power at the moment. So I cannot go into implementation detail now. \n\nMy original goal was to allow the security conscious user to opt-in to any new behavior that decreases the security of the TPM key. \nIn case of a new instance that is achievable by setting the image metadata on the user provided image before creating the instance.\nFor a pre-existing instances I assumed that the cloud provider will ping the user to accept the new security level, defined by the host of the instance, by hard rebooting the instance or to reject it by deleting the instance (and creating a new one with a specific image metadata in place).\n\nAs far as I understand the problem above is that after this feature we still have new instance created without specifying a level in flavor or image and therefor falling back to the host default.\n\nCould we instead make the every new boot require the flavor or the image value defined? Could we also make the same limitation on all the flavor and image changing lifecycle operation (resize, rebuild)? Of course only if tpm is also requested for the instance. \n\nI know, flavor explosion. But this would only affect flavors that asks for vtpm. Also the admin could decide that flavors providing vtpm does not define the security level forcing the user to provide it in the image. So the flavor explosion would be limited.\n\nI assume opting into the host level default will transform the pre-existing instance to a state where the instance\u0027s copy of the image properties are updated to hold the host level default, so these instances automatically get a virtual image with an explicit security level after the hard reboot. So after all pre-existing instances are rebooted the host value is not needed any more as new instances will get it via the mandatory image or flavor values.\n\nI know there is the issue of the request spec update. But I don\u0027t have technical context how the request spec gets the information of the image properties during a new boot or during a subsequent migration. I want to assume that it uses the instance\u0027s copy of the image properties and flavor extra specs. But I fear that the problem is that it is not using that data store but maintains an independent copy of that data. Maybe the solution here is to get rid of the independent copy in the request spec and rely on the instance\u0027s copy. But I\u0027m pretty sure this is not as simple as I imagine now.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"355aedf8bfa6f5b597d36b785c414f262cb909b2","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"8c865f1e_eb2a2bfb","line":477,"in_reply_to":"9c385a08_aaf9aa67","updated":"2025-08-04 21:35:01.000000000","message":"Understood, thanks.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3a1db011692160cda7bea38ee06a06b653caa384","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"e0417ce4_bbb53289","line":477,"in_reply_to":"b0a069e4_6716c355","updated":"2025-08-04 19:55:32.000000000","message":"I could be wrong but I was thinking the confirm/refuse is really about cases where the TPM secret security policy would be changed from what the user previously knew about their instance.\n\nFor example, a user has an existing instance that has a Barbican secret owned by and only readable by their user from day one. When their compute host is upgraded to this new code and if `default_tpm_secret_security \u003d deployment`, without a confirm/refuse process, their Barbican secret would be deleted and replaced with one owned by the Nova service user automatically. They used to be able to read their Barbican secret and now they can\u0027t. With confirm/refuse, they can opt to keep their Barbican secret the way it is as long as they don\u0027t hard reboot or stop/start their instance.\n\nWith new instances, they get a TPM secret policy that will not be changed in the middle of the instance lifetime, and confirm/refuse is not applicable.\n\nI will ask gibi to comment on this when he is back.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"847198437d14d0d9d3f5bbdfb979d50ce0b0128b","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"ccfcd871_76dc5680","line":477,"in_reply_to":"b45ea779_b07cc7d6","updated":"2025-08-04 18:21:56.000000000","message":"I don\u0027t think so because if there is no secret security policy specified in the flavor or image then the instance is supposed to take the `[libvirt]default_tpm_secret_security` from the compute host it lands on right? So initially it will be scheduled wherever and then it will be set to the default and captured in `image_hw_tpm_secret_security` in the instance system metadata when it lands on a compute.\n\nSubsequent scheduling would be an issue and that is covered in a later patch in the series to update the instance request spec to reflect the `image_hw_tpm_secret_security` from the instance system metadata (since we can\u0027t look at instance system metadata during scheduling AFAIK).","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"49d75807c594d4f65a9666b13b3a3fdab848310e","unresolved":false,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"69407b33_3d20ceba","line":477,"in_reply_to":"bf680aa1_5223d9f7","updated":"2025-10-07 17:45:52.000000000","message":"I\u0027m going to close out this thread as Obsolete to avoid confusion, given the updated/current design no longer has a user confirmation mechanism.","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"39dac84045d9379f0697a1bea2a9ecbfae7bb06e","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"e756d6b5_3378283e","line":477,"in_reply_to":"ccfcd871_76dc5680","updated":"2025-08-04 18:38:22.000000000","message":"Okay perhaps that\u0027s me not having grokked the full series. I guess I thought the goal was to end up with only flavors that target a specific policy and not a bunch of flavors that will get a policy that depends on where they land. I assumed the default was for the admins to say \"unless you disagree, X is the policy you will get when you hard reboot your legacy instance.\"\n\nLike, the reason we have this provisional-\u003eapprove-\u003epermanent policy workflow is because of the concern around people having not been able to object to a given policy after they\u0027ve already used the TPM. For an image that expects to initialize the TPM on first use (i.e. an image that, like SSH keys, generates a new FDE key on first boot and stashes it into the TPM)...the user would have no way to know what the policy for a flavor without one specified until they boot and then examine the resulting instance, right?","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8459899cac081f481fe82306d7c652eef9691b20","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"9c385a08_aaf9aa67","line":477,"in_reply_to":"e0417ce4_bbb53289","updated":"2025-08-04 20:55:20.000000000","message":"Oh I know, it\u0027s a much bigger deal to do the change-the-existing thing than otherwise, no doubt. It just seems inconsistent with the transparency part of it is all. Anyway, other than the consistency of the implementation, I\u0027m not bothered by it, I just want to make sure gibi gets a chance to object if he wants (before the release, no need to hold the patch).","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c4b18f6b594c8aa858156f80f1e668a86683d5fc","unresolved":true,"context_lines":[{"line_number":474,"context_line":"                                                           request_spec.image)"},{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""}],"source_content_type":"text/x-python","patch_set":13,"id":"50631fc9_3193d85b","line":477,"in_reply_to":"e756d6b5_3378283e","updated":"2025-08-04 18:54:56.000000000","message":"\u003e Okay perhaps that\u0027s me not having grokked the full series. I guess I thought the goal was to end up with only flavors that target a specific policy and not a bunch of flavors that will get a policy that depends on where they land. I assumed the default was for the admins to say \"unless you disagree, X is the policy you will get when you hard reboot your legacy instance.\"\n\nHm OK, I hadn\u0027t thought of the default as only applying to legacy instances -- I thought it was for longterm as well in that users need not have a preference about their TPM secret security and if they don\u0027t care, they don\u0027t have to specify it. And for new instances they receive the default permanently.\n\n\u003e Like, the reason we have this provisional-\u003eapprove-\u003epermanent policy workflow is because of the concern around people having not been able to object to a given policy after they\u0027ve already used the TPM. For an image that expects to initialize the TPM on first use (i.e. an image that, like SSH keys, generates a new FDE key on first boot and stashes it into the TPM)...the user would have no way to know what the policy for a flavor without one specified until they boot and then examine the resulting instance, right?\n\nRight, they would not know until they boot if they didn\u0027t specify one.\n\nIf `default_tpm_secret_security` was not meant to be a longterm thing then I don\u0027t feel the spec made that clear. /me consults the spec again ...\n\nThis sentence is what made me think the default is part of the overall design and not only applicable for legacy instances [1]:\n\n\"For operators that do not want to deal with flavor explosion as a consequence of this new extra spec, a new host configuration option is added as a fallback. Called [libvirt]default_tpm_secret_security with a default value of user (which is existing behavior), an instance with no image property or flavor extra spec will have its host’s tpm_secret_security policy persisted in its system_metadata upon booting on that host.\"\n\n[1] https://specs.openstack.org/openstack/nova-specs/specs/2025.2/approved/vtpm-live-migration.html#id1","commit_id":"1f3704d29336cda575aa8b76a31b1bf20790ff9b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8213254e6812be8674a59fc1b93b7e286762ac3d","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"12944943_70a5b1df","line":478,"updated":"2025-10-07 17:11:55.000000000","message":"From the IRC discussion just now, I think we need an `else` case here to either reject or return false or something if we hit a security policy we don\u0027t know about.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b6e78fb905787b47aa6d84b42b1cac16f2b9488e","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"4cd5bc6b_42b743ad","line":478,"in_reply_to":"00c5730b_f3aa5a75","updated":"2025-10-09 16:15:24.000000000","message":"\u003e However, the API is a bit different in that the user doesn\u0027t know whether what they\u0027re asking for will be satisfy-able because they don\u0027t know if there are any deployment-configured compute hosts behind the wall. So I think it just changes the nature of the thing.\n\nYeah, I can see that point of view. The feeling crossed my mind when I realized I couldn\u0027t make image property fail faster because it was a reminder how \"easily\" we will be able to get scheduling failures in general, even when the series is all done. So the \"fail fast for valid values\" felt a lot more like a drop in the bucket given that and not nearly as impactful. Can improve a few specific cases but you\u0027re still left with the very common experience of being able to fail scheduling.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a8a18c5ae41bbb2b013a2ede0b97f8414d8eae5a","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"5d5478b6_b4481620","line":478,"in_reply_to":"12944943_70a5b1df","updated":"2025-10-07 19:59:53.000000000","message":"While I\u0027m adding test coverage for the reject case ... I\u0027m realizing that maybe an additional change needs to happen further back in the series with regard to the image property and extra spec.\n\nMaybe in these early patches only \u0027user\u0027 should be a valid value in the enum for image and flavor until the later patches that add \u0027host\u0027 and \u0027deployment\u0027 respectively.\n\nBecause even if we reject resize scheduling for an unsupported-at-this-time value \u0027host\u0027, someone could still **create** a server with \u0027host\u0027 specified in the flavor, for example. And if they did, it would create the instance but then fail the scheduling and leave the user with an instance in ERROR state. I\u0027m thinking we shouldn\u0027t even allow the user to get into that situation by exposing not-yet-supported values until they are actually supported.\n\nWith this in mind I\u0027ll go back a couple of patches and remove \u0027host\u0027 and \u0027deployment\u0027 and add them back in as we reach the patches that make them be supported. This way we will help make sure each patch in the series can stand on its own.\n\nWith those changes made, I\u0027ll still have this reject scheduling block -- just not sure how to test cover it if the field validation will reject the request at the API. Maybe just via unit tests if I can\u0027t think of a way to get it with functional.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8e801720ae8220dff0a36afb84463b62a2a6e0bc","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"efc753ad_2060194a","line":478,"in_reply_to":"2547d4d6_fd1085e2","updated":"2025-10-09 15:53:54.000000000","message":"I see what you mean. The way I had been thinking about it was, presenting \u0027host\u0027 for example when there is literally no possible way for the deployment to give the \u0027host\u0027 mode anywhere, would be a bit silly. And in the most extreme case, I was thinking what if we only merged \u0027host\u0027 and then nothing else after it. Then \u0027deployment\u0027 is sitting there as a choice when it means nothing and won\u0027t mean anything for who knows how long.\n\nHaha, thanks for saying that. I think your points are good. The asymmetry was bothering me anyway and I almost changed it back the other day before pushing the respin because of it.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f84aae4bf67ab479e8ad616850077bd3e2cb5f13","unresolved":false,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"cd5f34db_067d23a2","line":478,"in_reply_to":"4cd5bc6b_42b743ad","updated":"2025-10-10 03:34:15.000000000","message":"Done","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"512f3c045f7f9e6f207096571728db7e3793a257","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"ae8e7359_464cead7","line":478,"in_reply_to":"5d5478b6_b4481620","updated":"2025-10-09 15:01:01.000000000","message":"I dunno, the behavior of getting an error if you try to create with host or deployment at this point is exactly what I was testing for. It\u0027s the same behavior a user will see if they try to create with a policy that the operator doesn\u0027t support. They won\u0027t see the extra spec validation fail - they\u0027ll just see a schedule fail and wouldn\u0027t know whether it\u0027s because the operator has only rolled to this commit, or if the operator hasn\u0027t enabled any nodes for the requested mode.\n\nIterating the extra spec validation seems worse to me, since we\u0027re subtly changing the API many times. I know we don\u0027t microversion for the extra specs, but I guess I\u0027d rather see us change it as few times as possible.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"77c0a4fd877137a93fd2960a8152adf35c6205ed","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"2547d4d6_fd1085e2","line":478,"in_reply_to":"81f626b6_09272a06","updated":"2025-10-09 15:43:43.000000000","message":"I guess another way to put it is.. it\u0027s fail fast only for the next three patches..after those, it will be \"fail at the scheduler\" for *probably* two of the three values on all deployments, assuming operators just pick a mode and only support that one. So, we\u0027re spreading the API changes out to fail fast(er) for one patch. Seems better to just set the behavior the way it will end up, especially since the failure mode is identical from the non-config-knowing user\u0027s perspective the whole way through.\n\nAnyway, again, no need to change it back, I\u0027m just reacting to your sad face disappointment in my opinion and so I\u0027m defending it :D","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8ee7b2ed2a356a174e4e14b08d649541cda00132","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"17d0b5c1_fd0df3c7","line":478,"in_reply_to":"81f626b6_09272a06","updated":"2025-10-09 15:42:25.000000000","message":"It would have been my preference if I could have made the image property match but since I couldn\u0027t, I don\u0027t love the asymmetrical behavior. So for that, combined with your feedback, I think it\u0027s probably best to change it back.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"8fd7266c8f8540b7222d65438180f5e2da7af977","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"81f626b6_09272a06","line":478,"in_reply_to":"ab5b27e8_4744270a","updated":"2025-10-09 15:36:07.000000000","message":"You don\u0027t have to change it back, I\u0027m just saying.. I was expecting the previous behavior, but with proper scheduler failure. And that changing the API three times in a row is less desirable.\n\nBut, no need to change it if this is really your preference.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a91d3d25da420c6e0cc87a0c3660057041a2d524","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"ab5b27e8_4744270a","line":478,"in_reply_to":"ae8e7359_464cead7","updated":"2025-10-09 15:33:39.000000000","message":"Really? 🙁 I get your point about not changing the \"API\". I had been thinking that if it was possible to fail faster it would be better, but I did find that for the image property there was no existing way to fail earlier than scheduling. So I\u0027m less disappointed to have to go change it back than I would have been since having all 3 here would be no worse than the image property behavior.","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"54ec3c2083fdbc013f0b1a0fb499968c2f40764c","unresolved":true,"context_lines":[{"line_number":475,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":476,"context_line":"        request_spec.root_required.add("},{"line_number":477,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":478,"context_line":"    return True"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":""},{"line_number":481,"context_line":"ALL_REQUEST_FILTERS \u003d ["}],"source_content_type":"text/x-python","patch_set":19,"id":"00c5730b_f3aa5a75","line":478,"in_reply_to":"efc753ad_2060194a","updated":"2025-10-09 15:58:56.000000000","message":"\u003e I see what you mean. The way I had been thinking about it was, presenting \u0027host\u0027 for example when there is literally no possible way for the deployment to give the \u0027host\u0027 mode anywhere, would be a bit silly. And in the most extreme case, I was thinking what if we only merged \u0027host\u0027 and then nothing else after it. Then \u0027deployment\u0027 is sitting there as a choice when it means nothing and won\u0027t mean anything for who knows how long.\n\nYeah, I totally get what you\u0027re saying, I just think that this is different from, say, a config knob. We\u0027d not add \"deployment\" before the code to handle it obviously, but rather only when you can actually choose that (as you\u0027re doing in this set). However, the API is a bit different in that the user doesn\u0027t know whether what they\u0027re asking for will be satisfy-able because they don\u0027t know if there are any deployment-configured compute hosts behind the wall. So I think it just changes the nature of the thing.\n\nIf we were validating the extra spec \"live\" by looking at the current set of hosts and saying \"reject because none of the hosts are even configured for that\" then it\u0027d be a different story in my mind.\n\nAnyway, it\u0027s a judgment/opinion call, do what your judgment tells you :)","commit_id":"82d1a45b431bbd381e6f897424756f0bcc116978"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"89f48102945caf819515c0efe37c25c7c9780aa6","unresolved":true,"context_lines":[{"line_number":476,"context_line":"        LOG.debug(\"tpm_secret_security_filter skipped\")"},{"line_number":477,"context_line":"        return False"},{"line_number":478,"context_line":""},{"line_number":479,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":480,"context_line":"        request_spec.root_required.add("},{"line_number":481,"context_line":"            os_traits.COMPUTE_SECURITY_TPM_SECRET_SECURITY_USER)"},{"line_number":482,"context_line":"    else:"}],"source_content_type":"text/x-python","patch_set":22,"id":"58f85e91_81c26ee2","line":479,"updated":"2025-10-28 13:59:16.000000000","message":"this could change over releases, but I don\u0027t think this is an interop issue so kk.","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d2116b04b18219a1e39b4d60ce50fe4a4d9ba96a","unresolved":true,"context_lines":[{"line_number":478,"context_line":"        return False"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":"    security \u003d hardware.get_tpm_secret_security_constraint("},{"line_number":481,"context_line":"            request_spec.flavor) or \u0027user\u0027"},{"line_number":482,"context_line":""},{"line_number":483,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":484,"context_line":"        request_spec.root_required.add("}],"source_content_type":"text/x-python","patch_set":26,"id":"d091f44c_fd2151ed","line":481,"updated":"2025-11-12 19:16:05.000000000","message":"So, I think I\u0027m reading this that for the point in this patch, we were already basically using the flavor for our indication anyway, right? So the removal of the sysmeta key didn\u0027t really change much here and yet.\n\nBut, I\u0027m noticing the `or \u0027user\u0027` change... before we were skipping this filter if not security policy was set but now we\u0027re assuming user if nothing was specified.. is that a change you made because it seems right, or because it has some intersection with the sysmeta key removal that I\u0027m missing?","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06ddcb9f580c7482dd136d719d22034921b3b363","unresolved":true,"context_lines":[{"line_number":478,"context_line":"        return False"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":"    security \u003d hardware.get_tpm_secret_security_constraint("},{"line_number":481,"context_line":"            request_spec.flavor) or \u0027user\u0027"},{"line_number":482,"context_line":""},{"line_number":483,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":484,"context_line":"        request_spec.root_required.add("}],"source_content_type":"text/x-python","patch_set":26,"id":"a6ef1529_151643a7","line":481,"in_reply_to":"58be8e57_1fc8e10a","updated":"2025-11-18 17:30:22.000000000","message":"\u003e The tl;dr is that if we don\u0027t need to be able to separate legacy vTPM instances from new defaulted `user` instances, then we can just assume `user` here if there\u0027s nothing in the flavor.\n\nRight, I think this is the important thing... TPM with no policy is exactly the same as TPM with policy of user, right? I mean, I think that makes sense as it\u0027s really the reality. It makes me think we should require a policy (for new instances) if a TPM is configured to avoid people being lazy and assuming that user is the default if not specified, but alas.","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"96c87df8648432a7d5412a88818dd9a20f7d3056","unresolved":true,"context_lines":[{"line_number":478,"context_line":"        return False"},{"line_number":479,"context_line":""},{"line_number":480,"context_line":"    security \u003d hardware.get_tpm_secret_security_constraint("},{"line_number":481,"context_line":"            request_spec.flavor) or \u0027user\u0027"},{"line_number":482,"context_line":""},{"line_number":483,"context_line":"    if security \u003d\u003d \u0027user\u0027:"},{"line_number":484,"context_line":"        request_spec.root_required.add("}],"source_content_type":"text/x-python","patch_set":26,"id":"58be8e57_1fc8e10a","line":481,"in_reply_to":"d091f44c_fd2151ed","updated":"2025-11-12 20:28:00.000000000","message":"I had to think about this a bit to remember -- it\u0027s vaguely related to the sysmeta key removal in that thinking about the key removal made me think of about a use case I hadn\u0027t seriously considered previously.\n\nThe tl;dr is that if we don\u0027t need to be able to separate legacy vTPM instances from new defaulted `user` instances, then we can just assume `user` here if there\u0027s nothing in the flavor.\n\nNow, apologies in advance if the rest of this is confusing because I\u0027m not sure I can explain it well enough in a single comment.\n\nThe use case I hadn\u0027t previously considered seriously is where an operator might want to disallow `user` secret security altogether. Previously I had been thinking the concept wouldn\u0027t make sense because `user` is the default and then besides that, there would be no way to make it possible other than stashing a sysmeta key.\n\nBut thinking more about it I thought, \"well what if an operator didn\u0027t want to support un-live-migratable vTPM instances at all because they wanted to be guaranteed they could live migrate?\" It seemed like a reasonable idea to me. They could set [libvirt]supported_tpm_secret_security to exclude `user` from the list. \n\nThen I thought, what about legacy vTPM instances from before `user` was a thing?\nI thought that we would need to be able to tell the difference between a legacy vTPM instance vs a new default one with `user`. So that we could block new `user` instances scheduling but leave legacy instances unaffected. I thought a sysmeta key would be required to tell the difference. If the key is present, it\u0027s new. If the key is not there, it\u0027s legacy.\n\nThen we talked about vTPM stuff at the PTG and one of the takeaways I got was that legacy vTPM \u003d\u003d new vTPM `user` and that there is no reason to separate them. So if we don\u0027t need to tell the difference, we could just default to `user` here. And we would need to in order to block `user` instances from scheduling if they were defaulted to `user` and it\u0027s not in the flavor.\n\nThat would indeed make legacy vTPM instances stuck unable to move until they resize to one of the security policies the operator has configured to support. I thought this is probably this OK. They could keep their legacy vTPM if they don\u0027t move it, but if they want to move it they have to opt-in to the new scheme that the operator wants to require.","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"}],"nova/tests/fixtures/libvirt.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5bffed18ac85c01073e2cc86f9f24a628702553b","unresolved":true,"context_lines":[{"line_number":1936,"context_line":""},{"line_number":1937,"context_line":"    def _remove_secret(self, secret):"},{"line_number":1938,"context_line":"        self._removed_secrets[secret._uuid] \u003d secret"},{"line_number":1939,"context_line":"        del self._secrets[secret._uuid]"},{"line_number":1940,"context_line":""},{"line_number":1941,"context_line":"    def _mark_running(self, dom):"},{"line_number":1942,"context_line":"        self._running_vms[self._id_counter] \u003d dom"}],"source_content_type":"text/x-python","patch_set":11,"id":"d9527b63_9923a785","line":1939,"updated":"2025-07-29 13:59:46.000000000","message":"Doesn\u0027t matter, but I have to say it:\n```\nself._removed_secrets[secret._uuid] \u003d self._secrets.pop(secret._uuid)\n```","commit_id":"933cdee9e7ae8a0ee40a676d03959acd32609fc4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"10929064d7303f2844654bf3b0675572f0a2cef3","unresolved":false,"context_lines":[{"line_number":1936,"context_line":""},{"line_number":1937,"context_line":"    def _remove_secret(self, secret):"},{"line_number":1938,"context_line":"        self._removed_secrets[secret._uuid] \u003d secret"},{"line_number":1939,"context_line":"        del self._secrets[secret._uuid]"},{"line_number":1940,"context_line":""},{"line_number":1941,"context_line":"    def _mark_running(self, dom):"},{"line_number":1942,"context_line":"        self._running_vms[self._id_counter] \u003d dom"}],"source_content_type":"text/x-python","patch_set":11,"id":"01ea4209_cc2d102c","line":1939,"in_reply_to":"c7614668_b06f40d7","updated":"2025-07-30 01:16:15.000000000","message":"Done","commit_id":"933cdee9e7ae8a0ee40a676d03959acd32609fc4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4714656ef5c34787e9ff8c354993d945ab530e78","unresolved":true,"context_lines":[{"line_number":1936,"context_line":""},{"line_number":1937,"context_line":"    def _remove_secret(self, secret):"},{"line_number":1938,"context_line":"        self._removed_secrets[secret._uuid] \u003d secret"},{"line_number":1939,"context_line":"        del self._secrets[secret._uuid]"},{"line_number":1940,"context_line":""},{"line_number":1941,"context_line":"    def _mark_running(self, dom):"},{"line_number":1942,"context_line":"        self._running_vms[self._id_counter] \u003d dom"}],"source_content_type":"text/x-python","patch_set":11,"id":"c7614668_b06f40d7","line":1939,"in_reply_to":"d9527b63_9923a785","updated":"2025-07-29 16:45:17.000000000","message":"🙂","commit_id":"933cdee9e7ae8a0ee40a676d03959acd32609fc4"}],"nova/tests/functional/libvirt/test_vtpm.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9649eae8ef4ffe37b337d1f8cb27fe1be9a92243","unresolved":true,"context_lines":[{"line_number":466,"context_line":"        extra_specs \u003d {"},{"line_number":467,"context_line":"            \u0027hw:tpm_model\u0027: \u0027tpm-tis\u0027,"},{"line_number":468,"context_line":"            \u0027hw:tpm_version\u0027: \u00271.2\u0027,"},{"line_number":469,"context_line":"            \u0027hw:tpm_secret_security\u0027: \u0027host\u0027}"},{"line_number":470,"context_line":"        flavor_id \u003d self._create_flavor(extra_spec\u003dextra_specs)"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"        with mock.patch("}],"source_content_type":"text/x-python","patch_set":21,"id":"3724a0e5_8db7e13d","line":469,"updated":"2025-10-13 16:54:29.000000000","message":"Can\u0027t we create this with \"foobar\" at this level and then we can keep this test even after the host patch to make sure that if we ever get an unsupported security model, we refuse?","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"83b03e1e47a014c793eaf396933119413a2f1762","unresolved":false,"context_lines":[{"line_number":466,"context_line":"        extra_specs \u003d {"},{"line_number":467,"context_line":"            \u0027hw:tpm_model\u0027: \u0027tpm-tis\u0027,"},{"line_number":468,"context_line":"            \u0027hw:tpm_version\u0027: \u00271.2\u0027,"},{"line_number":469,"context_line":"            \u0027hw:tpm_secret_security\u0027: \u0027host\u0027}"},{"line_number":470,"context_line":"        flavor_id \u003d self._create_flavor(extra_spec\u003dextra_specs)"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"        with mock.patch("}],"source_content_type":"text/x-python","patch_set":21,"id":"dcdfeeae_f29d20e3","line":469,"in_reply_to":"311808a7_181db3ed","updated":"2025-10-13 21:40:29.000000000","message":"Acknowledged","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6f94dd096cea7ae919f1a62d0d38cd84f11ca4cf","unresolved":true,"context_lines":[{"line_number":466,"context_line":"        extra_specs \u003d {"},{"line_number":467,"context_line":"            \u0027hw:tpm_model\u0027: \u0027tpm-tis\u0027,"},{"line_number":468,"context_line":"            \u0027hw:tpm_version\u0027: \u00271.2\u0027,"},{"line_number":469,"context_line":"            \u0027hw:tpm_secret_security\u0027: \u0027host\u0027}"},{"line_number":470,"context_line":"        flavor_id \u003d self._create_flavor(extra_spec\u003dextra_specs)"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"        with mock.patch("}],"source_content_type":"text/x-python","patch_set":21,"id":"6b308b2a_965979a4","line":469,"in_reply_to":"3724a0e5_8db7e13d","updated":"2025-10-13 20:01:47.000000000","message":"No because the extra spec validation would kick out \"foobar\" early at the API. And I think image props has similar enforcement of things in the underlying field enum.\n\nWhat I did down the line is for the \u0027host\u0027 patch I changed it to \"deployment\" and then for the \u0027deployment\u0027 patch I made it so the destination host only supports \u0027user\u0027. Don\u0027t ask why, there is not a real reason.\n\nSo what I can do is just collapse all of that ^ into this patch and then not change it in later patches.","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d12346071daebbd52f958f12bfd1b17184b5f67","unresolved":true,"context_lines":[{"line_number":466,"context_line":"        extra_specs \u003d {"},{"line_number":467,"context_line":"            \u0027hw:tpm_model\u0027: \u0027tpm-tis\u0027,"},{"line_number":468,"context_line":"            \u0027hw:tpm_version\u0027: \u00271.2\u0027,"},{"line_number":469,"context_line":"            \u0027hw:tpm_secret_security\u0027: \u0027host\u0027}"},{"line_number":470,"context_line":"        flavor_id \u003d self._create_flavor(extra_spec\u003dextra_specs)"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"        with mock.patch("}],"source_content_type":"text/x-python","patch_set":21,"id":"6caf033c_cecf92e2","line":469,"in_reply_to":"6b308b2a_965979a4","updated":"2025-10-13 21:07:31.000000000","message":"Ack, well, I meant as a backstop for the props and extra specs enforcement that will just continue working no matter what, but fair enough. Maybe could also just  mock something out to run the filter function in a way that will trip it.","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f9fcd8e0c2bd8940fb3f7a8c630155e4eef2c70e","unresolved":true,"context_lines":[{"line_number":466,"context_line":"        extra_specs \u003d {"},{"line_number":467,"context_line":"            \u0027hw:tpm_model\u0027: \u0027tpm-tis\u0027,"},{"line_number":468,"context_line":"            \u0027hw:tpm_version\u0027: \u00271.2\u0027,"},{"line_number":469,"context_line":"            \u0027hw:tpm_secret_security\u0027: \u0027host\u0027}"},{"line_number":470,"context_line":"        flavor_id \u003d self._create_flavor(extra_spec\u003dextra_specs)"},{"line_number":471,"context_line":""},{"line_number":472,"context_line":"        with mock.patch("}],"source_content_type":"text/x-python","patch_set":21,"id":"311808a7_181db3ed","line":469,"in_reply_to":"6caf033c_cecf92e2","updated":"2025-10-13 21:18:05.000000000","message":"I have the mocking approach essentially covered as unit tests in this patch. Was there something about those tests that is not covering what you had in mind?","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"}],"nova/tests/unit/scheduler/test_request_filter.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"83b03e1e47a014c793eaf396933119413a2f1762","unresolved":false,"context_lines":[{"line_number":782,"context_line":"        reqspec \u003d objects.RequestSpec("},{"line_number":783,"context_line":"            flavor\u003dobjects.Flavor("},{"line_number":784,"context_line":"                extra_specs\u003d{"},{"line_number":785,"context_line":"                    \u0027hw:tpm_secret_security\u0027: \u0027bogus\u0027,"},{"line_number":786,"context_line":"                }),"},{"line_number":787,"context_line":"            image\u003dobjects.ImageMeta("},{"line_number":788,"context_line":"                properties\u003dobjects.ImageMetaProps()))"}],"source_content_type":"text/x-python","patch_set":21,"id":"9b9f59c2_38c0916a","line":785,"updated":"2025-10-13 21:40:29.000000000","message":"Oh yeah, I totally missed this. That\u0027s exactly what I was hoping for - something that could always be invalid. Mah bad :)","commit_id":"790be790989f3006a42130f4ac1aec3ae7acd01b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c6290acba715bf69c50c4812aa4069b3fd00e2d7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":26,"id":"60164a5f_88273b79","line":802,"updated":"2025-11-17 16:47:29.000000000","message":"I don\u0027t see a path where we check the tpm_model image property now given we now check get_vtpm_constraint()","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"1a087daf0e68de8e122f99a1ef24d09a47d0046a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":26,"id":"b92850a2_792488f6","line":802,"in_reply_to":"60164a5f_88273b79","updated":"2025-11-18 17:34:37.000000000","message":"Done","commit_id":"0f8f94f837c76ef0beab51725ba0006f7771f5b9"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"55a96e34d1615945e95c70a817d6b73b9e0cc0c3","unresolved":false,"context_lines":[{"line_number":773,"context_line":"                image\u003dobjects.ImageMeta("},{"line_number":774,"context_line":"                    properties\u003dobjects.ImageMetaProps(hw_tpm_model\u003d\u0027tpm-tis\u0027,"},{"line_number":775,"context_line":"                                                      hw_tpm_version\u003d\u00271.2\u0027)))"},{"line_number":776,"context_line":""},{"line_number":777,"context_line":"        self.assertEqual(set(), reqspec.root_required)"},{"line_number":778,"context_line":"        self.assertEqual(set(), reqspec.root_forbidden)"},{"line_number":779,"context_line":"        self.assertTrue("}],"source_content_type":"text/x-python","patch_set":27,"id":"da4aa1c6_9fe53042","line":776,"updated":"2025-11-19 11:33:20.000000000","message":"++, thanks !","commit_id":"ad1dd5e594a81c53f8e8c3c121d0f4a6c3bbb770"}],"nova/tests/unit/virt/test_hardware.py":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"89f48102945caf819515c0efe37c25c7c9780aa6","unresolved":false,"context_lines":[{"line_number":5973,"context_line":"        else:"},{"line_number":5974,"context_line":"            self.assertEqual("},{"line_number":5975,"context_line":"                expected,"},{"line_number":5976,"context_line":"                hw.get_tpm_secret_security_constraint(flavor, image_meta))"},{"line_number":5977,"context_line":""},{"line_number":5978,"context_line":""},{"line_number":5979,"context_line":"@ddt.ddt"}],"source_content_type":"text/x-python","patch_set":22,"id":"308425d0_f40e5688","line":5976,"updated":"2025-10-28 13:59:16.000000000","message":"++","commit_id":"b7d94dd4f59ea3b25125c8f0dafdf308496e84cc"}]}