| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-08 | |||
| 06:33:54 | ralonsoh | hello folks, if you have a few minutes, please check https://review.opendev.org/c/openstack/os-vif/+/995933 | |
| 06:33:57 | ralonsoh | thanks in advance! | |
| 06:34:36 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: Fix SEV-SNP feature detection in start up https://review.opendev.org/c/openstack/nova-specs/+/996394 | |
| 06:39:22 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: Use domain capability to detect SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/996395 | |
| 08:13:18 | gibi | gmaan: sean-k-mooney: re threading as default in our unit test jobs. I'm OK in general to switch. The remaining disable unit tests needed DB fixture changes currently being developed in the functional test series. | |
| 08:37:34 | opendevreview | minwoo seo proposed openstack/nova master: Add availability_zone support for migration https://review.opendev.org/c/openstack/nova/+/976085 | |
| 09:08:50 | rubasov | hi nova folks: may I ask for a review on this bugfix (with a functional reproducer)? https://review.opendev.org/q/topic:bug/2051685 | |
| 09:40:29 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316 | |
| 10:33:01 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022 | |
| 10:58:53 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022 | |
| 11:27:29 | tkajinam | mhen, can you share the full content of the firmware descriptor file in Ubuntu ? | |
| 11:27:59 | tkajinam | mhen, it's probably best to report a bug for ubuntu then add the link to it, just in case they fix that invalid descriptor | |
| 11:28:06 | tkajinam | instead of describing the whole details in the local doc | |
| 11:47:38 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120 | |
| 11:47:38 | opendevreview | Takashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090 | |
| 11:47:39 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316 | |
| 11:51:44 | opendevreview | Takashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090 | |
| 11:51:45 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316 | |
| 11:51:45 | opendevreview | Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120 | |
| 12:06:26 | opendevreview | Ashish Gupta proposed openstack/placement master: tests: Support file-backed SQLite URL in placement fixtures https://review.opendev.org/c/openstack/placement/+/993106 | |
| 12:21:04 | opendevreview | Ashish Gupta proposed openstack/nova master: tests: use file-backed Placement SQLite in functional threading https://review.opendev.org/c/openstack/nova/+/992581 | |
| 14:50:52 | opendevreview | Ashish Gupta proposed openstack/nova master: tests: Use per-database write locks instead of global lock https://review.opendev.org/c/openstack/nova/+/992862 | |
| 15:00:50 | Uggla | Reminder: Upstream bug triage in ~30mn. | |
| 15:15:03 | sean-k-mooney | gibi oh actlly https://review.opendev.org/c/opendev/zuul-providers/+/996449 merged an hour ag | |
| 15:15:09 | sean-k-mooney | *ago | |
| 15:15:40 | gibi | ack | |
| 15:15:41 | sean-k-mooney | so we shoudl not see failure in new jobs | |
| 15:34:09 | sean-k-mooney | Uggla: url? | |
| 15:34:26 | Uggla | https://meet.google.com/zjr-rxus-hzj | |
| 15:41:19 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Remove redundant version check for virtio-fs https://review.opendev.org/c/openstack/nova/+/996496 | |
| 15:41:35 | tkajinam | ^^^ wondering if we should check the virt type instead | |
| 15:42:14 | sean-k-mooney | we woudl need to check for both qemu and kvm | |
| 15:42:15 | tkajinam | (this also makes me wonder if we should require kvm for sev support. it may not work for the other virt type really. | |
| 15:42:55 | sean-k-mooney | i.e virtio fs shoudl wor for qemu and kvm | |
| 15:43:10 | sean-k-mooney | sev maybe | |
| 15:43:25 | tkajinam | sean-k-mooney, yeah and I don't think it may work for lxc for example | |
| 15:43:35 | sean-k-mooney | i dont know if that works for qemu or just with kvm | |
| 15:44:19 | sean-k-mooney | well for lxc we are not actully using a vm so i dont think sev works for contianer in general | |
| 15:44:37 | sean-k-mooney | you can enabeld sev for all memoy at the host level but if you do that it used to break sriov | |
| 15:45:10 | tkajinam | sev definitely requires kvm because it relies on the implementations in kvm_amd module. I'm not too sure about virtiofs on the other hand | |
| 15:45:48 | sean-k-mooney | i dont think that requires kvm | |
| 15:46:05 | sean-k-mooney | but ya for sev you could add checkign teh vrit type to the supprot crtiria | |
| 15:46:10 | sean-k-mooney | if its not already there | |
| 15:46:20 | tkajinam | it's not, yet | |
| 15:46:40 | tkajinam | that's has never been added since sev support was first introduced. | |
| 15:47:02 | tkajinam | because that's an existing problem and may be trivial I'll look into that later, separately from sev-snp work | |
| 15:47:03 | sean-k-mooney | well if it does not work it would just fail to boot the vm | |
| 15:47:08 | tkajinam | yeah | |
| 15:47:26 | sean-k-mooney | so its not really a regression to not report sev supprot when virt type is qemu | |
| 15:47:57 | sean-k-mooney | tkajinam: if you can confim it i would just file a bug for it | |
| 15:48:48 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/996496 looks ok ot me although im serpised we dont have any unit test coverage of the functions your removing | |
| 15:49:25 | tkajinam | sean-k-mooney, I'll file one by my end | |
| 15:49:43 | tkajinam | we might want to change that check to virtio-fs to account virt_type, instead of just removing it. | |
| 15:49:53 | tkajinam | (I'll record that as a separate bug, too | |
| 16:07:42 | opendevreview | Takashi Kajinami proposed openstack/nova master: Do not report SEV capability for non kvm virt_type https://review.opendev.org/c/openstack/nova/+/996498 | |
| 16:16:43 | gibi | sean-k-mooney: I think futurist is just slow to shut down an exector https://bugs.launchpad.net/futurist/+bug/2160159 | |
| 16:17:19 | sean-k-mooney | ah ok | |
| 16:17:50 | sean-k-mooney | i mean we could actully swap to concurrent.futures.ThreadPoolExecutor(max_workers=100) if needed | |
| 16:18:15 | sean-k-mooney | we have centralised the executor interaction in nova.utils | |
| 16:19:04 | sean-k-mooney | but cool that sound like a real bug | |
| 16:19:32 | gibi | yeah I will check if I can spot why | |
| 16:21:22 | sean-k-mooney | https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L110-L147 | |
| 16:22:24 | sean-k-mooney | so its polling ever second https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L98-L108 | |
| 16:22:29 | sean-k-mooney | when its waitign for the work to complete | |
| 16:23:35 | sean-k-mooney | but its also joining the work thread https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L142 | |
| 16:24:01 | sean-k-mooney | but in your lamda case that should not be costly | |
| 16:24:16 | gibi | is it due to https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L103 | |
| 16:24:19 | gibi | ? | |
| 16:24:27 | gibi | there is a clear 1 sec timeout passed there | |
| 16:25:00 | sean-k-mooney | that what i was wondering too | |
| 16:25:13 | sean-k-mooney | but that get is in blockign mode with a max of 1 second | |
| 16:25:26 | sean-k-mooney | if the queue has a value it wont wait for one second | |
| 16:26:06 | sean-k-mooney | i was wondering if you coudl jsut monkeypatch https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L142 to 0.1 | |
| 16:26:14 | sean-k-mooney | if that woudl have any effect on the timeings | |
| 16:26:19 | sean-k-mooney | but i dont think it should | |
| 16:26:50 | gibi | yeah I'm about to try it :) | |
| 16:27:35 | sean-k-mooney | jsut looking at the code im not seeing nayting obviouly dumb like a hardcoded sleep or similar | |
| 16:29:28 | sean-k-mooney | so your tesitn calling shudown but do we call stop before we do that. i assume shutdown sill do that interenally | |
| 16:29:59 | sean-k-mooney | oh well stop is on the threadworker and shutdown is on the executor | |
| 16:30:04 | gibi | it is the problem | |
| 16:30:15 | gibi | if I set it to 0.1 then the shutdown is 10 times faster | |
| 16:30:33 | gibi | added a comment to the bug | |
| 16:31:30 | gibi | I will propose a patch top of Ashish's functional series to monkey patch that value in the test | |
| 16:31:32 | sean-k-mooney | oh | |
| 16:31:39 | sean-k-mooney | i know what happenign i think | |
| 16:31:51 | sean-k-mooney | so each tradwroker is waiting up to a secodn but we have 10 workers | |
| 16:32:05 | sean-k-mooney | and i bet when we call shutdown it loops over all of them serially | |
| 16:32:23 | sean-k-mooney | i.e. the executor is calling stop on each threqad worker one at a time | |
| 16:32:46 | sean-k-mooney | gibi: i bet if you double the worker count you will see it doubel coorect? | |
| 16:33:07 | gibi | nope I tried that adding more worker does not change the timing | |
| 16:34:01 | sean-k-mooney | huh weird | |
| 16:34:05 | sean-k-mooney | https://docs.python.org/3/library/queue.html#queue.Queue.get | |
| 16:35:41 | sean-k-mooney | it really is the upper bound | |
| 16:36:30 | gibi | but the queue is empty in this case as there is no work left. So it does wait 1 sec before it raises Empty | |
| 16:37:02 | gibi | and the shutdown logic only checked in the empty exception handler | |
| 16:37:02 | sean-k-mooney | yes | |
| 16:37:59 | gibi | so we need better logic. We need to wake up the queue during shutdown with a poison added to the queue | |
| 16:38:30 | gibi | or ignore this and just monkey patch the 1 sec to a small number from our test :) In production that 1 sec is totally OK during shutdown | |
| 16:39:33 | sean-k-mooney | https://github.com/openstack/futurist/blob/6f870896819197ca323b3dd8af8f3b0389aff69c/futurist/_futures.py#L224-L240 | |
| 16:40:23 | sean-k-mooney | gibi: so yes in the tests we can set ti to somethign smal for now | |