Earlier  
Posted Nick Remark
#openstack-nova - 2026-07-08
05:31:01 opendevreview minwoo seo proposed openstack/nova master: Add availability_zone support for migration https://review.opendev.org/c/openstack/nova/+/976085
05:31:36 opendevreview minwoo seo proposed openstack/nova master: Add availability_zone support for migration https://review.opendev.org/c/openstack/nova/+/976085
05:32:29 opendevreview minwoo seo proposed openstack/nova-specs master: Add spec for cross-AZ migration support https://review.opendev.org/c/openstack/nova-specs/+/976202
06:27:03 opendevreview Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316
06:29:03 opendevreview Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316
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: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090
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: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: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120
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
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 sean-k-mooney yes

Earlier   Later