| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-19 | |||
| 09:12:34 | gibi | we should not do hypoteticals. Use the underlying default is the safest in my eyes | |
| 09:12:59 | sean-k-mooney | its not that the socket will break it its we are enabling a feature that we dont know the side effect of | |
| 09:13:19 | gibi | we are not enabling it, libvirt does. | |
| 09:13:36 | sean-k-mooney | so we are not addign it to the domain | |
| 09:13:41 | sean-k-mooney | ok | |
| 09:13:59 | gibi | and the whole reason to have these features is to be able to prove that your VM is secure | |
| 09:14:10 | sean-k-mooney | no | |
| 09:14:14 | gibi | so blocking the possibility of that actively is against the goal | |
| 09:14:19 | sean-k-mooney | its to encypt the guest memory | |
| 09:14:31 | sean-k-mooney | proving its secure is its own feature | |
| 09:14:33 | gibi | but how would you know that it is encrypted? | |
| 09:14:37 | antia | encrypting the guest memory is somewhat useless unless it can be proven | |
| 09:14:46 | sean-k-mooney | that is my point attestation of any kind shoudl ahve been its own dedicated feature | |
| 09:15:15 | sean-k-mooney | gibi: im not sure you shoudl knwo that as a normal user or how | |
| 09:15:35 | sean-k-mooney | beyond the flavor extra spec if that is expsoed to you in the releven tcloud | |
| 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 | |