Friday, 2025-12-05

melwittdid anyone else stop receiving gerrit email notifications after about 4 hours ago?01:43
*** mhen_ is now known as mhen02:17
opendevreviewMerged openstack/nova master: libvirt: add configuration option for volume AIO mode  https://review.opendev.org/c/openstack/nova/+/96484805:20
opendevreviewBalazs Gibizer proposed openstack/nova master: Fix missing guest.migrate(parallel=) mock arg  https://review.opendev.org/c/openstack/nova/+/96950309:10
opendevreviewBalazs Gibizer proposed openstack/nova master: Collect result of _live_migration_operation  https://review.opendev.org/c/openstack/nova/+/96950109:10
gibiUggla: I'm not sure anything is left tirageing in https://etherpad.opendev.org/p/nova-bug-triage-roster#L24 Does that duplicted bug shows up in your query as untriaged? It should not. As it is connected to another bug as duplicate and that bug is fixed09:45
Ugglagibi, if you set it as duplicate that's fine. It should not appear anymore.09:53
noonedeadpunkhey folks! do you know if passing of any of these flags are supproted by nova? https://www.qemu.org/docs/master/system/i386/hyperv.html10:10
noonedeadpunkI guess not, unless I'm missing a way to pass something completely arbitrary...10:11
gibiUggla: it is set as duplicate since 2025-07-29 hence my question10:12
Ugglagibi, oh ok that's probably because I get the bugs from a previous doc I did, not fresh at all. Sorry about that.10:14
gibino worries10:14
gibithanks for organizing the triage10:14
gibinoonedeadpunk: appreantly yes, based on the fields here we have set of enlightments https://github.com/openstack/nova/blob/1712ae48e3111e0a2c178b9d601572d624a56374/nova/virt/libvirt/config.py#L296410:15
gibinoonedeadpunk: https://github.com/openstack/nova/blob/1712ae48e3111e0a2c178b9d601572d624a56374/nova/virt/libvirt/driver.py#L6678 you need set os_type10:17
noonedeadpunkhuh10:17
noonedeadpunkOk, so it's done on it's own, nice!10:17
noonedeadpunkthanks gibi!10:17
gibihttps://docs.openstack.org/glance/latest/admin/useful-image-properties.html10:17
noonedeadpunkyeah, I knew about os_type, but I didn't know about hidden logic behind it:)10:18
noonedeadpunkwill propose documentation update probably :)10:19
gibinoonedeadpunk: thanks10:19
opendevreviewBalazs Gibizer proposed openstack/nova master: Upgrade note for concurrency mode default change  https://review.opendev.org/c/openstack/nova/+/96988810:32
gibigmaan: sean-k-mooney: dansmith: ^^ this is what I come up with based on the discussion about the upgrade impact of eventlet removal and our default mode change in G 10:33
opendevreviewLajos Katona proposed openstack/nova master: WIP: Use SDK for Neutron Ports  https://review.opendev.org/c/openstack/nova/+/96929810:54
sean-k-mooneygibi: im not sure i agree with the recommendation to decouple the cahnge in mode in gerneal but its a more reasonable recomendtion for slurp upgrades11:00
sean-k-mooneyi dont really think we shoudl be recommendign that operators every use the env var out side of optin in to threadign to test early 11:01
sean-k-mooneyit does exist as an escape hatch if we messed up11:02
sean-k-mooneyso i dont object to it existing just that for me makeing the swtich trasnparent  to the end user is very imporant but i get the performance tuning concern11:03
sean-k-mooneygibi: do we know if any of the larger operators have started testign treading mode since the 2025.2 release?11:03
opendevreviewWill Szumski proposed openstack/nova master: WIP: Adds regression test for bug LP#2132984  https://review.opendev.org/c/openstack/nova/+/96938011:15
opendevreviewWill Szumski proposed openstack/nova master: Fix race betweem instance claim and anti affinity check  https://review.opendev.org/c/openstack/nova/+/96989411:15
gibisean-k-mooney: I got no indication if any large operator testing or tested threading mode in nova12:14
gibisean-k-mooney: I think one of the main reason to have a way to switch between modes is to avoid big bang integration of the threading mode during upgrade. Especially due to the performance tuning needs.12:16
gibisean-k-mooney: if it helps then I can try to give an oslo config flag instead of a env variable, but I don't see a good ROI of that at the moment12:16
sean-k-mooneyso that was explcit not a goal for me because i saw it as a failure on our part if operatos needed to think about htis to that degree12:17
sean-k-mooneyie.. the uptrade shoudl be tansparent becuase we shoudl get the default right before chanigng them12:17
sean-k-mooneybut ya i dont think we need to make it an oslo config12:18
sean-k-mooneyim just really hoping that most operator will upgrade form 2026.1 to 2027.1 and not notice that we changed the threadning mode12:18
gibithe problem for me is that I cannot define good default that will work for differntly sized and shaped deployments12:19
gibiin the past we used large numbers as pool size so that covered a wide range of deployments12:19
gibiwith threading we cannot use those large numbers any more without consequences12:19
sean-k-mooneyyep i understand. given we only supprot say 10 boot operation on a server or a limite number of migraton ectra i think the small numbers for the comptue are actully likely to be reasonble12:26
sean-k-mooneyfor the api the scaling mode has alwasy been mainly via proceses,12:27
sean-k-mooneythe schduler and conductor are probaly the ones i woudl be most concerned with12:27
sean-k-mooneyboth are horizontally scable and virtucally scalabel with workers but ya they may need different tuneing12:28
sean-k-mooneygibi: i am quitely hopeful that we will see a similar uplift in performance that ironic saw although we may have been using less problematic patterns12:28
gibiscatter gather across multi cell clouds will not scale by scaling the nova-api process 12:58
gibiit will only scale if you scale the number of threads close to the number of cells in the threadpool12:58
opendevreviewBalazs Gibizer proposed openstack/nova master: Enable mypy on nova/utils.py  https://review.opendev.org/c/openstack/nova/+/96993614:16
dansmithbauzas: can you +W this trivial one-liner mock fix? https://review.opendev.org/c/openstack/nova/+/96950315:01
dansmithwe didn't catch it on initial merge because of the bug fixed by the patch above it15:01
bauzasack15:02
dansmiththanks15:02
dansmiththe patch above would be nice too, but not as trivial15:03
gmaangibi: ack, will take  alook today16:33
gmaanbauzas: gibi sean-k-mooney I think +w was missed until something we are waiting for, otherwise, can either of you please hit +w https://review.opendev.org/c/openstack/nova-specs/+/96954316:34
sean-k-mooneygmaan: well for the backlog spec i guess16:53
gmaansean-k-mooney: did not get? this is in the backlog spec17:06
JayFStable backport of an Ironic bugfix, cleanly applied, V+1 already, for your consideration: https://review.opendev.org/c/openstack/nova/+/96983317:33
sean-k-mooneygmaan: we are now techinically past spec freeze but given that is a backlog spec change that was +2id but not +w to allow folks to review i think we can proceed with it17:38
opendevreviewMerged openstack/nova master: Fix missing guest.migrate(parallel=) mock arg  https://review.opendev.org/c/openstack/nova/+/96950317:44
opendevreviewMerged openstack/nova-specs master: Add spec3 in graceful shutdown backlog spec  https://review.opendev.org/c/openstack/nova-specs/+/96954317:47
opendevreviewsean mooney proposed openstack/nova-specs master: add spec for resource tracker notifications  https://review.opendev.org/c/openstack/nova-specs/+/96771218:09
opendevreviewMerged openstack/nova master: Collect result of _live_migration_operation  https://review.opendev.org/c/openstack/nova/+/96950118:10
opendevreviewmelanie witt proposed openstack/nova master: Make QEMU_IMG_LIMITS process limits configurable  https://review.opendev.org/c/openstack/nova/+/96953818:38
melwittgibi: changed to Closes-Bug ^ and added a few more words to the commit message18:40
gmaansean-k-mooney: yeah, that is my understanding too. 19:06
opendevreviewmelanie witt proposed openstack/nova master: Make QEMU_IMG_LIMITS process limits configurable  https://review.opendev.org/c/openstack/nova/+/96953820:42

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