| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-23 | |||
| 16:59:52 | opendevmeet | Meeting ended Tue Sep 23 16:59:52 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:12 | elodilles | hence, unfortunately sticking to UTC is probably the most straightforward :/ | |
| 17:01:29 | elodilles | in my opinion | |
| 17:22:55 | Uggla | elodilles with all our internal meetings + daylight + reasonable time (not too late), I'm struggling to find a single day that works. :( | |
| 17:24:54 | Uggla | What I know is Tuesday is the worst, so we need to change. | |
| 21:11:51 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 21:11:51 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795 | |
| 21:11:52 | opendevreview | melanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData https://review.opendev.org/c/openstack/nova/+/952628 | |
| 21:11:52 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 21:11:53 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 21:11:53 | opendevreview | melanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration https://review.opendev.org/c/openstack/nova/+/962051 | |
| 21:11:54 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 21:11:55 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 21:11:55 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 21:11:57 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 21:11:57 | opendevreview | melanie witt proposed openstack/nova master: WIP Opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 21:55:15 | clarkb | zigo: is that with python3.13 too? | |
| 21:55:21 | zigo | Yeah. | |
| 21:55:22 | clarkb | exciting | |
| 21:55:36 | zigo | Well, I got Epoxy on official Debian under 3.13, and it works ... | |
| 21:56:12 | zigo | Release day is when? Tomorrow? | |
| #openstack-nova - 2025-09-24 | |||
| 07:37:34 | Uggla | zigo release of F should be next week. | |
| 07:38:01 | gibi | zigo: nice! | |
| 07:39:07 | Uggla | zigo yep thx for the testing, that's cool ! | |
| 07:43:53 | lajoskatona | Uggla: Hi, just would like to highlight that the first green patch for migrating from neutronclient to SDK is ready: https://review.opendev.org/c/openstack/nova/+/928022 , I plan to migrate the remaining calls (like subnets, ports, sec_groups....) also (I hope I will have time for it) | |
| 07:45:21 | Uggla | lajoskatona cool good news | |
| 09:30:49 | gokhan__ | hello folks, is there a way to rescue openstack windows instance ? | |
| 09:32:18 | gokhan__ | What values should I set for the hw_rescue_device and hw_rescue_bus image properties for Windows instances in OpenStack? | |
| 10:22:06 | jssfr | gokhan__, that probably depends on what image you want to use for rescuing? | |
| 10:22:28 | jssfr | if it's a windows image, I'd suggest to try a sata CDROM as bus (I think virtio still needs specific drivers on windows, so I'd stay away from that) | |
| 10:27:12 | elodilles | Uggla: I'm about to check and generate last-minute RCs where needed, and I see that nova has a merged bug fix on stable/2025.2 already. do you consider that bug release critical? should I generate an RC2 for that? (the bug fix is: https://review.opendev.org/c/openstack/nova/+/961804 ) | |
| 10:45:51 | gokhan__ | jssfr, I am using windows server 2019 qcow2 image and I want to give this image also as rescue disk image. | |
| 10:51:37 | jssfr | gokhan__, then I'd go for hw_rescue_device=cdrom and hw_rescue_bus= ... hm, sata is not an option, then I'd first try scsi and if that doesn't work usb. | |
| 10:52:22 | gokhan__ | hw_rescue_device | |
| 10:52:22 | gokhan__ | sata didn't work jssfr | |
| 10:52:22 | gokhan__ | hw_rescue_bus | |
| 10:52:22 | gokhan__ | cdrom | |
| 10:54:07 | jssfr | gokhan__, yeah, I just noticed sata is not an option. try scsi and if that doesn't work, try usb. | |
| 11:00:31 | gokhan__ | jssfr, ok I will try with different options. may be if hw_rescue_device=cdrom we need to use .iso image. | |
| 11:46:10 | gokhan__ | jssfr, with windows 2019 server image iso hw_rescue_device=cdrom and hw_rescue_bus=scsi worked. I can see console. But when I try to repair instance it didn't worked. it can't show disks. it says no disk to repair | |
| 12:01:40 | opendevreview | Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777 | |
| 12:05:47 | opendevreview | Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777 | |
| 12:12:55 | opendevreview | Taketani Ryo proposed openstack/nova-specs master: Add a spec for 2026.1 for libvirt launching Arm CCA instances https://review.opendev.org/c/openstack/nova-specs/+/960777 | |
| 12:18:34 | ykarel_ | uptime | |
| 13:03:28 | gibi | Copy conference info | |
| 13:03:28 | gibi | content_copy | |
| 13:03:28 | gibi | fyi eventlet sync in ~90 minutes meet.google.com/bcy-uqoz-hje | |
| 13:03:28 | gibi |  | |
| 13:03:40 | gibi | baad copy past buffer, baaad :) | |
| 13:03:53 | gibi | but the link is correct | |
| 13:38:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: [hacking] N374 do not use time.sleep(0) to yield https://review.opendev.org/c/openstack/nova/+/950992 | |
| 13:39:32 | gibi | stephenfin: thanks. Good catch of my sloppy conflict resolution on ^^. I fixed it up | |
| 14:12:14 | bauzas | gibi: can't join the eventlet meeting unfortunately :( | |
| 14:12:19 | gibi | bauzas: no worries | |
| 14:12:42 | gibi | the doc has some links and text about where we are if you later want to take a look | |
| 14:17:30 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron subnets https://review.opendev.org/c/openstack/nova/+/962190 | |
| 14:17:30 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022 | |
| 14:19:22 | dansmith | I've not made much progress on my thing in the last week due to other distractions | |
| 14:22:18 | gibi | same here. but I want to get back to the rally stuff this week finally | |
| 14:26:13 | gibi | btw, for me devstack in 24.04 in a VM generates strangely high io load recently. So high that it affects the normla use of the host. I'm not seem to able to pinpoint the source in the VM. I rolled back libvirt and qemu to pre sept 16 version in sid and that seems to help at least to get it back to unnoticed if I don't measure it. Maybe it is also related of my use of iommu and IGB for SRIOV... | |
| 14:28:03 | gibi | so that is anoher reason I did not progress with rally :) | |
| 14:42:23 | tkajinam | Can we merge https://review.opendev.org/c/openstack/osc-placement/+/935121 ? (post unmaintained transition change, kept for some time) | |
| 14:42:58 | gibi | tkajinam: done | |
| 14:43:11 | tkajinam | gibi, thx ! | |
| 14:54:24 | opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/2023.1 https://review.opendev.org/c/openstack/osc-placement/+/935121 | |
| 14:56:54 | atmark | hello, is nova host-evacuate-live concurrent or serial? | |
| 15:07:15 | tkajinam | atmark, API calls by cli would be done in serial but the operation is asynchronous so actual migration may be run concurrently. | |
| 15:07:48 | tkajinam | atmark, note that the max_concurrent_live_migrations option controls how a single nova-compute can run live migration concurrently so by default it processes multiple live migration requests one by one | |
| 15:07:52 | tkajinam | unless you tune it | |
| 15:18:05 | opendevreview | Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 15:37:39 | melwitt | bauzas, dansmith: for your awareness, the spec re-proposal for vtpm live migration is available for review at https://review.opendev.org/c/openstack/nova-specs/+/961564 and the updated patch series is at https://review.opendev.org/q/topic:%22bp/vtpm-live-migration%22+is:open | |
| 15:37:55 | bauzas | ack, will try to review it shortly | |
| 15:38:17 | melwitt | ty | |
| 15:38:52 | dansmith | melwitt: I know, I've had the notification marked in my client to follow up, I just keep ... not | |
| 15:38:57 | dansmith | sorry | |
| 15:39:57 | melwitt | dansmith: sure np | |
| 15:44:58 | melwitt | it when they are back | |
| 15:44:58 | melwitt | for tempest testing I have https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/955969 proposed and I will be adding a test to it for the resize-opt-in. I have also been trying to get vtpm to work with regular tempest but have been unsuccessful. I have got all the setup in place but the guest crashes in qemu and I can't find why. they work fine in whitebox obvs but regular tempest no. I will probably ask sean-k-mooney about | |
| 15:47:57 | dansmith | by "regular tempest" do you mean in an upstream job? | |
| 15:50:09 | melwitt | yes | |
| 15:50:30 | melwitt | the unsuccess is here at the top of the series https://review.opendev.org/c/openstack/nova/+/957477 | |
| 15:51:17 | melwitt | it gets tpm enabled in the capabilities and everything and the guest xml properly gets the tpm device in it but the guest just crashes when it tries to start, example: https://zuul.opendev.org/t/openstack/build/35be637426de4f7db36e56d76c554964/log/compute1/logs/libvirt/libvirt/qemu/instance-00000003_log.txt | |
| 15:52:08 | melwitt | the regular tempest patch is https://review.opendev.org/c/openstack/tempest/+/957475 and what I linked above is the nova patch that depends-on it to see if it could work | |
| 15:52:13 | dansmith | um, duh | |
| 15:52:14 | dansmith | reason=crashed | |
| 15:52:15 | dansmith | there | |
| 15:52:18 | melwitt | lol right | |
| 15:52:18 | dansmith | is your reason | |
| 15:52:53 | dansmith | it does say starting tpm emulator so it seems like it supports it.. are the whitebox and regular tests running different distros/qemu versions, etc? | |
| 15:53:26 | melwitt | I looked in the qemu source code out of curiosity and did not find anything helpful there. it's failing some mutex assertion but I dunno what that could mean as far as cause. and the libvirtd log isn't helping either as to showing why it happens | |
| 15:54:14 | melwitt | whitebox has the same libvirt and qemu version and I _think_ the same distro. I'm stumped so far | |
| 15:55:53 | melwitt | I have been looking for differences between the two because I don't get how it works there and not here. the cpu model looks to be the same. whitebox sets some extra cpu flags but afaict that is specifically for some cpu flags related tests in whitebox and nothing to do with them really being needed by the environment | |
| 15:56:58 | melwitt | in the googling I've done so far regarding the mutex assertion failure I have only found that it has something to do with cpu stuff. like model or arch or something like that? | |
| 15:57:52 | melwitt | ERROR:system/cpus.c is where it's raised from i.e. https://github.com/qemu/qemu/blob/master/system/cpus.c | |
| 15:58:24 | dansmith | what's the diff in the XMLs? | |
| 15:59:14 | melwitt | it looked the same at an eyeballing but let me actually diff them | |
| 16:00:12 | dansmith | yeah let's actually diff | |
| 16:00:32 | dansmith | if they're the same I can't really imagine how they wouldn't work the same unless it's distro/qemu | |
| 16:05:19 | melwitt | yeah. looking at this I'm reminded that there is virt_type=kvm in whitebox whereas upstream is virt_type=qemu. I know that the former means nested virt but from what I googled that should not affect whether the tpm would work | |
| 16:07:44 | clarkb | you can run virt_type=kvm upstream too. But half of our resources will fail (no nested virt) and you get occasional failures elsewhere due to bugs in nested virt. Still maybe worth testing if it helps narrow down the problem? | |