| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-19 | |||
| 09:15:50 | gibi | but the premise is that you don't trust the provider so you need a way to be safe | |
| 09:16:04 | gibi | so if the provider tells you it is encrypted you wont trust that either | |
| 09:16:26 | sean-k-mooney | this socket conenct to a deamon run on the host by the provdier | |
| 09:16:31 | sean-k-mooney | you cant trust that eitehr | |
| 09:17:25 | gibi | I guess there are mechanism to make that work. I guess it is just the channel not the source of truth | |
| 09:17:43 | antia | this goes beyond the scope I think. Intel has documentation on this process | |
| 09:18:05 | sean-k-mooney | antia im trying not to second guess the spec | |
| 09:18:16 | gibi | sean-k-mooney: if this helps I'm OK to say in the doc that nova does not actively support attestation. So we can close bugs. But actively preventing attestation I'm not OK with | |
| 09:18:20 | sean-k-mooney | im just highlihgt that i woudl have ask for this to be remvoed if i had reviewed the spec | |
| 09:18:35 | sean-k-mooney | so im highlighting the maintaince concern here not saying we ahve to remove it | |
| 09:18:45 | sean-k-mooney | gibi: yes that woudl help | |
| 09:18:51 | gibi | then lets do that | |
| 09:18:54 | antia | that I can add | |
| 09:19:04 | gibi | thanks both of you | |
| 09:19:34 | sean-k-mooney | gibi: im just sentitve to the fact that folks have come to depend on the internals of some feature that we didnt intnet to be public in the past | |
| 09:19:55 | sean-k-mooney | i.e. cloud-init incorrectly usign our dmi/smbios code to detech that its oepnstack | |
| 09:20:02 | gibi | I think in case of AMD you cannot even prevent attestation from libvirt if encryption is on | |
| 09:20:09 | sean-k-mooney | even though that only ever worked for libvirt | |
| 09:20:43 | sean-k-mooney | ack | |
| 09:21:17 | sean-k-mooney | antia: for what its woth the feature more or less looks ok | |
| 09:21:35 | sean-k-mooney | the main blocker for me is you missing the libvirt version check and the cgroups issue i mentioned in teh review | |
| 09:21:51 | antia | thanks for reviewing! | |
| 09:21:58 | sean-k-mooney | antia: once those 2 issues are adressed i think we can more or less proceed with the series | |
| 09:22:00 | antia | the cgroup issue I am resolving right now | |
| 09:22:26 | sean-k-mooney | cool | |
| 09:23:32 | gibi | sean-k-mooney: about the version check | |
| 09:23:34 | antia | I am not strictly against a version check for TDX, but I find it unnecessary. The same isn't done for SNP and it is not needed since Libvirt capabilities can handle it | |
| 09:23:41 | gibi | yeah ^^ | |
| 09:24:07 | gibi | so libvirt only reports the domcap if libvirt + qemu is supporting the feature | |
| 09:24:25 | sean-k-mooney | oh we already have that supproted via domcaps | |
| 09:24:29 | gibi | yeah | |
| 09:24:34 | sean-k-mooney | and we are usign that to fileter the traits reporitng | |
| 09:24:38 | gibi | the flag yes, the capacity does not | |
| 09:24:39 | sean-k-mooney | ok then jsut the cgroups issue | |
| 09:24:50 | gibi | yepp | |
| 09:24:54 | antia | okay good | |
| 09:24:57 | sean-k-mooney | sorry i missed that | |
| 09:25:37 | gibi | no worries | |
| 09:40:24 | gibi | so about scsi. On my machine the VM is created successfully but cannot boot. It stops at the EFI setup not seeing a boot device | |
| 09:56:28 | antia | that is consistent with my previous experience | |
| 10:27:15 | sean-k-mooney | that is becaus of the qemu firmware image yes? | |
| 10:27:25 | sean-k-mooney | so it may or may not work dependin on that | |
| 10:27:41 | sean-k-mooney | im not sure if we shoudl relaly block it in nova but we shoudl call it out in the docs | |
| 10:39:43 | gibi | yepp call it out in the doc | |
| 10:40:06 | gibi | (and yes I tested without TDX that the same image boots from scsi) | |
| 10:40:58 | sean-k-mooney | ack, i partly wonder if we are jsut mising setting somethign liek the iommu options we recnelty stop setting for sev | |
| 10:41:15 | sean-k-mooney | but i guess we can follow up with improvment next cycle if we discover a way to supprot it | |
| 10:41:22 | sean-k-mooney | and jsut treat it as a minor bugfix | |
| 10:41:41 | gibi | OK | |
| 11:16:23 | opendevreview | Bhavana proposed openstack/nova-specs master: Add spec for MIG-aware PCI Host Weigher https://review.opendev.org/c/openstack/nova-specs/+/998753 | |
| 11:52:49 | sean-k-mooney | im generally not sure ^ is something that is really in nova scope now | |
| 11:53:20 | sean-k-mooney | cybrog will need a way to provide its own way to experss schdulign prioties in the future | |
| 11:53:31 | sean-k-mooney | be it a weigher or somethign more generic in nova | |
| 11:54:11 | sean-k-mooney | but if we are actully intending this fucntionatly to go out of nova then addign mig aware ness to nova is questionable | |
| 11:54:32 | sean-k-mooney | nova can mange vgpus on PGUS configure with mig | |
| 11:54:41 | sean-k-mooney | but its is not aware mig is in use | |
| 12:35:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: [DNM]: Troubleshoot race condition in unshelve vif plug https://review.opendev.org/c/openstack/nova/+/1001294 | |
| 12:35:15 | opendevreview | Balazs Gibizer proposed openstack/nova master: [WIP]Add task_state = None as pre-condition of unshelve https://review.opendev.org/c/openstack/nova/+/1001485 | |
| 12:35:31 | gibi | gmaan: ^^ I have hunch based on your last comment | |
| 12:36:00 | sean-k-mooney | unshivlign while still shevle offloading? | |
| 12:36:04 | gibi | yepp | |
| 12:36:11 | gibi | it seems like we have a race | |
| 12:36:25 | gibi | the offloading removes the instance.host while unshelve is already claimed | |
| 12:36:27 | sean-k-mooney | ya i can see that being a problem | |
| 12:36:50 | sean-k-mooney | also ya addign task state to the decoreato rmakes seesne | |
| 12:36:58 | gibi | and it might happen more often in the grenade job as it uses a single conductor setup instead of a super and a cell conductor | |
| 12:37:19 | gibi | so the two instance.save happens in the same conductor | |
| 12:37:37 | sean-k-mooney | maybe although i dont think that would make it that much slower with onloy 1-2 vms | |
| 12:37:43 | sean-k-mooney | *1-2 computes | |
| 12:37:48 | gibi | yeah, I'm just guessing here | |
| 12:37:58 | sean-k-mooney | i think the race hunch is a good one | |
| 12:38:09 | sean-k-mooney | jus tnot entirly sure why its more common in grenade | |
| 12:38:10 | gibi | we will see. if the precondition makes the tempest test fail early that will prove it | |
| 12:38:47 | gibi | it can be something with threading + single conductor as well. I think only grenade is doing that now | |
| 12:39:00 | sean-k-mooney | is the tempest tst properly waiting for it to be shleve offloaded or just unshilving straight away | |
| 12:39:05 | gibi | threading allows more random task switching | |
| 12:39:27 | gibi | sean-k-mooney: even if the tempest waits for the shelve_offload state we might set that early with a task state | |
| 12:39:30 | gibi | let me check | |
| 12:39:49 | sean-k-mooney | gibi: well im thinking that tempest shoudl retry the unshleve | |
| 12:40:03 | sean-k-mooney | at least on a 409 | |
| 12:40:10 | sean-k-mooney | which is what that decoreator shoudl be returning | |
| 12:40:58 | sean-k-mooney | since the transtion form shelve to shelve offloaded is configurabel and depend on if its BFV or BFI | |
| 12:41:14 | sean-k-mooney | or using ceph | |
| 12:41:28 | gibi | https://github.com/openstack/tempest/blob/fa340b1f5fff8f57a018be206644c81b6d36b3d4/tempest/common/compute.py#L388-L400 | |
| 12:41:30 | sean-k-mooney | so i dont think we can write the test to know which to expect | |
| 12:41:37 | gibi | so it depends on the tempest config what we are waiting for | |
| 12:41:42 | sean-k-mooney | but it can retyr the unshelve on 409 conflict and still be correct | |
| 12:42:10 | gibi | I can imagine we end up only waiting for SHELVED state and issue an unshelve | |
| 12:42:19 | sean-k-mooney | yep | |
| 12:42:37 | sean-k-mooney | but as i said for images_type=rbd and bfv we go drictly to shelve_offloaded i think | |
| 12:42:41 | gibi | OK we will see and if it is the case then we need to fix nova and tempest as well | |
| 12:42:43 | sean-k-mooney | regradless fo the offload time | |
| 12:43:33 | sean-k-mooney | ya we should have ci reulst in a while and we can see | |
| 12:45:53 | gibi | yepp | |
| 14:15:09 | dansmith | gibi: I just +2'd this if you want to re-add yours after the test coverage fix: https://review.opendev.org/c/openstack/nova/+/998571 | |
| 14:23:28 | gibi | dansmith: ohh sure. Thanks for the reviews there | |
| 14:30:00 | gibi | Uggla: I left some feedback in the repro and fix in https://review.opendev.org/c/openstack/nova/+/999978 | |
| 14:30:33 | gibi | I agree this is a valid repro but for the fix we might need to make a step back and see if we can make a wider fix | |
| 14:30:56 | gibi | having an instance without task state and without instance.host during a period of evac sounds a source of different issuees | |
| 14:45:05 | gibi | Uggla: on the same note I will need to drop at 17:45 latest from the upstream triage call today | |