)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"be9b29aded30903670fb7d713d390102f61b9b17","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"89ae20c4_3c5b44dd","updated":"2026-06-15 23:23:25.000000000","message":"i need to think about this more","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"14918ce0_0b417b4f","updated":"2026-07-13 15:29:46.000000000","message":"Direction looks good to me. I have a question about the location of the driver downcall.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"5764c8c2fccc55f73c9b50eed3bc5a9257d65573","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"15880747_a4a2dbb9","updated":"2026-07-07 16:41:50.000000000","message":"I think the only potential issue in this patch is the obvious abandonment of trying to treat these validations as driver-universal as though other drivers could implement vTPM or pinning. I feel like I would want to run this by the rest of the team for a sanity check ... make sure no one is strongly opposed to this idea.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"48f480f14ada4e311757f9be94311bde8b5107da","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f4ec5c7c_18a59b07","updated":"2026-07-06 17:05:18.000000000","message":"The idea and change looks good to me. Honestly I was surprised when I saw these checks were implemented in compute layer, and pushing it to the driver looks it much cleaner.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2639c9bc886b12a4a3e84ee33bc509a4015db6d3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"4491b953_856d9ce8","updated":"2026-07-06 12:51:23.000000000","message":"recheck flaky test","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7670b35ba60c81f7a1826338a2324ce13282779f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"95a06002_996f61dd","in_reply_to":"15880747_a4a2dbb9","updated":"2026-07-07 17:05:02.000000000","message":"well it does not perclude other drivers supporting vTPM or pinning however none fo them do today\n\nthey would either need to add there onw version of the check in there own process_instances_at_startup implementation or optionally factor out the check in to hardware.py or a similar shared module under /nova/virt if that made sesne to share across drivers. they could even be helper method on the base driver class.\nfor now these are from my perspective livbirt specific so i have not tried to generalise them.\n\nso its correct that we woudl no longner be treating these check as driver neutral but in reality the never were given no other driver supprot these features.\n\n@gibizer@gmail.com @sbauza@redhat.com what do you think?\n\ni would prefer to make this change and then have the sev-snp startup check be invoked form libvirt process_instances_at_startup again so that we do not check all vmware/ironic instance for this when the compute agent restarts.\n\nextending the virt driver interface with process_instances_at_startup seams like a logical evolution fo the interface to me expecily since we are moving all mutation fo the interface after the compute stable uuid check has been completed.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"3bcb44e98a115a3d7d2068f34cf6eea6ec14adf1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9a2f3af7_58c912ff","in_reply_to":"2195e634_4abf8ea4","updated":"2026-07-13 15:35:32.000000000","message":"\u003e What I was thinking with my comments on PS1 was that if there is a way for the libvirt driver to more intelligently report supports_vtpm in self.capabilities (do more than just check CONF.libvirt.swtpm_enabled), then we would have compute manager simply use that to determine whether to do validations for vTPM and other drivers like Ironic would just skip it. I wasn\u0027t imagining moving every single thing into the libvirt driver.\n\nI feel that eventually we will end up creating a complicated interface between the driver and the manager so that the manager learns what kind of generic check it needs to do based on the state of the driver. Instead of just delegating the check to the driver blindly. So I apply the https://martinfowler.com/bliki/TellDontAsk.html rule here.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7790963b4b5416e10e0ef6f159913fa89a45df4","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2195e634_4abf8ea4","in_reply_to":"8e7e33e9_6e2c1756","updated":"2026-07-08 11:27:28.000000000","message":"by the way the vtpm check is already more complicate then jsut checkign the config option its just not apprent form lookign at the code. \n\n\nthe version i have in this patch is intentioally not repeating the other checks already done by the libvirt driver.\n\nin the libvirt driver init_host\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L910\nthere is a call too _check_vtpm_support\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1151-L1206\n\nthat checks if the hsot is capable fo supproting vtpm and that runs before the new check and make sure you have not enabled vtpm on a host that cant support it.\nwe are not doing the instnace level checks there today because init_host is not ment to use non locla info i.e. db lookups to get the instances to validate them.\n\nwe set this form the config becasue we know that we will fail in init host if we cant supprot it\n\n \"supports_vtpm\": CONF.libvirt.swtpm_enabled,\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L467\n\nwe coudl have _check_vtpm_support return a bool and use ti there\nbut we dont have the instance list so we cant detect if you disabled vtpm in a generic way.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"708f58361bcf4108cd09d015f7f8d8a3fe08570e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"913e38f9_51fa7ddd","in_reply_to":"8eaa0b33_4022b71b","updated":"2026-07-07 19:52:32.000000000","message":"What I was thinking with my comments on PS1 was that if there is a way for the libvirt driver to more intelligently report `supports_vtpm` in `self.capabilities` (do more than just check CONF.libvirt.swtpm_enabled), then we would have compute manager simply use that to determine whether to do validations for vTPM and other drivers like Ironic would just skip it. I wasn\u0027t imagining moving every single thing into the libvirt driver.\n\nGenerally with driver features there is some attempt made to make the interface common across drivers and each driver opts in to provide their own implementation. If there is no meaningful validation that can happen at the compute manager level, then I guess there is no point in doing it there but it does make me wonder then if there should be something at nova.virt.driver such as `validate_vtpm_configuration` if each driver is expected to provide their own custom code.\n\nI\u0027m just thinking aloud here and interested to know their thoughts.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bf5dca903edb401701d4104d963526b018a58bfe","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8e7e33e9_6e2c1756","in_reply_to":"913e38f9_51fa7ddd","updated":"2026-07-08 11:14:04.000000000","message":"supports_* capablity traits were ment to signal if the driver supprot a capabltiy but we overloaded it to allso carry if its configured in the vtpm case\n\nthat ment  the generic theck for \"does a server request vtpm\" need to be written to validate all instance when a driver say supports_vtpm\u003dfalse ...\n\nthe reaso for that is that check is tryign to catch the case wehre you had swtpm enable and then disabled it when vms on the host were using it.\n\na way to fix that is to just say swtpm is not a hard depency and remove the ablity to turn this off for the libvirt driver. at the time it was intoduce swtpm was not widely packaged on all suprotd distros but that is nolonger the case so that is something we coudl consider.\n\ni dont really like the idea of building may side effect api where we add a capablity that is resally a driver specific feature flag that we then write \"generic\" check for in the compute manger.\n\nif we want to share semi generic driver specific check i woudl perf to do it by addign the checks in to the base driver and have the base driver look at the flag rahter then breaking the encaplustion bonary between the compute manage and driver layer.\n\nthese existing checks were crossing that bondary and leaking info into the comptue manager that really shoudl have been at the driver layer IMO\n\nso im not agains thavign reusable feature check at the driver level that are written to portable  \n\nbut i dont want us to need to have `supports_vtpm` and `vtpm_enabled` driver capabliteis which we would need in this case. that the downstream change that JayF and co did for this internally.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"48cac42f7a036c46b5605c9b3f308334bf9cc472","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8eaa0b33_4022b71b","in_reply_to":"95a06002_996f61dd","updated":"2026-07-07 17:06:41.000000000","message":"added gibi/sylvain becasue we were discussing the sev-snp start up checsk which to me are also libvirt specific and shoudl not be implmetned in the compute manger\n\nhttps://review.opendev.org/c/openstack/nova/+/994342/11/nova/compute/manager.py#1174","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0758fcefa60b0811c115d59ce9ef5044ff02ed30","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a369c3e9_296a4f33","in_reply_to":"9a2f3af7_58c912ff","updated":"2026-07-14 02:29:58.000000000","message":"I think part of the reason I feel kind of confused by these concepts in general is because when I worked on vTPM live migration, I actually had to move things _out_ of the driver and into nova/vtpm.py or compute manager during code review because I had put non-driver specific things in the driver initially.\n\nSo I\u0027m not sure how to feel about this. And maybe it\u0027s different than the things I had to move -- I dunno. I could personally benefit a general design/architecture doc guide for how these things should be organized because currently I don\u0027t understand it.\n\nNone of what I say is to try to block this, to be clear. I just don\u0027t think I have enough understanding or knowledge here to review this properly. Thanks for trying to explain it though.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e06d2ebcccca80ce6cb48c6a8ff6a0da9372b96e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ed86cfec_5649e56a","in_reply_to":"a369c3e9_296a4f33","updated":"2026-07-14 08:19:19.000000000","message":"I understand the frustration. We are not consistent at all about our architectural messaging but I don\u0027t know how to fix that.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5abc5581b5bf84123b8485e23491e59b6f6c7665","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"fb868e87_36534e20","in_reply_to":"ed86cfec_5649e56a","updated":"2026-07-14 12:34:24.000000000","message":"my approach to this is if its actually has no driver dependency at all or if its implemented in more then 1 driver the same way it can be done in the manger.\n\npart of the vtpm migration code likely shoudl be in the manager and the rest purely in the libvirt driver.\n\nthe secret creation in https://github.com/openstack/nova/blob/master/nova/vtpm.py is driver independent as that is just interacting with our key store.\n\nthe stable compute uuid file is similar.\n\nthe pci tracker or resource tracker are also again similer in that they handle normalised data structure which each of the driver construct form there driver specific view.\n\n\nany time we need to exented the driver interface with a new method to make a deciosn however that to me is a signal that we are leaking driver spciric behvior into the generic layer.\n\nmy hope with this is we are providing a singel hook point that allow the compute manager to remain generic while the driver sepcific logic can stay in the driver.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"107659beca882146d058925613ce62df9b2a8d38","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"147c7fbc_6ca31549","in_reply_to":"fb868e87_36534e20","updated":"2026-07-15 20:51:46.000000000","message":"Thanks ... FWIW I was not frustrated, but rather having trouble understanding the delineations and feeling unconfident about voting about it.\n\nYour points make sense. IIRC there were other additional requests to move some (existing) vTPM code from driver to compute manager as part of vTPM live migration review but the scope was already large so we left some of it alone.\n\nI think the most convincing point is the potentially endless additions of specialized virt interface methods when we could instead provide one hook for all driver-specific checks or processes. And each driver keep theirs as small as possible, given that there might be a temptation to overload it and forget to do common things in the compute manager. The tradeoff is that we\u0027ll need to be mindful during reviews that truly common logic stays in the manager rather than getting pulled into driver overrides.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"107659beca882146d058925613ce62df9b2a8d38","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"0e6ec1ed_dc388f27","updated":"2026-07-15 20:51:46.000000000","message":"Thanks for the discussion here and the patience. I think I am OK to go with this now -- it is a tradeoff but a reasonable one.","commit_id":"870d301254c666b25c6f282fb205ccfa8908a135"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"63e44d3373e5690681bffff40360abd6ae6c7fce","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"e7c1868f_05c83a16","updated":"2026-07-15 16:09:37.000000000","message":"recheck nova-alt-configuration is fixed.\n\nThis looks good to me.","commit_id":"870d301254c666b25c6f282fb205ccfa8908a135"}],"nova/compute/manager.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6a8b0d2c0b3567c089820e0d54f507c24cb942d1","unresolved":true,"context_lines":[{"line_number":1759,"context_line":"                    \u0027number of disk devices.\u0027)"},{"line_number":1760,"context_line":"            raise exception.InvalidConfiguration(msg)"},{"line_number":1761,"context_line":""},{"line_number":1762,"context_line":"        self.driver.init_host(host\u003dself.host)"},{"line_number":1763,"context_line":""},{"line_number":1764,"context_line":"        if service_ref:"},{"line_number":1765,"context_line":"            # If we are an existing service, check to see if we need"}],"source_content_type":"text/x-python","patch_set":1,"id":"445b3556_183f7f78","side":"PARENT","line":1762,"updated":"2026-05-28 19:38:30.000000000","message":"it would be nice if we could pass in the instances here since at lest the libivrt driver is already getting all the instnace for the currnet host so that it can register the image metadata defautls.\n\ni am also thinking that it would be preferbael to do the comptue host rename check before we call this for a similar reason.\n\nit would be better to not do any db modifcation on instance object before that validatrion.\n\nthis is out os scope fo this bug to some degree but it might be worth reconsidering the ordering here amd moveing\n\nself.driver.init_host(host\u003dself.host) to line 1788 below right before calling init_virt_events. and after where we currently get the instnaces. so we can pass them in and elimate the addtional call entirly.\n\npassing the instnace would be a virt direr api change however.","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2639c9bc886b12a4a3e84ee33bc509a4015db6d3","unresolved":false,"context_lines":[{"line_number":1759,"context_line":"                    \u0027number of disk devices.\u0027)"},{"line_number":1760,"context_line":"            raise exception.InvalidConfiguration(msg)"},{"line_number":1761,"context_line":""},{"line_number":1762,"context_line":"        self.driver.init_host(host\u003dself.host)"},{"line_number":1763,"context_line":""},{"line_number":1764,"context_line":"        if service_ref:"},{"line_number":1765,"context_line":"            # If we are an existing service, check to see if we need"}],"source_content_type":"text/x-python","patch_set":1,"id":"fca2eceb_9c84cdf9","side":"PARENT","line":1762,"in_reply_to":"445b3556_183f7f78","updated":"2026-07-06 12:51:23.000000000","message":"Done","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a1db7d869d16a2af94d83f0f243ea9ed6e8fb1da","unresolved":true,"context_lines":[{"line_number":1789,"context_line":"        self.init_virt_events()"},{"line_number":1790,"context_line":""},{"line_number":1791,"context_line":"        self._validate_pinning_configuration(instances)"},{"line_number":1792,"context_line":"        self._validate_vtpm_configuration(instances)"},{"line_number":1793,"context_line":""},{"line_number":1794,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1795,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":1,"id":"97216f2b_1e3f3d03","side":"PARENT","line":1792,"updated":"2026-05-28 20:04:34.000000000","message":"the other wasy to fix this are\n1: wrap this ins an if and only call it if its libvirt\n2: add a second compute capablity flag in addtion to the exisitng one.\n3: delte this check engirely by effectivly reverting \nhttps://opendev.org/openstack/nova/commit/bf5eea6fda23cc709e31cedb39e4054fafe923d2\n4: add a validate_instances driver method and move this to that\n\n\nby the way cpu pinning is alos only implemnted by the libvirt driver \nso _validate_pinning_configuration\n\nhttps://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/compute/manager.py#L1069\n\nshoudl also probably not be in the compute manger.\n\nnow it is true tha twhiel other driver dont supprot cpu pinnign they do supprot vcpu_pin_set to contole the nubmer of cpus that tehy can used but valdiating the config option don theed the instances.\nthis is just for valid the instance affinciy on startup up and i belive only the libvirt driver care about htat.","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e58709f2f6f659b5464a2641588c280c6ffe129a","unresolved":true,"context_lines":[{"line_number":1789,"context_line":"        self.init_virt_events()"},{"line_number":1790,"context_line":""},{"line_number":1791,"context_line":"        self._validate_pinning_configuration(instances)"},{"line_number":1792,"context_line":"        self._validate_vtpm_configuration(instances)"},{"line_number":1793,"context_line":""},{"line_number":1794,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1795,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":1,"id":"a723055c_1f241142","side":"PARENT","line":1792,"in_reply_to":"225222d3_4755f9d2","updated":"2026-06-02 19:29:41.000000000","message":"so that parly correct and partly missign the fact that we split the check across 2 diffent place because of course we did.\n\n\nso there were 2 peices of relevent context.\n\ndriver.init_host in the libvirt driver\n\nhttps://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/virt/libvirt/driver.py#L784-L924\n\ncalls  self._check_vtpm_support()\nhttps://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/virt/libvirt/driver.py#L908\nhttps://github.com/openstack/nova/blob/380f657b5102707a3da676478e72fd96691e966b/nova/virt/libvirt/driver.py#L1149-L1204\n\nwhich is what check fi the swtpm_enabeld config option i sset and validates if the current host is compatiable.\n\nso if our libvirt is tooo old or we are missign the binaries that is where that woudl be check before we ever get here.\n\nthe second pice so of context is the rest fo init_host in the libvirt driver does not mutate db state, it validate config , initalise the conenction to libvirt an populates in memoy state exepct fo \n\n_register_all_undefined_instance_details which today gets all instance for the current host andregistered tehre defult image properties if needed.\n\nthat arguable should not happen in init host as it means we currenly list all t he instnace twice on startup instead of once and the first time is happing beforce stable uuid hostname check above. so really we do not want to dfo any db operation on the vms before we have done that.\n\nlooping back to your question of can we ask libvirt if it supprot vTPM\n\norignally no but after we impemented this feature in nova we went to the libvirt team and asked them to extend libvirt to provide the info\n\nso now virsh domcapabilities includes\n```\n    \u003ctpm supported\u003d\u0027yes\u0027\u003e\n      \u003cenum name\u003d\u0027model\u0027\u003e\n        \u003cvalue\u003etpm-tis\u003c/value\u003e\n        \u003cvalue\u003etpm-crb\u003c/value\u003e\n      \u003c/enum\u003e\n      \u003cenum name\u003d\u0027backendModel\u0027\u003e\n        \u003cvalue\u003epassthrough\u003c/value\u003e\n        \u003cvalue\u003eemulator\u003c/value\u003e\n        \u003cvalue\u003eexternal\u003c/value\u003e\n      \u003c/enum\u003e\n      \u003cenum name\u003d\u0027backendVersion\u0027\u003e\n        \u003cvalue\u003e1.2\u003c/value\u003e\n        \u003cvalue\u003e2.0\u003c/value\u003e\n      \u003c/enum\u003e\n    \u003c/tpm\u003e\n    \n```\n\nso we can now deprecate and or remvoe the config option and delegate this to libvirt to tell us.\n\ntakashi may have already wrote a patch fro trhat at some poin but\ni think we shoudl do that  in a diffent commit\n\n\ni can create a followup that will make the detection automatic but i think the solve for the prfoamcne issue is to add \n\nprocess_instances_at_startup  to the base virt dirver and call it here and move\n\n_validate_pinning_configuration, _validate_vtpm_configuration\nand _register_all_undefined_instance_details  to process_instances_at_startup in the libvirt driver\n\n\nthat way we elimiante the pinnnign an dvtpm configurtion check for ironic and other virt driver that dont care\nelimiate one entirly list instance by host call for the libvirt startup and finally make sure all mutating db operation happen after the compute service hostname check.\n\nill see if i can wip that up quickly.","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"6ad1cca49d007db100ea994ea68818d57a367e2a","unresolved":true,"context_lines":[{"line_number":1789,"context_line":"        self.init_virt_events()"},{"line_number":1790,"context_line":""},{"line_number":1791,"context_line":"        self._validate_pinning_configuration(instances)"},{"line_number":1792,"context_line":"        self._validate_vtpm_configuration(instances)"},{"line_number":1793,"context_line":""},{"line_number":1794,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1795,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":1,"id":"225222d3_4755f9d2","side":"PARENT","line":1792,"in_reply_to":"883f26b9_dabb0709","updated":"2026-06-02 18:34:20.000000000","message":"I have kept reading over this issue multiple times getting confused and finally I see what is weird about this is the driver capability reporting is based solely on the config option:\n```\n         self.capabilities \u003d {\n             [...]\n             \"supports_vtpm\": CONF.libvirt.swtpm_enabled,\n             [...]\n         }\n\n```\nI kept thinking to myself, \"why is this not solely based on driver capability, why is this so hard to figure out when to do the validation and when not\" because I had been thinking the capability was something from libvirt itself, like a query of actual libvirt whether it can do it or not. And that a driver like Ironic would be just, no capability, no validation, done.\n\nIt seems weird that someone could just set set `CONF.libvirt.swtpm_enabled \u003d true` and that will make the compute host advertise support even if it doesn\u0027t have the right packages installed etc.\n\nI wonder, is there no way to do that? To query libvirt itself and determine whether it _could_ support vTPM independent of `CONF.libvirt.swtpm_enabled` and use that to determine whether to validate the instances or not, and let that be part of the driver capability report? And then just let the validation check be based on driver capability.","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6ff7cfad0dfd2c6736686a954eb51fb5e241f6ed","unresolved":true,"context_lines":[{"line_number":1789,"context_line":"        self.init_virt_events()"},{"line_number":1790,"context_line":""},{"line_number":1791,"context_line":"        self._validate_pinning_configuration(instances)"},{"line_number":1792,"context_line":"        self._validate_vtpm_configuration(instances)"},{"line_number":1793,"context_line":""},{"line_number":1794,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1795,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":1,"id":"883f26b9_dabb0709","side":"PARENT","line":1792,"in_reply_to":"97216f2b_1e3f3d03","updated":"2026-05-28 22:39:03.000000000","message":"the more i think about this the more i feel option 4 is the right path here\n\ni shoudl add \n```\ndef process_instances_at_startup(self, instances):\n  return instances\n```\n\nto the base virt driver adn i should move\n\n_validate_pinning_configuration, _validate_vtpm_configuration\nand _register_all_undefined_instance_details to libvirt implmeation of process_instances_at_startup. \ninstead and pass down the instances form the compute manger to the virt driver so that the virt dirver\n\nthat will allwo use to remove a db call form teh virt dirver and do only isntnace lookup on start up.\n\nif i rebase on https://review.opendev.org/c/openstack/nova/+/977037","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2639c9bc886b12a4a3e84ee33bc509a4015db6d3","unresolved":false,"context_lines":[{"line_number":1789,"context_line":"        self.init_virt_events()"},{"line_number":1790,"context_line":""},{"line_number":1791,"context_line":"        self._validate_pinning_configuration(instances)"},{"line_number":1792,"context_line":"        self._validate_vtpm_configuration(instances)"},{"line_number":1793,"context_line":""},{"line_number":1794,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1795,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":1,"id":"b568d727_3d6a7ba9","side":"PARENT","line":1792,"in_reply_to":"a723055c_1f241142","updated":"2026-07-06 12:51:23.000000000","message":"Done","commit_id":"db1e6ddfe7d9ac631d0b842810242f8821e1b818"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8b7d4952d0c31005754873b3b7cc0fd2f7b9985b","unresolved":true,"context_lines":[{"line_number":1691,"context_line":"        instances \u003d self.driver.process_instances_at_startup("},{"line_number":1692,"context_line":"            context, instances)"},{"line_number":1693,"context_line":""},{"line_number":1694,"context_line":"        self.init_virt_events()"},{"line_number":1695,"context_line":""},{"line_number":1696,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1697,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":2,"id":"14ec6b1e_48833537","line":1694,"updated":"2026-06-15 23:28:37.000000000","message":"im not sure which order i want here.\n\nof if the order matters in this case","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2639c9bc886b12a4a3e84ee33bc509a4015db6d3","unresolved":false,"context_lines":[{"line_number":1691,"context_line":"        instances \u003d self.driver.process_instances_at_startup("},{"line_number":1692,"context_line":"            context, instances)"},{"line_number":1693,"context_line":""},{"line_number":1694,"context_line":"        self.init_virt_events()"},{"line_number":1695,"context_line":""},{"line_number":1696,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1697,"context_line":"        # becomes problematic here then we should consider adding a config"}],"source_content_type":"text/x-python","patch_set":2,"id":"3ee7de07_72411f54","line":1694,"in_reply_to":"14ec6b1e_48833537","updated":"2026-07-06 12:51:23.000000000","message":"this is the correct order because we do not want to start processing events before we are sure the instances are in the expected state","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":false,"context_lines":[{"line_number":1692,"context_line":"        # instance state before we subscribe to virt lifecycle events or start"},{"line_number":1693,"context_line":"        # recovering instances. This must stay after the host rename check as"},{"line_number":1694,"context_line":"        # drivers may mutate instance records."},{"line_number":1695,"context_line":"        instances \u003d self.driver.process_instances_at_startup("},{"line_number":1696,"context_line":"            context, instances)"},{"line_number":1697,"context_line":""},{"line_number":1698,"context_line":"        self.init_virt_events()"}],"source_content_type":"text/x-python","patch_set":3,"id":"40b723fe_4cc4d82e","line":1695,"updated":"2026-07-13 15:29:46.000000000","message":"we have a bit of hidden pattern already seeded in the virt driver to check instances during startup via the self.driver.init_host(host\u003dself.host) call. See \nhttps://github.com/openstack/nova/blob/4f78199ae79ccfa4e39d88dbf71cdce1ca89fe32/nova/virt/libvirt/driver.py#L926\nand\nhttps://github.com/openstack/nova/blob/4f78199ae79ccfa4e39d88dbf71cdce1ca89fe32/nova/virt/libvirt/driver.py#L989-L993\nand\nhttps://github.com/openstack/nova/blob/4f78199ae79ccfa4e39d88dbf71cdce1ca89fe32/nova/virt/libvirt/driver.py#L1049\n\nAs you pointed out we want these instance mutating checks to happen *after* the host rename check. And I agree. So your new method make sense. And we need to move _register_all_undefined_instance_details to be called from process_instances_at_startup.\n\n// later\n\nyou did it. thanks.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":true,"context_lines":[{"line_number":1697,"context_line":""},{"line_number":1698,"context_line":"        self.init_virt_events()"},{"line_number":1699,"context_line":""},{"line_number":1700,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1701,"context_line":"        # becomes problematic here then we should consider adding a config"},{"line_number":1702,"context_line":"        # option or a driver flag to tell us if we should thread"},{"line_number":1703,"context_line":"        # _destroy_evacuated_instances and"}],"source_content_type":"text/x-python","patch_set":3,"id":"0ff3e4c0_e4549816","line":1700,"updated":"2026-07-13 15:29:46.000000000","message":"hehe, this might be part of the performance problem?","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5abc5581b5bf84123b8485e23491e59b6f6c7665","unresolved":false,"context_lines":[{"line_number":1697,"context_line":""},{"line_number":1698,"context_line":"        self.init_virt_events()"},{"line_number":1699,"context_line":""},{"line_number":1700,"context_line":"        # NOTE(gibi): If ironic and vcenter virt driver slow start time"},{"line_number":1701,"context_line":"        # becomes problematic here then we should consider adding a config"},{"line_number":1702,"context_line":"        # option or a driver flag to tell us if we should thread"},{"line_number":1703,"context_line":"        # _destroy_evacuated_instances and"}],"source_content_type":"text/x-python","patch_set":3,"id":"00e63712_831907e4","line":1700,"in_reply_to":"0ff3e4c0_e4549816","updated":"2026-07-14 12:34:24.000000000","message":"Acknowledged","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":true,"context_lines":[{"line_number":1711,"context_line":"            # Initialise instances on the host that are not evacuating"},{"line_number":1712,"context_line":"            for instance in instances:"},{"line_number":1713,"context_line":"                if instance.uuid not in evacuated_instances:"},{"line_number":1714,"context_line":"                    self._init_instance(context, instance)"},{"line_number":1715,"context_line":""},{"line_number":1716,"context_line":"            # NOTE(gibi): collect all the instance uuids that is in some way"},{"line_number":1717,"context_line":"            # was already handled above. Either by init_instance or by"}],"source_content_type":"text/x-python","patch_set":3,"id":"3a89cbc8_0a0c56e6","line":1714,"updated":"2026-07-13 15:29:46.000000000","message":"Have you considered including the per instance initialization on the driver level into this call? I guess it would make sense not validate and fail on instances that are already evacuated away.","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3d011f0205cc3dea8e292f803c9d4811a73d47e2","unresolved":true,"context_lines":[{"line_number":1711,"context_line":"            # Initialise instances on the host that are not evacuating"},{"line_number":1712,"context_line":"            for instance in instances:"},{"line_number":1713,"context_line":"                if instance.uuid not in evacuated_instances:"},{"line_number":1714,"context_line":"                    self._init_instance(context, instance)"},{"line_number":1715,"context_line":""},{"line_number":1716,"context_line":"            # NOTE(gibi): collect all the instance uuids that is in some way"},{"line_number":1717,"context_line":"            # was already handled above. Either by init_instance or by"}],"source_content_type":"text/x-python","patch_set":3,"id":"aa900345_851fab75","line":1714,"in_reply_to":"3a89cbc8_0a0c56e6","updated":"2026-07-13 16:49:29.000000000","message":"i have not condireded this no\n\njust reading your comment now, \n\nhttps://docs.openstack.org/nova/latest/user/support-matrix.html#operation_evacuate\n\nevacuate is listed as unknow for both vmware and ironic although rebuild is supproted on both\nhttps://docs.openstack.org/nova/latest/user/support-matrix.html#operation_rebuild\n\nso fi we are sure that that check also only applies to libvirt then sure this can be moved in this commit or a followup.\n\nlooking at the actull capablites dict\nironic and vmware report false\nhttps://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L158\nhttps://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L68\nand its not set for zvm so it will also be false\nhttps://github.com/openstack/nova/blob/master/nova/virt/zvm/driver.py#L46\n\nso i guess this could also move or be made condtional.\n\nany prefence","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5abc5581b5bf84123b8485e23491e59b6f6c7665","unresolved":false,"context_lines":[{"line_number":1711,"context_line":"            # Initialise instances on the host that are not evacuating"},{"line_number":1712,"context_line":"            for instance in instances:"},{"line_number":1713,"context_line":"                if instance.uuid not in evacuated_instances:"},{"line_number":1714,"context_line":"                    self._init_instance(context, instance)"},{"line_number":1715,"context_line":""},{"line_number":1716,"context_line":"            # NOTE(gibi): collect all the instance uuids that is in some way"},{"line_number":1717,"context_line":"            # was already handled above. Either by init_instance or by"}],"source_content_type":"text/x-python","patch_set":3,"id":"cb728281_96005d2b","line":1714,"in_reply_to":"aa900345_851fab75","updated":"2026-07-14 12:34:24.000000000","message":"Done","commit_id":"e325555b184cd36413d348603b3b1abeb13bdcaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c729b53690ffa8653af2ec3f72124d3090716116","unresolved":true,"context_lines":[{"line_number":1695,"context_line":"        # demonstrated startup bottleneck, it could be moved to background"},{"line_number":1696,"context_line":"        # processing separately."},{"line_number":1697,"context_line":"        try:"},{"line_number":1698,"context_line":"            evacuated_instances \u003d {}"},{"line_number":1699,"context_line":"            if self.driver.capabilities.get(\u0027supports_evacuate\u0027, False):"},{"line_number":1700,"context_line":"                # Check that instances were not already evacuated to another"},{"line_number":1701,"context_line":"                # host before asking the driver to process their state."},{"line_number":1702,"context_line":"                evacuated_instances \u003d self._destroy_evacuated_instances("},{"line_number":1703,"context_line":"                    context, nodes_by_uuid)"},{"line_number":1704,"context_line":""},{"line_number":1705,"context_line":"            # Allow the virt driver to validate and normalize the persisted"},{"line_number":1706,"context_line":"            # state of local instances before recovering them. This must stay"}],"source_content_type":"text/x-python","patch_set":4,"id":"ba62a1a8_b8f122e5","line":1703,"range":{"start_line":1698,"start_character":11,"end_line":1703,"end_character":43},"updated":"2026-07-13 20:07:18.000000000","message":"im not sure if this is what you were suggeting or if you wanted me to move this into the libvirt driver?","commit_id":"4a7898d31e0cbde4117d91447d54d362f6833f41"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"63e44d3373e5690681bffff40360abd6ae6c7fce","unresolved":false,"context_lines":[{"line_number":1695,"context_line":"        # demonstrated startup bottleneck, it could be moved to background"},{"line_number":1696,"context_line":"        # processing separately."},{"line_number":1697,"context_line":"        try:"},{"line_number":1698,"context_line":"            evacuated_instances \u003d {}"},{"line_number":1699,"context_line":"            if self.driver.capabilities.get(\u0027supports_evacuate\u0027, False):"},{"line_number":1700,"context_line":"                # Check that instances were not already evacuated to another"},{"line_number":1701,"context_line":"                # host before asking the driver to process their state."},{"line_number":1702,"context_line":"                evacuated_instances \u003d self._destroy_evacuated_instances("},{"line_number":1703,"context_line":"                    context, nodes_by_uuid)"},{"line_number":1704,"context_line":""},{"line_number":1705,"context_line":"            # Allow the virt driver to validate and normalize the persisted"},{"line_number":1706,"context_line":"            # state of local instances before recovering them. This must stay"}],"source_content_type":"text/x-python","patch_set":4,"id":"94385048_3ea92973","line":1703,"range":{"start_line":1698,"start_character":11,"end_line":1703,"end_character":43},"in_reply_to":"5969a4b7_24426888","updated":"2026-07-15 16:09:37.000000000","message":"I\u0027m fine with the move you proposed here. My only goal was not to process instances that are evacuated away from this host as they should not cause trouble on this host any more.","commit_id":"4a7898d31e0cbde4117d91447d54d362f6833f41"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5abc5581b5bf84123b8485e23491e59b6f6c7665","unresolved":true,"context_lines":[{"line_number":1695,"context_line":"        # demonstrated startup bottleneck, it could be moved to background"},{"line_number":1696,"context_line":"        # processing separately."},{"line_number":1697,"context_line":"        try:"},{"line_number":1698,"context_line":"            evacuated_instances \u003d {}"},{"line_number":1699,"context_line":"            if self.driver.capabilities.get(\u0027supports_evacuate\u0027, False):"},{"line_number":1700,"context_line":"                # Check that instances were not already evacuated to another"},{"line_number":1701,"context_line":"                # host before asking the driver to process their state."},{"line_number":1702,"context_line":"                evacuated_instances \u003d self._destroy_evacuated_instances("},{"line_number":1703,"context_line":"                    context, nodes_by_uuid)"},{"line_number":1704,"context_line":""},{"line_number":1705,"context_line":"            # Allow the virt driver to validate and normalize the persisted"},{"line_number":1706,"context_line":"            # state of local instances before recovering them. This must stay"}],"source_content_type":"text/x-python","patch_set":4,"id":"5969a4b7_24426888","line":1703,"range":{"start_line":1698,"start_character":11,"end_line":1703,"end_character":43},"in_reply_to":"ba62a1a8_b8f122e5","updated":"2026-07-14 12:34:24.000000000","message":"@gibizer@gmail.com so the obvious alternative would be to shove this into \n\nself.driver.process_instances_at_startup but im not sure that is what you wanted","commit_id":"4a7898d31e0cbde4117d91447d54d362f6833f41"}],"nova/virt/driver.py":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8b7d4952d0c31005754873b3b7cc0fd2f7b9985b","unresolved":true,"context_lines":[{"line_number":375,"context_line":"        :param instances: nova.objects.instance.InstanceList"},{"line_number":376,"context_line":"        :returns: nova.objects.instance.InstanceList"},{"line_number":377,"context_line":"        \"\"\""},{"line_number":378,"context_line":"        return instances"},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"    def cleanup_host(self, host):"},{"line_number":381,"context_line":"        \"\"\"Clean up anything that is necessary for the driver gracefully stop,"}],"source_content_type":"text/x-python","patch_set":2,"id":"7c34dc4a_f6a4c19b","line":378,"updated":"2026-06-15 23:28:37.000000000","message":"this default means that all in tree and out of tree driver should have no upgrade impact.","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2639c9bc886b12a4a3e84ee33bc509a4015db6d3","unresolved":false,"context_lines":[{"line_number":375,"context_line":"        :param instances: nova.objects.instance.InstanceList"},{"line_number":376,"context_line":"        :returns: nova.objects.instance.InstanceList"},{"line_number":377,"context_line":"        \"\"\""},{"line_number":378,"context_line":"        return instances"},{"line_number":379,"context_line":""},{"line_number":380,"context_line":"    def cleanup_host(self, host):"},{"line_number":381,"context_line":"        \"\"\"Clean up anything that is necessary for the driver gracefully stop,"}],"source_content_type":"text/x-python","patch_set":2,"id":"9116ffeb_27948f4a","line":378,"in_reply_to":"7c34dc4a_f6a4c19b","updated":"2026-07-06 12:51:23.000000000","message":"Acknowledged","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":false,"context_lines":[{"line_number":924,"context_line":"        # Set REGISTER_IMAGE_PROPERTY_DEFAULTS in the instance system_metadata"},{"line_number":925,"context_line":"        # to default values for properties that have not already been set."},{"line_number":926,"context_line":"        self._register_all_undefined_instance_details()"},{"line_number":927,"context_line":""},{"line_number":928,"context_line":"    def _check_pci_whitelist(self):"},{"line_number":929,"context_line":""},{"line_number":930,"context_line":"        need_specific_version \u003d False"}],"source_content_type":"text/x-python","patch_set":3,"id":"1f7efd47_23bc6bdb","side":"PARENT","line":927,"updated":"2026-07-13 15:29:46.000000000","message":"ohh you did it. nice. thanks.","commit_id":"d699068af042a1aa8e7865682306e7239dbf223d"}],"releasenotes/notes/bug-2154495-vtpm-startup-validation-4e28c5db901e.yaml":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8b7d4952d0c31005754873b3b7cc0fd2f7b9985b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5d597991_88d63c41","line":10,"updated":"2026-06-15 23:28:37.000000000","message":"if we proceed in this direction instead i proably should mention the new virt driver method even if there is no upgrade impatct to it.","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c161027c6089039408de2ab4ae3313bc66c6b817","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8de0efd8_95ccd711","line":10,"in_reply_to":"5d597991_88d63c41","updated":"2026-07-13 15:29:46.000000000","message":"and maybe extend this with the pcpu check as that is also moved","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5abc5581b5bf84123b8485e23491e59b6f6c7665","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"aa7b8040_1c21e3c0","line":10,"in_reply_to":"860c0e8e_e25e4da3","updated":"2026-07-14 12:34:24.000000000","message":"Done","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3d011f0205cc3dea8e292f803c9d4811a73d47e2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"860c0e8e_e25e4da3","line":10,"in_reply_to":"8de0efd8_95ccd711","updated":"2026-07-13 16:49:29.000000000","message":"sure","commit_id":"3629c502abce1c991ff860fcdd3c68948cebc2f0"}]}