)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4362a959d2670f8b9c23e2c925890d39461f35bc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a80a6b31_b089c2f3","updated":"2025-10-21 14:19:24.000000000","message":"I\u0027ve mentioned this elsewhere but I\u0027m mostly focusing on reviewing the implementation because the spec for this was so light on detail (which we found after looking at the actual code).","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"212e3bf2_f45d9798","updated":"2025-11-03 11:30:18.000000000","message":"this needs some modification based on the ptg dicussion but over all i think this is still valid directionally so +1","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"86de10a120995cba4e5e5889ee359eb8f9b419e7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6796d176_67d3b13f","updated":"2025-11-05 17:17:27.000000000","message":"yup, please just change what we discussed","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"22feb1818704e25889d620fc37224715ca321a2b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a0a5bb11_a28db690","updated":"2025-11-26 17:09:15.000000000","message":"I\u0027m +Wing this because of the deadline but I haven\u0027t read it. As I mentioned before, I\u0027m focusing my energy on the implementation and we\u0027re iterating there as necessary. So I\u0027ll approve the \"idea\" of this and we can circle back to revise this to match what we actually did later.","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"8fda3cd452b75f218f24439370f22a73d5eb9c90","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"f8d56fda_52e7333b","updated":"2025-11-17 13:48:59.000000000","message":"btw. I checked the differences between the two files by using Cursor and I was able to see all of the modifications by diff both of the files while I was also having a summary thanks to claude-4.5","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"1c0584bf_767f3b47","updated":"2025-11-17 13:47:06.000000000","message":"definitely +2, that\u0027s what we discussed on the PTG","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"}],"specs/2026.1/approved/vtpm-live-migration.rst":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0c21d5fa636fe4f554e48336852b2fb69a712ebc","unresolved":true,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"For simplicity, if neither ``hw_tpm_secret_security`` nor"},{"line_number":173,"context_line":"``hw:tpm_secret_security`` are set in the image properties or flavor extra"},{"line_number":174,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":175,"context_line":"policy."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":178,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1133d6a7_bb12a79d","line":175,"range":{"start_line":174,"start_character":7,"end_line":175,"end_character":7},"updated":"2025-09-29 23:50:03.000000000","message":"NOTE: During testing I have found that if we are going to default to `user` secret security if nothing was specified in the image or flavor, then it should probably not be choosable in `[libvirt]supported_tpm_secret_security` and should instead be hard-coded to always be included.\n\nThe reason I say this is because if nothing is specified for secret security policy in the image or flavor and the instance defaults to `user`, it would be stuck unable to migrate unless compute hosts are configured to include `user` in their `[libvirt]supported_tpm_secret_security`, which could easily be overlooked. Too easy to have a mismatch.\n\nBasically if `user` can be set automatically then it should be supported automatically, IMHO.","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0924c7b8517405a5a891409eab0421809293e3ec","unresolved":true,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"For simplicity, if neither ``hw_tpm_secret_security`` nor"},{"line_number":173,"context_line":"``hw:tpm_secret_security`` are set in the image properties or flavor extra"},{"line_number":174,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":175,"context_line":"policy."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":178,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bb86e776_5d90556e","line":175,"range":{"start_line":174,"start_character":7,"end_line":175,"end_character":7},"in_reply_to":"1133d6a7_bb12a79d","updated":"2025-10-29 22:50:25.000000000","message":"I thought of a scenario where it could be valid to let instances default to \u0027user\u0027 yet let deployers configure _without_ \u0027user\u0027 support on a compute host. They could want to do this if they want to disallow creation of new instances with legacy behavior (i.e. un-live-migratable instances).","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"For simplicity, if neither ``hw_tpm_secret_security`` nor"},{"line_number":173,"context_line":"``hw:tpm_secret_security`` are set in the image properties or flavor extra"},{"line_number":174,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":175,"context_line":"policy."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":178,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8b70d47c_093fbfdf","line":175,"range":{"start_line":174,"start_character":7,"end_line":175,"end_character":7},"in_reply_to":"bb86e776_5d90556e","updated":"2025-11-11 02:28:43.000000000","message":"Acknowledged (this comment is obsolete as of the latest implementation PS)","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0c21d5fa636fe4f554e48336852b2fb69a712ebc","unresolved":true,"context_lines":[{"line_number":258,"context_line":"service version bump have a value for ``image_hw_tpm_secret_security`` set in"},{"line_number":259,"context_line":"their ``system_metadata`` if requested explicitly by the user via the image"},{"line_number":260,"context_line":"property or extra spec, as described in the `\u003cProposed change_\u003e_` section."},{"line_number":261,"context_line":"Note that the key stashed in the ``system_metadata`` will be"},{"line_number":262,"context_line":"``image_hw_tpm_secret_security`` regardless of whether the specification came"},{"line_number":263,"context_line":"from the image property or the flavor extra spec."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Live migration of instances with vTPM will be blocked until the minimum"},{"line_number":266,"context_line":"service version of the deployment is the upgraded version. The cloud must be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"28ac8866_a491b010","line":263,"range":{"start_line":261,"start_character":0,"end_line":263,"end_character":49},"updated":"2025-09-29 23:50:03.000000000","message":"NOTE: During testing I have found this is problematic because it prevents a user from changing their TPM secret security policy via a resize. Because once `image_hw_tpm_secret_security` is set to something, it will conflict with any flavor containing a different `hw:tpm_secret_security`. A user could however change their policy with a rebuild to an image with different `hw_tpm_secret_security` set in the properties.\n\nMaybe this is what we want and that we want a user to be \"locked in\" to their TPM secret security except by way of a rebuild, but I have a feeling we shouldn\u0027t be that limiting.\n\nAnd if we aren\u0027t going to be that limiting, then we would need to use a different system metadata key for this that does not mimic an image property. Perhaps `vtpm_secret_security` to mirror the existing `vtpm_secret_uuid` system metadata key.","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b62350db5cff134d641ccd670e20b2f52e96d21d","unresolved":true,"context_lines":[{"line_number":258,"context_line":"service version bump have a value for ``image_hw_tpm_secret_security`` set in"},{"line_number":259,"context_line":"their ``system_metadata`` if requested explicitly by the user via the image"},{"line_number":260,"context_line":"property or extra spec, as described in the `\u003cProposed change_\u003e_` section."},{"line_number":261,"context_line":"Note that the key stashed in the ``system_metadata`` will be"},{"line_number":262,"context_line":"``image_hw_tpm_secret_security`` regardless of whether the specification came"},{"line_number":263,"context_line":"from the image property or the flavor extra spec."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Live migration of instances with vTPM will be blocked until the minimum"},{"line_number":266,"context_line":"service version of the deployment is the upgraded version. The cloud must be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7af23585_6873da62","line":263,"range":{"start_line":261,"start_character":0,"end_line":263,"end_character":49},"in_reply_to":"15c6518c_4710af0b","updated":"2025-10-01 00:15:29.000000000","message":"\u003e A user could however change their policy with a rebuild to an image with different hw_tpm_secret_security set in the properties.\n\nNeed to correct myself: rebuild is actually blocked at the API for vTPM instances, so we don\u0027t need to worry about rebuild scenarios.","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"524eb8a0efd4ca36379fa9bf11796e5addedb21d","unresolved":true,"context_lines":[{"line_number":258,"context_line":"service version bump have a value for ``image_hw_tpm_secret_security`` set in"},{"line_number":259,"context_line":"their ``system_metadata`` if requested explicitly by the user via the image"},{"line_number":260,"context_line":"property or extra spec, as described in the `\u003cProposed change_\u003e_` section."},{"line_number":261,"context_line":"Note that the key stashed in the ``system_metadata`` will be"},{"line_number":262,"context_line":"``image_hw_tpm_secret_security`` regardless of whether the specification came"},{"line_number":263,"context_line":"from the image property or the flavor extra spec."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Live migration of instances with vTPM will be blocked until the minimum"},{"line_number":266,"context_line":"service version of the deployment is the upgraded version. The cloud must be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"15c6518c_4710af0b","line":263,"range":{"start_line":261,"start_character":0,"end_line":263,"end_character":49},"in_reply_to":"28ac8866_a491b010","updated":"2025-09-30 15:40:00.000000000","message":"Adding that IIRC the reasoning for overloading the `image_hw_tpm_secret_security` sysmeta key was so that the user would be able to see their TPM secret security policy in the image properties [1] if it was not chosen by them i.e. it was defaulted by the previously proposed config option (has been removed from the proposal based on code review feedback).\n\nWith the re-proposal not including the config option, the default TPM secret security if nothing was specified in the image or flavor is `user`.\n\nGiven this change in design, I\u0027m not sure there is still any usefulness in overloading the `image_hw_tpm_secret_security` sysmeta key. My gut feeling in general is that ideally we should not overload the key, in part because overloading things ends up causing issues such as this one (with conflicting flavor/image despite no actual image being involved).\n\n[1] https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#microversion-2-98","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"979ce5a49cfb07743012d641f757d47157acef17","unresolved":false,"context_lines":[{"line_number":258,"context_line":"service version bump have a value for ``image_hw_tpm_secret_security`` set in"},{"line_number":259,"context_line":"their ``system_metadata`` if requested explicitly by the user via the image"},{"line_number":260,"context_line":"property or extra spec, as described in the `\u003cProposed change_\u003e_` section."},{"line_number":261,"context_line":"Note that the key stashed in the ``system_metadata`` will be"},{"line_number":262,"context_line":"``image_hw_tpm_secret_security`` regardless of whether the specification came"},{"line_number":263,"context_line":"from the image property or the flavor extra spec."},{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Live migration of instances with vTPM will be blocked until the minimum"},{"line_number":266,"context_line":"service version of the deployment is the upgraded version. The cloud must be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8cc2c745_a39c1c88","line":263,"range":{"start_line":261,"start_character":0,"end_line":263,"end_character":49},"in_reply_to":"7af23585_6873da62","updated":"2025-10-29 22:01:23.000000000","message":"Done","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0c21d5fa636fe4f554e48336852b2fb69a712ebc","unresolved":true,"context_lines":[{"line_number":334,"context_line":"Nova\u0027s `vTPM documentation"},{"line_number":335,"context_line":"\u003chttps://docs.openstack.org/nova/latest/admin/emulated-tpm.html\u003e`_ is updated"},{"line_number":336,"context_line":"to remove the live migration limitation and explain the usage of the"},{"line_number":337,"context_line":"``supported_tpm_secret_security`` and ``default_tpm_secret_security``"},{"line_number":338,"context_line":"configuration options, as well as the implications of all possible values. The"},{"line_number":339,"context_line":"expectation that vTPM state storage is not shared and that shared vTPM state"},{"line_number":340,"context_line":"storage live migration is untested is made explicit."}],"source_content_type":"text/x-rst","patch_set":1,"id":"d57e9527_6c543393","line":337,"range":{"start_line":337,"start_character":33,"end_line":337,"end_character":69},"updated":"2025-09-29 23:50:03.000000000","message":"Need to remove this.","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"979ce5a49cfb07743012d641f757d47157acef17","unresolved":false,"context_lines":[{"line_number":334,"context_line":"Nova\u0027s `vTPM documentation"},{"line_number":335,"context_line":"\u003chttps://docs.openstack.org/nova/latest/admin/emulated-tpm.html\u003e`_ is updated"},{"line_number":336,"context_line":"to remove the live migration limitation and explain the usage of the"},{"line_number":337,"context_line":"``supported_tpm_secret_security`` and ``default_tpm_secret_security``"},{"line_number":338,"context_line":"configuration options, as well as the implications of all possible values. The"},{"line_number":339,"context_line":"expectation that vTPM state storage is not shared and that shared vTPM state"},{"line_number":340,"context_line":"storage live migration is untested is made explicit."}],"source_content_type":"text/x-rst","patch_set":1,"id":"16ed3ec0_a7fe5b6f","line":337,"range":{"start_line":337,"start_character":33,"end_line":337,"end_character":69},"in_reply_to":"d57e9527_6c543393","updated":"2025-10-29 22:01:23.000000000","message":"Done","commit_id":"b09379d23dc6bb704fed23cecb6ed7e7c497a616"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":47,"context_line":"------------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"vTPM state storage is not the same as instance state storage. The latter can be"},{"line_number":50,"context_line":"configured to be shared, for example on NFS. The former is always non-shared."},{"line_number":51,"context_line":"Libvirt can be told where to store the vTPM state via the `source"},{"line_number":52,"context_line":"\u003chttps://libvirt.org/formatdomain.html#tpm-device\u003e`_ XML element, which Nova"},{"line_number":53,"context_line":"`does not support"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8ac51e08_bcce93da","line":50,"range":{"start_line":50,"start_character":44,"end_line":50,"end_character":77},"updated":"2025-11-03 11:30:18.000000000","message":"not to ratwhole on this point but that techncially not true\nlibvirt does actully support having teh tpm data on nfs however when it is on nfs which si not common it shoudl be handeled by libvirt/qemu and nova should not need to care. libvirt has special case handeling in this case wehre it wont nuke the tpm data when the domain is undefiend and it should also be smart enough to not try and copy it.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":47,"context_line":"------------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"vTPM state storage is not the same as instance state storage. The latter can be"},{"line_number":50,"context_line":"configured to be shared, for example on NFS. The former is always non-shared."},{"line_number":51,"context_line":"Libvirt can be told where to store the vTPM state via the `source"},{"line_number":52,"context_line":"\u003chttps://libvirt.org/formatdomain.html#tpm-device\u003e`_ XML element, which Nova"},{"line_number":53,"context_line":"`does not support"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4ea7afae_5da45a8d","line":50,"range":{"start_line":50,"start_character":44,"end_line":50,"end_character":77},"in_reply_to":"1245c3c7_f2fa7bef","updated":"2025-11-11 02:28:43.000000000","message":"Done","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":47,"context_line":"------------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"vTPM state storage is not the same as instance state storage. The latter can be"},{"line_number":50,"context_line":"configured to be shared, for example on NFS. The former is always non-shared."},{"line_number":51,"context_line":"Libvirt can be told where to store the vTPM state via the `source"},{"line_number":52,"context_line":"\u003chttps://libvirt.org/formatdomain.html#tpm-device\u003e`_ XML element, which Nova"},{"line_number":53,"context_line":"`does not support"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1245c3c7_f2fa7bef","line":50,"range":{"start_line":50,"start_character":44,"end_line":50,"end_character":77},"in_reply_to":"8ac51e08_bcce93da","updated":"2025-11-05 17:55:37.000000000","message":"Thanks for the correction, I will adjust this to say what you have just said.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"Thus, this spec requires vTPM state storage to be not shared, and declares live"},{"line_number":61,"context_line":"migration with shared vTPM state storage to be untested. This will be"},{"line_number":62,"context_line":"documented."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Libvirt support"},{"line_number":65,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1cfad752_32d88ede","line":62,"updated":"2025-11-03 11:30:18.000000000","message":"again we dont striclly need to requrie this but that is what we will be testing in ci so we can leave this as is.\n\nthis is more documenting what is tested to work rather then strictly speaking what is required since we are not going to enforce that the tpm dir is on local storage.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"Thus, this spec requires vTPM state storage to be not shared, and declares live"},{"line_number":61,"context_line":"migration with shared vTPM state storage to be untested. This will be"},{"line_number":62,"context_line":"documented."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Libvirt support"},{"line_number":65,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"27968bb8_3e830f61","line":62,"in_reply_to":"1cfad752_32d88ede","updated":"2025-11-05 17:55:37.000000000","message":"I\u0027ll update this too then.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":59,"context_line":""},{"line_number":60,"context_line":"Thus, this spec requires vTPM state storage to be not shared, and declares live"},{"line_number":61,"context_line":"migration with shared vTPM state storage to be untested. This will be"},{"line_number":62,"context_line":"documented."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Libvirt support"},{"line_number":65,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8b32370f_2bb46a75","line":62,"in_reply_to":"27968bb8_3e830f61","updated":"2025-11-11 02:28:43.000000000","message":"Done","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":73,"context_line":"since version 7.1.0."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Secret management"},{"line_number":78,"context_line":"-----------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"8928e4ba_ad2841cd","line":76,"updated":"2025-11-03 11:30:18.000000000","message":"note our current min libvirt version is 8.0.0 as of epoxy so this means we do not need to do min version checks when implementing this feature","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":73,"context_line":"since version 7.1.0."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Secret management"},{"line_number":78,"context_line":"-----------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"251944b2_ea2c59a9","line":76,"in_reply_to":"6cba32cc_fab829e0","updated":"2025-11-11 02:28:43.000000000","message":"Done","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":73,"context_line":"since version 7.1.0."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Therefore, this spec requires Libvirt 7.1.0."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Secret management"},{"line_number":78,"context_line":"-----------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"6cba32cc_fab829e0","line":76,"in_reply_to":"8928e4ba_ad2841cd","updated":"2025-11-05 17:55:37.000000000","message":"I\u0027ll add mention of that.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":145,"context_line":"     - This is the most secure option, as even the Nova service user and root"},{"line_number":146,"context_line":"       on the compute host cannot read the secret."},{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1db81661_af1e720a","line":148,"updated":"2025-11-03 11:30:18.000000000","message":"this is the current behavior today.\nim ok with keeping this exactly as it is today but i would also be ok\nwith allowign the compute agent to be able to start the vm if and only if the libvirt secret was still defiend in libvirt.\n\nso this woudl be a tiny tweak to nova ot not delete the secrete once the vm has been booted but we would still mark the secret so it cant be read back.\n\nwe woudl mark the secreate as persitent and private. by setting \n`ephemeral\u003d\u0027no\u0027 private\u003d\u0027yes`\nas show inthe libvirt vtpm example\nhttps://libvirt.org/formatsecret.html#usage-type-vtpm\n\ni think this could be done in this spec or as a bugfix or not at all.\n\ni.e. we coudl decide that fixing the host reboot case for vtpm is not a goal.\n\ni just want to raise this for consideration not as an objection to the current spec.\n\nthis woudl allow use to remove the sepcial casseing for vtpm as its the only secrete we currently delete after the vm starts.\nthis woudl bring vtpm into line with how we define the volume secrets.\ni personally belive this woudl be a good improvment.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":145,"context_line":"     - This is the most secure option, as even the Nova service user and root"},{"line_number":146,"context_line":"       on the compute host cannot read the secret."},{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe55320_f1a62e05","line":148,"in_reply_to":"1db81661_af1e720a","updated":"2025-11-05 17:55:37.000000000","message":"I\u0027m hesitant to change that, especially as part of this feature work. I don\u0027t know the history of why deletion of the secret after the guest is running is done or what the implications are if we don\u0027t do that (for the existing behavior). I had assumed there was some security reason for undefining it like that. I\u0027m also wary of changing existing expected behavior for normal un-live-migratable vTPM instances -- is there something users could potentially be disappointed about?\n\nI think a change like this should have been discussed at the PTG if we wanted to do that and I would rather not mix it with adding vTPM live migration here. The feature is already complicated enough as it is. It has missed 2 cycles so far and has been quite significantly simplified in design since then. I would like to please keep it as simple as possible.\n\nIf we want to change the secret undefining behavior, I think it should be a separate change and ideally I would want a PTG discussion to make sure there is no issue with changing existing behavior.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":true,"context_lines":[{"line_number":145,"context_line":"     - This is the most secure option, as even the Nova service user and root"},{"line_number":146,"context_line":"       on the compute host cannot read the secret."},{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"}],"source_content_type":"text/x-rst","patch_set":3,"id":"70cc27ff_2ad79c0e","line":148,"in_reply_to":"257fbbef_1ec6f377","updated":"2025-11-17 13:47:06.000000000","message":"I compare both merged spec and that one and fwiw, that\u0027s not changing, so I think that if we want to support that, this should be a follow-up spec in the next cycle as it would be a new behaviour.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2b344299f8dd9833d46b72ba86973f17ae3873a","unresolved":true,"context_lines":[{"line_number":145,"context_line":"     - This is the most secure option, as even the Nova service user and root"},{"line_number":146,"context_line":"       on the compute host cannot read the secret."},{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"}],"source_content_type":"text/x-rst","patch_set":3,"id":"257fbbef_1ec6f377","line":148,"in_reply_to":"ffe55320_f1a62e05","updated":"2025-11-05 20:20:13.000000000","message":"that fine by me.\ni htink orgianlly the inte was just to keep the secret defeidn for as short as possibel but im fine to revist this next cycle or whenever.\n\ni just wanted to raise this as a posiblity to make the resume_guests_on_host_reboot thing work in this mode.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":152,"context_line":"       not have access to the secret, but it can be accessed by users with"},{"line_number":153,"context_line":"       sufficient privileges on the compute host."}],"source_content_type":"text/x-rst","patch_set":3,"id":"71f498ab_313ba8e9","line":150,"updated":"2025-11-03 11:30:18.000000000","message":"if we were to adopt my suggestion of using `ephemeral\u003d\u0027no\u0027 private\u003d\u0027yes\u0027` for user\nthe deta heer is `ephemeral\u003d\u0027no\u0027 private\u003d\u0027no\u0027` i.e. host mode allows nova to read it back but in user mode only libvirt can do that.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":true,"context_lines":[{"line_number":147,"context_line":"     - The instance is immovable and cannot be restarted by Nova in the event"},{"line_number":148,"context_line":"       of a compute host crash or reboot."},{"line_number":149,"context_line":"   * - ``host``"},{"line_number":150,"context_line":"     - The Libvirt secret is persistent and retrievable."},{"line_number":151,"context_line":"     - This is \"medium\" security. API-level admins and the Nova service user do"},{"line_number":152,"context_line":"       not have access to the secret, but it can be accessed by users with"},{"line_number":153,"context_line":"       sufficient privileges on the compute host."}],"source_content_type":"text/x-rst","patch_set":3,"id":"2a654eb5_27a02087","line":150,"in_reply_to":"71f498ab_313ba8e9","updated":"2025-11-17 13:47:06.000000000","message":"should be discussed in a follow-up spec then.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":157,"context_line":"       or similar is assumed. The instance can also be restarted by Nova in the"},{"line_number":158,"context_line":"       event of a compute host crash or reboot for the exact same reason."},{"line_number":159,"context_line":"   * - ``deployment``"},{"line_number":160,"context_line":"     - The Nova service user owns the Barbican secret."},{"line_number":161,"context_line":"     - This is the least secure but most flexible option."},{"line_number":162,"context_line":"     - The instance can be live migrated because Nova can download the secret"},{"line_number":163,"context_line":"       from Barbican and define it in Libvirt on the destination host. The"}],"source_content_type":"text/x-rst","patch_set":3,"id":"df744e1a_f1b0151b","line":160,"updated":"2025-11-03 11:30:18.000000000","message":"this mode could use `ephemeral\u003d\u0027no\u0027 private\u003d\u0027yes\u0027` or `ephemeral\u003d\u0027no\u0027 private\u003d\u0027no\u0027`  or even `ephemeral\u003d\u0027yes\u0027 private\u003d\u0027yes\u0027` as in all cause nova can retive the key form barbican to implemtne the host reboot case so its not dependent on libvirt secrete retrival to function.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":true,"context_lines":[{"line_number":157,"context_line":"       or similar is assumed. The instance can also be restarted by Nova in the"},{"line_number":158,"context_line":"       event of a compute host crash or reboot for the exact same reason."},{"line_number":159,"context_line":"   * - ``deployment``"},{"line_number":160,"context_line":"     - The Nova service user owns the Barbican secret."},{"line_number":161,"context_line":"     - This is the least secure but most flexible option."},{"line_number":162,"context_line":"     - The instance can be live migrated because Nova can download the secret"},{"line_number":163,"context_line":"       from Barbican and define it in Libvirt on the destination host. The"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1b379421_70418d00","line":160,"in_reply_to":"07434428_96d032c2","updated":"2025-11-17 13:47:06.000000000","message":"nothing was changed for this deployment section (just melanie modified the lists) so I think this is not a new problem.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":157,"context_line":"       or similar is assumed. The instance can also be restarted by Nova in the"},{"line_number":158,"context_line":"       event of a compute host crash or reboot for the exact same reason."},{"line_number":159,"context_line":"   * - ``deployment``"},{"line_number":160,"context_line":"     - The Nova service user owns the Barbican secret."},{"line_number":161,"context_line":"     - This is the least secure but most flexible option."},{"line_number":162,"context_line":"     - The instance can be live migrated because Nova can download the secret"},{"line_number":163,"context_line":"       from Barbican and define it in Libvirt on the destination host. The"}],"source_content_type":"text/x-rst","patch_set":3,"id":"07434428_96d032c2","line":160,"in_reply_to":"df744e1a_f1b0151b","updated":"2025-11-05 17:55:37.000000000","message":"I don\u0027t understand what you are saying here. The currently proposed code for \u0027deployment\u0027 mode uses ephemeral\u003dyes and private\u003dyes same as \u0027user\u0027 -- the only difference is Barbican secret ownership. I think this is intended in that the actual goal is to allow admin to live migrate users\u0027 instances. The \u0027deployment\u0027 mode keeps all of the same handling of the secret as far as undefining it after the guest is running, libvirt not storing it anywhere, etc while enabling an admin user to live migrate a different user\u0027s instance.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":165,"context_line":"       crash or reboot for the exact same reason."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Users are able to choose what level they require on their instance by selecting"},{"line_number":168,"context_line":"a flavor that sets the new ``hw:tpm_secret_security`` flavor extra spec. The"},{"line_number":169,"context_line":"security policy will be stored in the instance system metadata under a new key"},{"line_number":170,"context_line":"``vtpm_secret_security``. This is named to be consistent with the already"},{"line_number":171,"context_line":"existing ``vtpm_secret_uuid`` system metadata key. If no specific policy was"},{"line_number":172,"context_line":"indicated in the flavor extra spec, the instance will default to the ``user``"},{"line_number":173,"context_line":"policy, which is the same as legacy behavior."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The ``vtpm_secret_security`` system metadata key is needed so that we can"},{"line_number":176,"context_line":"identify new instances that are defaulting to legacy behavior. One way this"},{"line_number":177,"context_line":"could be important is if the deployer does not want to support further legacy"},{"line_number":178,"context_line":"behavior for vTPM and would like to exclude the ``user`` policy from their"},{"line_number":179,"context_line":"``[libvirt]supported_tpm_secret_security`` list. Doing so would prevent"},{"line_number":180,"context_line":"creation of new servers with legacy behavior because they would not be able to"},{"line_number":181,"context_line":"schedule if no compute hosts are supporting ``user``."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"For simplicity, if ``hw:tpm_secret_security`` is not set in the flavor extra"},{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8a8ce055_9dfdc306","line":181,"range":{"start_line":168,"start_character":73,"end_line":181,"end_character":53},"updated":"2025-11-03 11:30:18.000000000","message":"so this all needs to be revised based on the PTG dicussion. the tldr is we agreed to remvoe the ablity to set this via the image, as a result we will not ahve any key in the instance_system_metadata table.\n\nnova will just read the policy form the flavor. if its not set in the flavor vai \nhw:tpm_secret_security it will use the user policy.\n\nthis will allow user to opt into and change the policy via a simple resize.\n\nthat also mean we do not need to have any conflict detection logic in the api for resize as there is only one source of the policy, the flavor.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2b344299f8dd9833d46b72ba86973f17ae3873a","unresolved":true,"context_lines":[{"line_number":165,"context_line":"       crash or reboot for the exact same reason."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Users are able to choose what level they require on their instance by selecting"},{"line_number":168,"context_line":"a flavor that sets the new ``hw:tpm_secret_security`` flavor extra spec. The"},{"line_number":169,"context_line":"security policy will be stored in the instance system metadata under a new key"},{"line_number":170,"context_line":"``vtpm_secret_security``. This is named to be consistent with the already"},{"line_number":171,"context_line":"existing ``vtpm_secret_uuid`` system metadata key. If no specific policy was"},{"line_number":172,"context_line":"indicated in the flavor extra spec, the instance will default to the ``user``"},{"line_number":173,"context_line":"policy, which is the same as legacy behavior."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The ``vtpm_secret_security`` system metadata key is needed so that we can"},{"line_number":176,"context_line":"identify new instances that are defaulting to legacy behavior. One way this"},{"line_number":177,"context_line":"could be important is if the deployer does not want to support further legacy"},{"line_number":178,"context_line":"behavior for vTPM and would like to exclude the ``user`` policy from their"},{"line_number":179,"context_line":"``[libvirt]supported_tpm_secret_security`` list. Doing so would prevent"},{"line_number":180,"context_line":"creation of new servers with legacy behavior because they would not be able to"},{"line_number":181,"context_line":"schedule if no compute hosts are supporting ``user``."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"For simplicity, if ``hw:tpm_secret_security`` is not set in the flavor extra"},{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a64231a8_044e33af","line":181,"range":{"start_line":168,"start_character":73,"end_line":181,"end_character":53},"in_reply_to":"205b5486_03063e1a","updated":"2025-11-05 20:20:13.000000000","message":"you cna do this with compute capablities and or compute capabilty traits yes\n\nso i dont think its required unless i missed something.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":165,"context_line":"       crash or reboot for the exact same reason."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Users are able to choose what level they require on their instance by selecting"},{"line_number":168,"context_line":"a flavor that sets the new ``hw:tpm_secret_security`` flavor extra spec. The"},{"line_number":169,"context_line":"security policy will be stored in the instance system metadata under a new key"},{"line_number":170,"context_line":"``vtpm_secret_security``. This is named to be consistent with the already"},{"line_number":171,"context_line":"existing ``vtpm_secret_uuid`` system metadata key. If no specific policy was"},{"line_number":172,"context_line":"indicated in the flavor extra spec, the instance will default to the ``user``"},{"line_number":173,"context_line":"policy, which is the same as legacy behavior."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The ``vtpm_secret_security`` system metadata key is needed so that we can"},{"line_number":176,"context_line":"identify new instances that are defaulting to legacy behavior. One way this"},{"line_number":177,"context_line":"could be important is if the deployer does not want to support further legacy"},{"line_number":178,"context_line":"behavior for vTPM and would like to exclude the ``user`` policy from their"},{"line_number":179,"context_line":"``[libvirt]supported_tpm_secret_security`` list. Doing so would prevent"},{"line_number":180,"context_line":"creation of new servers with legacy behavior because they would not be able to"},{"line_number":181,"context_line":"schedule if no compute hosts are supporting ``user``."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"For simplicity, if ``hw:tpm_secret_security`` is not set in the flavor extra"},{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"}],"source_content_type":"text/x-rst","patch_set":3,"id":"205b5486_03063e1a","line":181,"range":{"start_line":168,"start_character":73,"end_line":181,"end_character":53},"in_reply_to":"8a8ce055_9dfdc306","updated":"2025-11-05 17:55:37.000000000","message":"I had been thinking that we still need a system metadata key in order to prevent scheduling of legacy vTPM servers if an operator does not want to allow them. And I was thinking this because of the scheduler request filter logic that adds the \u0027USER\u0027 trait if secret security \u003d\u003d \u0027user\u0027. That we could stamp new default instances with \u0027user\u0027 in the system metadata so that we will add the \u0027USER\u0027 required trait when scheduling.\n\nThinking about it more because of your comment, I guess it\u0027s not necessary because I could instead change the request filter logic to also add the \u0027USER\u0027 trait if the instance has vTPM but no security mode specified in the flavor. That would achieve the same thing unless I\u0027m missing something. I\u0027ll try to make that change and see if I run into any problems.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":165,"context_line":"       crash or reboot for the exact same reason."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Users are able to choose what level they require on their instance by selecting"},{"line_number":168,"context_line":"a flavor that sets the new ``hw:tpm_secret_security`` flavor extra spec. The"},{"line_number":169,"context_line":"security policy will be stored in the instance system metadata under a new key"},{"line_number":170,"context_line":"``vtpm_secret_security``. This is named to be consistent with the already"},{"line_number":171,"context_line":"existing ``vtpm_secret_uuid`` system metadata key. If no specific policy was"},{"line_number":172,"context_line":"indicated in the flavor extra spec, the instance will default to the ``user``"},{"line_number":173,"context_line":"policy, which is the same as legacy behavior."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"The ``vtpm_secret_security`` system metadata key is needed so that we can"},{"line_number":176,"context_line":"identify new instances that are defaulting to legacy behavior. One way this"},{"line_number":177,"context_line":"could be important is if the deployer does not want to support further legacy"},{"line_number":178,"context_line":"behavior for vTPM and would like to exclude the ``user`` policy from their"},{"line_number":179,"context_line":"``[libvirt]supported_tpm_secret_security`` list. Doing so would prevent"},{"line_number":180,"context_line":"creation of new servers with legacy behavior because they would not be able to"},{"line_number":181,"context_line":"schedule if no compute hosts are supporting ``user``."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"For simplicity, if ``hw:tpm_secret_security`` is not set in the flavor extra"},{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bd8dccce_b92747dd","line":181,"range":{"start_line":168,"start_character":73,"end_line":181,"end_character":53},"in_reply_to":"a64231a8_044e33af","updated":"2025-11-11 02:28:43.000000000","message":"Done","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":185,"context_line":"policy."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"A new image property is intentionally not provided because server rebuild is"},{"line_number":188,"context_line":"blocked in the API. If a user were to create a server with a given TPM secret"},{"line_number":189,"context_line":"security policy via an image property, that policy would become locked-in and"},{"line_number":190,"context_line":"unable to be changed. The user would not be able to change the image property"},{"line_number":191,"context_line":"because they would not be able to rebuild, and they would not be able to resize"},{"line_number":192,"context_line":"to a different TPM secret security policy because the image property and flavor"},{"line_number":193,"context_line":"extra spec would conflict and fail with HTTP 409."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":196,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"17368cbd_b035b168","line":193,"range":{"start_line":187,"start_character":0,"end_line":193,"end_character":49},"updated":"2025-11-03 11:30:18.000000000","message":"this can now be deleted","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2b344299f8dd9833d46b72ba86973f17ae3873a","unresolved":true,"context_lines":[{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":185,"context_line":"policy."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"A new image property is intentionally not provided because server rebuild is"},{"line_number":188,"context_line":"blocked in the API. If a user were to create a server with a given TPM secret"},{"line_number":189,"context_line":"security policy via an image property, that policy would become locked-in and"},{"line_number":190,"context_line":"unable to be changed. The user would not be able to change the image property"},{"line_number":191,"context_line":"because they would not be able to rebuild, and they would not be able to resize"},{"line_number":192,"context_line":"to a different TPM secret security policy because the image property and flavor"},{"line_number":193,"context_line":"extra spec would conflict and fail with HTTP 409."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":196,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5e487f4c_86b65f14","line":193,"range":{"start_line":187,"start_character":0,"end_line":193,"end_character":49},"in_reply_to":"0ef1f42c_dd8abb9d","updated":"2025-11-05 20:20:13.000000000","message":"oh yep i read that too quickly.\n\ni guess its ok here. or in the alternitive either works for me on re reading it.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":185,"context_line":"policy."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"A new image property is intentionally not provided because server rebuild is"},{"line_number":188,"context_line":"blocked in the API. If a user were to create a server with a given TPM secret"},{"line_number":189,"context_line":"security policy via an image property, that policy would become locked-in and"},{"line_number":190,"context_line":"unable to be changed. The user would not be able to change the image property"},{"line_number":191,"context_line":"because they would not be able to rebuild, and they would not be able to resize"},{"line_number":192,"context_line":"to a different TPM secret security policy because the image property and flavor"},{"line_number":193,"context_line":"extra spec would conflict and fail with HTTP 409."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":196,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0ef1f42c_dd8abb9d","line":193,"range":{"start_line":187,"start_character":0,"end_line":193,"end_character":49},"in_reply_to":"17368cbd_b035b168","updated":"2025-11-05 17:55:37.000000000","message":"No, this is explaining why we are not providing an image property. Otherwise this spec says \"we are not providing one\" with no explanation as to why. I think it should be explained in the spec so that we don\u0027t have to keep answering separately, \"why is image property not allowed?\" in the future.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":184,"context_line":"specs, an instance with vTPM will default to the ``user`` TPM secret security"},{"line_number":185,"context_line":"policy."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"A new image property is intentionally not provided because server rebuild is"},{"line_number":188,"context_line":"blocked in the API. If a user were to create a server with a given TPM secret"},{"line_number":189,"context_line":"security policy via an image property, that policy would become locked-in and"},{"line_number":190,"context_line":"unable to be changed. The user would not be able to change the image property"},{"line_number":191,"context_line":"because they would not be able to rebuild, and they would not be able to resize"},{"line_number":192,"context_line":"to a different TPM secret security policy because the image property and flavor"},{"line_number":193,"context_line":"extra spec would conflict and fail with HTTP 409."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":196,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a44df836_8a81fa1d","line":193,"range":{"start_line":187,"start_character":0,"end_line":193,"end_character":49},"in_reply_to":"5e487f4c_86b65f14","updated":"2025-11-11 02:28:43.000000000","message":"Acknowledged","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6e160d686fffbd55484c5580fe8c2f93f724fc81","unresolved":true,"context_lines":[{"line_number":216,"context_line":"This is the only version of this spec that covers the essentials: users of new"},{"line_number":217,"context_line":"instances can choose the security level that they require, and operators can"},{"line_number":218,"context_line":"choose which security levels they are willing to support given the limitations"},{"line_number":219,"context_line":"imposed by higher security levels."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Data model impact"},{"line_number":222,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d1ca3966_8d900b1e","line":219,"updated":"2025-11-03 11:30:18.000000000","message":"lets add the option of supproting this in the image as well here but we dont need to go into detail just say that supproting it in the image cause probelm wiht changing the policy in the future via resize or something like that","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"c300aeab75ecadc0abe70bd497bce178ca1e5938","unresolved":false,"context_lines":[{"line_number":216,"context_line":"This is the only version of this spec that covers the essentials: users of new"},{"line_number":217,"context_line":"instances can choose the security level that they require, and operators can"},{"line_number":218,"context_line":"choose which security levels they are willing to support given the limitations"},{"line_number":219,"context_line":"imposed by higher security levels."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Data model impact"},{"line_number":222,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b4f50fcc_31829716","line":219,"in_reply_to":"3c8cf849_e3f34b82","updated":"2025-11-11 02:28:43.000000000","message":"Done","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5f07cd237c06530ce3e3e231c815f5d9d9165bd7","unresolved":true,"context_lines":[{"line_number":216,"context_line":"This is the only version of this spec that covers the essentials: users of new"},{"line_number":217,"context_line":"instances can choose the security level that they require, and operators can"},{"line_number":218,"context_line":"choose which security levels they are willing to support given the limitations"},{"line_number":219,"context_line":"imposed by higher security levels."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Data model impact"},{"line_number":222,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3c8cf849_e3f34b82","line":219,"in_reply_to":"d1ca3966_8d900b1e","updated":"2025-11-05 17:55:37.000000000","message":"OK, I can mention the image property here too.","commit_id":"2d08ab829cff5c041a4b274877fe0172cc807890"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[{"line_number":181,"context_line":"unable to be changed. The user would not be able to change the image property"},{"line_number":182,"context_line":"because they would not be able to rebuild, and they would not be able to resize"},{"line_number":183,"context_line":"to a different TPM secret security policy because the image property and flavor"},{"line_number":184,"context_line":"extra spec would conflict and fail with HTTP 409."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Operators are able to specify what level they support by using the new"},{"line_number":187,"context_line":"``[libvirt]supported_tpm_secret_security`` config option. This is a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"21349177_cc50aa24","line":184,"updated":"2025-11-17 13:47:06.000000000","message":"I\u0027m okay with the new section above (removing the Image Property Support)","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[{"line_number":188,"context_line":"per compute host list option that can take the value of one or more of the"},{"line_number":189,"context_line":"security levels from the previous table. Its default value is all three levels."},{"line_number":190,"context_line":"These values are exposed as driver capability traits. The"},{"line_number":191,"context_line":"``hw:tpm_secret_security`` flavor extra spec is translated to a required trait"},{"line_number":192,"context_line":"to match the driver capabilities."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"The behavior of an instance during live migration is defined by its persisted"}],"source_content_type":"text/x-rst","patch_set":4,"id":"15ce0669_079cc67b","line":191,"range":{"start_line":191,"start_character":26,"end_line":191,"end_character":27},"updated":"2025-11-17 13:47:06.000000000","message":"noted the change ;)","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[{"line_number":221,"context_line":"If we would like to support image property in the future, we could possibly do"},{"line_number":222,"context_line":"it if we could add the ability to rebuild vTPM instances at the same time. It"},{"line_number":223,"context_line":"is not yet known if there are any technical limitations that prevent the"},{"line_number":224,"context_line":"possibility of implementing rebuild, but we could certainly investigate."},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"Data model impact"},{"line_number":227,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"a6c4b0be_170a8af4","line":224,"updated":"2025-11-17 13:47:06.000000000","message":"++","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[{"line_number":226,"context_line":"Data model impact"},{"line_number":227,"context_line":"-----------------"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"None."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"REST API impact"},{"line_number":232,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"01156c5d_ee603ea1","line":229,"updated":"2025-11-17 13:47:06.000000000","message":"\\o/","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":false,"context_lines":[{"line_number":292,"context_line":"``hw:tpm_secret_security`` extra spec set to ``host`` or ``deployment``."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Automatic migration of pre-existing instances into TPM secret security"},{"line_number":295,"context_line":"policies could be discussed and considered as future work."},{"line_number":296,"context_line":""},{"line_number":297,"context_line":"Implementation"},{"line_number":298,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7606c5b3_0a95bc80","line":295,"updated":"2025-11-17 13:47:06.000000000","message":"++, the upgrade is now simplier","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2f7f28403d929f5fc70f1134d7d2c63e17141aa9","unresolved":true,"context_lines":[{"line_number":374,"context_line":"   * - 2026.1 Gazpacho"},{"line_number":375,"context_line":"     - Re-proposed"},{"line_number":376,"context_line":"   * - 2025.2 Flamingo"},{"line_number":377,"context_line":"     - Re-proposed"},{"line_number":378,"context_line":"   * - 2025.1 Epoxy"},{"line_number":379,"context_line":"     - Introduced"}],"source_content_type":"text/x-rst","patch_set":4,"id":"38a4acc6_481ced29","line":377,"range":{"start_line":377,"start_character":7,"end_line":377,"end_character":18},"updated":"2025-11-17 13:47:06.000000000","message":"nit: Well, it was approved","commit_id":"d9e9ae54bf526949d834851fdcf32ee0aaf042ca"}]}