Wednesday, 2026-07-08

opendevreviewGhanshyam Maan proposed openstack/nova master: Fix intermittent 409 in TestGracefulShutdown tests  https://review.opendev.org/c/openstack/nova/+/99638100:51
gmaanmelwitt: sean-k-mooney ^^ i think this will fix the test_cold_migration_dest_compute_graceful_shutdown (i think revert resize test also have same issue ) failure00:53
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support by libvirt/QEMU  https://review.opendev.org/c/openstack/nova/+/99631602:59
opendevreviewminwoo seo proposed openstack/nova master: Add availability_zone support for migration  https://review.opendev.org/c/openstack/nova/+/97608505:22
opendevreviewminwoo seo proposed openstack/nova master: Add availability_zone support for migration  https://review.opendev.org/c/openstack/nova/+/97608505:25
opendevreviewminwoo seo proposed openstack/nova master: Add availability_zone support for migration  https://review.opendev.org/c/openstack/nova/+/97608505:31
opendevreviewminwoo seo proposed openstack/nova master: Add availability_zone support for migration  https://review.opendev.org/c/openstack/nova/+/97608505:31
opendevreviewminwoo seo proposed openstack/nova-specs master: Add spec for cross-AZ migration support  https://review.opendev.org/c/openstack/nova-specs/+/97620205:32
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99631606:27
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99631606:29
ralonsohhello folks, if you have a few minutes, please check https://review.opendev.org/c/openstack/os-vif/+/99593306:33
ralonsohthanks in advance!06:33
opendevreviewTakashi Kajinami proposed openstack/nova-specs master: Fix SEV-SNP feature detection in start up  https://review.opendev.org/c/openstack/nova-specs/+/99639406:34
opendevreviewTakashi Kajinami proposed openstack/nova-specs master: Use domain capability to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova-specs/+/99639506:39
gibigmaan: 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:13
opendevreviewminwoo seo proposed openstack/nova master: Add availability_zone support for migration  https://review.opendev.org/c/openstack/nova/+/97608508:37
rubasovhi nova folks: may I ask for a review on this bugfix (with a functional reproducer)? https://review.opendev.org/q/topic:bug/205168509:08
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99631609:40
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron networks  https://review.opendev.org/c/openstack/nova/+/92802210:33
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron networks  https://review.opendev.org/c/openstack/nova/+/92802210:58
tkajinammhen, can you share the full content of the firmware descriptor file in Ubuntu ?11:27
tkajinammhen, it's probably best to report a bug for ubuntu then add the link to it, just in case they fix that invalid descriptor11:27
tkajinaminstead of describing the whole details in the local doc11:28
opendevreviewTakashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99509011:47
opendevreviewTakashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests  https://review.opendev.org/c/openstack/nova/+/99512011:47
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99631611:47
opendevreviewTakashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99509011:51
opendevreviewTakashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests  https://review.opendev.org/c/openstack/nova/+/99512011:51
opendevreviewTakashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support  https://review.opendev.org/c/openstack/nova/+/99631611:51
opendevreviewAshish Gupta proposed openstack/placement master: tests: Support file-backed SQLite URL in placement fixtures  https://review.opendev.org/c/openstack/placement/+/99310612:06
opendevreviewAshish Gupta proposed openstack/nova master: tests: use file-backed Placement SQLite in functional threading  https://review.opendev.org/c/openstack/nova/+/99258112:21
*** chandank` is now known as chandankumar13:14
opendevreviewAshish Gupta proposed openstack/nova master: tests: Use per-database write locks instead of global lock  https://review.opendev.org/c/openstack/nova/+/99286214:50
UgglaReminder: Upstream bug triage in ~30mn.15:00
sean-k-mooneygibi oh actlly https://review.opendev.org/c/opendev/zuul-providers/+/996449 merged an hour ag15:15
sean-k-mooney*ago15:15
gibiack15:15
sean-k-mooneyso we shoudl not see failure in new jobs15:15
sean-k-mooneyUggla: url?15:34
Ugglahttps://meet.google.com/zjr-rxus-hzj 15:34
opendevreviewTakashi Kajinami proposed openstack/nova master: libvirt: Remove redundant version check for virtio-fs  https://review.opendev.org/c/openstack/nova/+/99649615:41
tkajinam^^^ wondering if we should check the virt type instead 15:41
sean-k-mooneywe woudl need to check for both qemu and kvm15:42
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
sean-k-mooneyi.e virtio fs shoudl wor for qemu and kvm15:42
sean-k-mooneysev maybe15:43
tkajinamsean-k-mooney, yeah and I don't think it may work for lxc for example15:43
sean-k-mooneyi dont know if that works for qemu or just with kvm15:43
sean-k-mooneywell for lxc we are not actully using a vm so i dont think sev works for contianer in general15:44
sean-k-mooneyyou can enabeld sev for all memoy at the host level but if you do that it used to break sriov15:44
tkajinamsev definitely requires kvm because it relies on the implementations in kvm_amd module. I'm not too sure about virtiofs on the other hand15:45
sean-k-mooneyi dont think that requires kvm15:45
sean-k-mooneybut ya for sev you could add checkign teh vrit type to the supprot crtiria15:46
sean-k-mooneyif its not already there15:46
tkajinamit's not, yet15:46
tkajinamthat's has never been added since sev support was first introduced.15:46
tkajinambecause that's an existing problem and may be trivial I'll look into that later, separately from sev-snp work15:47
sean-k-mooneywell if it does not work it would just fail to boot the vm15:47
tkajinamyeah15:47
sean-k-mooneyso its not really a regression to not report sev supprot when virt type is qemu15:47
sean-k-mooneytkajinam: if you can confim it i would just file a bug for it15:47
sean-k-mooneyhttps://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 removing15:48
tkajinamsean-k-mooney, I'll file one by my end15:49
tkajinamwe might want to change that check to virtio-fs to account virt_type, instead of just removing it.15:49
tkajinam(I'll record that as a separate bug, too15:49
opendevreviewTakashi Kajinami proposed openstack/nova master: Do not report SEV capability for non kvm virt_type  https://review.opendev.org/c/openstack/nova/+/99649816:07
gibisean-k-mooney: I think futurist is just slow to shut down an exector https://bugs.launchpad.net/futurist/+bug/216015916:16
sean-k-mooneyah ok16:17
sean-k-mooneyi mean we could actully swap to  concurrent.futures.ThreadPoolExecutor(max_workers=100) if needed16:17
sean-k-mooneywe have centralised the executor interaction in nova.utils16:18
sean-k-mooneybut cool that sound like a real bug16:19
gibiyeah I will check if I can spot why16:19
sean-k-mooneyhttps://github.com/openstack/futurist/blob/master/futurist/_thread.py#L110-L14716:21
sean-k-mooneyso its polling ever second https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L98-L10816:22
sean-k-mooneywhen its waitign for the work to complete16:22
sean-k-mooneybut its also joining the work thread https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L14216:23
sean-k-mooneybut in your lamda case that should not be costly16:24
gibiis it due to https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L10316:24
gibi?16:24
gibithere is a clear 1 sec timeout passed there16:24
sean-k-mooneythat what i was wondering too16:25
sean-k-mooneybut that get is in blockign mode with a max of 1 second16:25
sean-k-mooneyif the queue has a value it wont wait for one second16:25
sean-k-mooneyi was wondering if you coudl jsut monkeypatch https://github.com/openstack/futurist/blob/master/futurist/_thread.py#L142 to 0.116:26
sean-k-mooneyif that woudl have any effect on the timeings16:26
sean-k-mooneybut i dont think it should16:26
gibiyeah I'm about to try it :)16:26
sean-k-mooneyjsut looking at the code im not seeing nayting obviouly dumb like a hardcoded sleep or similar16:27
sean-k-mooneyso your tesitn calling shudown but do we call stop before we do that. i assume shutdown sill do that interenally16:29
sean-k-mooneyoh well stop is on the threadworker  and shutdown is on the executor16:29
gibiit is the problem16:30
gibiif I set it to 0.1 then the shutdown is 10 times faster16:30
gibiadded a comment to the bug16:30
gibiI will propose a patch top of Ashish's functional series to monkey patch that value in the test16:31
sean-k-mooneyoh16:31
sean-k-mooneyi know what happenign i think16:31
sean-k-mooneyso each tradwroker is waiting up to a secodn but we have 10 workers16:31
sean-k-mooneyand i bet when we call shutdown it loops over all of them serially16:32
sean-k-mooneyi.e. the executor is calling stop on each threqad worker one at a time16:32
sean-k-mooneygibi: i bet if you double the worker count you will see it doubel coorect?16:32
gibinope I tried that adding more worker does not change the timing16:33
sean-k-mooneyhuh weird 16:34
sean-k-mooneyhttps://docs.python.org/3/library/queue.html#queue.Queue.get16:34
sean-k-mooneyit really is the upper bound16:35
gibibut the queue is empty in this case as there is no work left. So it does wait 1 sec before it raises Empty16:36
sean-k-mooneyyes16:37
gibiand the shutdown logic only checked in the empty exception handler16:37
gibiso we need better logic. We need to wake up the queue during shutdown with a poison added to the queue16:37
gibior 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 shutdown16:38
sean-k-mooneyhttps://github.com/openstack/futurist/blob/6f870896819197ca323b3dd8af8f3b0389aff69c/futurist/_futures.py#L224-L24016:39
sean-k-mooneygibi: so yes in the tests we can set ti to somethign smal for now16:40
sean-k-mooneybut that for over the woekers16:40
sean-k-mooneywhere we call join is why i tought it would scale with teh worksers16:40
gibiI think we wait that 1 sec per worker in parallel for each worker16:41
opendevreviewMerged openstack/nova master: Fix intermittent 409 in TestGracefulShutdown tests  https://review.opendev.org/c/openstack/nova/+/99638116:41
sean-k-mooneysortof each worker will do that16:42
sean-k-mooneybut https://github.com/openstack/futurist/blob/6f870896819197ca323b3dd8af8f3b0389aff69c/futurist/_futures.py#L23716:42
sean-k-mooneywhen we call join there is seriailised16:42
sean-k-mooneyso we are taking the shutdwon lock, setting studwo to ture and waiting for the queu to drain, 16:44
gibiyes but join is not the one that triggers the wait for 1 sec. Join is just checks if the given thread is finished or not. At the first join we wait for 1 sec, then we see that the first thread finished, at the second join we see that the second thread already finished. etc16:44
sean-k-mooneythen notifying all workser to stop16:44
sean-k-mooneyand finally joining them all 16:44
gibiwe join serially but the thread wait for their own 1 sec in parallel16:44
gibi*threads16:44
sean-k-mooneyi think your correct16:46
sean-k-mooneyim just not sure why we see the wait16:46
gibianyhow I will dig deeper tomorrow. The last thing I do today is put a patch up to nova to nuke this 1 sec in the test16:47
opendevreviewBalazs Gibizer proposed openstack/nova master: HACK:Speed up functional test in threading mode  https://review.opendev.org/c/openstack/nova/+/99650016:57
sean-k-mooneygibi: i might quickly hack on somehting, if i push anything ill add you to it and you can free free to udpate it or push your own fix16:57
gibiOK thanks16:57
sean-k-mooneyim basiclly goign to ask ai to reporduce your finding in a test case and then see if it can rootcause it16:57
gibihttps://review.opendev.org/c/openstack/nova/+/996500 for me locally re-gains all the lost time in the threading mode16:57
gibisean-k-mooney: OK cool16:57
opendevreviewBalazs Gibizer proposed openstack/nova master: HACK:Speed up functional test in threading mode  https://review.opendev.org/c/openstack/nova/+/99650016:58
sean-k-mooneyalso cool lets see how that ^ goes in ci over night16:58
gibiyepp16:58
gibidropping now16:58
gibisee you tomorrow16:58
opendevreviewThibaut Démaret proposed openstack/nova master: libvirt: add disk rotation_rate support for local disks  https://review.opendev.org/c/openstack/nova/+/97969317:42
melwittI have a patch that has been up for a while with one +2, to make QEMU_IMG_LIMITS configurable if anyone might be interested https://review.opendev.org/c/openstack/nova/+/969538 this came from an old upstream CI issue where the image limit was too low for an encrypted disk with ceph18:45
sean-k-mooneymelwitt: so while that helps20:22
sean-k-mooneywe proably shoudl fix the memory limit if we are doign this20:22
sean-k-mooneymelwitt: currently we are limiting on adress space but we shoudl be limiting on RSS20:22
melwitthm ok .. I am not yet familiar with that20:23
sean-k-mooneyaddress space is how much well adrsss space that is mapped into the process with or without actual memory usage20:24
sean-k-mooneyRSS is residnet set size20:24
sean-k-mooneyi.e. how much actual memory is being used 20:24
sean-k-mooneyin ci with some config we were seing newver version fo ceph/rbd map alot of memory without actully usign a lot of memroy20:25
melwittoh I see20:25
sean-k-mooneyhttps://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L16220:25
melwitta-ha20:26
melwittso you think if we just s/address_space/resident_set_size/20:27
melwittlooks like rss has been a choice as long as address space ... so it is not a newly available choice. yet it has not been used20:27
melwittI wonder if that was deliberate20:27
sean-k-mooneyi would just sed it yes20:28
melwittlooks like no one is using it, huh. https://codesearch.openstack.org/?q=resident_set_size&i=nope&literal=nope&files=&excludeFiles=&repos=20:29
sean-k-mooneyso i moved the ceph jobs to debian to work around it https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/955714 and proposed a reviert of the tempest skip https://review.opendev.org/c/openstack/tempest/+/95517720:31
sean-k-mooneybut we never actully merge the tempest skip reviert20:31
melwittyeah, I remembered that. I had wondered what the "real fix" should be20:32
sean-k-mooneyi +1 your patch becasue we coudl proceed with it, i think movign to rss instead fo adresss space woudl make sense btu let see if gibi has or somoen else has an opion20:33
sean-k-mooneymelwitt: im not agaisnt makign it configurabl i just dont think that the correct limit to use in this case in general20:34
sean-k-mooneybut we coudl change that in a followup20:34
melwittsure. I'm also happy to just change it to resident_set_size if there is no potential bad thing about that haha20:35
melwittI am a bit wondering why no one has made use of it before20:35
sean-k-mooneywell almost nothign uses this in general https://codesearch.openstack.org/?q=ProcessLimits&i=nope&literal=nope&files=&excludeFiles=&repos=20:36
sean-k-mooneyand i think the code was cargo culted form nova to the rest20:36
sean-k-mooneytweaking the adress space limit will allow more meory to be used like rss would20:37
melwittnova trend setter20:37
sean-k-mooneybut you may have to set it higher then otherwise20:37
melwittyeah. I mostly saw how cinder and ironic both doing it20:38
sean-k-mooneyyou know what ill appove your current patch but lets chat about this more20:38
sean-k-mooneyyour currrent patch matches cinder and ironics approch20:38
sean-k-mooneyso if it works for them it will proably be fine20:39
melwittit's ok, I don't mind chatting for rss20:39
sean-k-mooneyok but lets check back tomorrow so we dont forget :)20:39
melwittI feel like dan would have a good input for this but I think he's away until next week20:40
sean-k-mooneygmaan: related to ^ i rebased https://review.opendev.org/c/openstack/tempest/+/955177 to get new results20:40
sean-k-mooneyok im goign to go eat dinner o/20:41
melwittok seeya o/20:41
gmaansean-k-mooney: ack20:48
opendevreviewGhanshyam Maan proposed openstack/nova master: Task tracking mechanism for graceful shutdown  https://review.opendev.org/c/openstack/nova/+/99629921:38
opendevreviewMerged openstack/nova master: Rename cyborg-tempest to cyborg-tempest-py3  https://review.opendev.org/c/openstack/nova/+/99629721:57
opendevreviewAshish Gupta proposed openstack/nova master: tests: file-backed SQLite with WAL in threading mode for Database and CellDatabases Fixtures  https://review.opendev.org/c/openstack/nova/+/98858323:18
opendevreviewAshish Gupta proposed openstack/nova master: tests: use file-backed Placement SQLite in functional threading  https://review.opendev.org/c/openstack/nova/+/99258123:24
opendevreviewAshish Gupta proposed openstack/nova master: tests: Use per-database write locks instead of global lock  https://review.opendev.org/c/openstack/nova/+/99286223:27

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!