Thursday, 2025-10-02

*** mhen_ is now known as mhen01:08
jlejeune1hello, now that 2025.2 is out, I would like to have new reviews for my backports please: https://review.opendev.org/q/topic:%22bug-2044235%22 :)07:15
opendevreviewBalazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness  https://review.opendev.org/c/openstack/placement/+/96259609:43
opendevreviewBalazs Gibizer proposed openstack/placement master: Remove excessive logging from GET a_c  https://review.opendev.org/c/openstack/placement/+/96277509:43
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune search space with invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277609:43
gibidansmith: sean-k-mooney: ^^ this helps if we keep max_allocation_candidates <= 1000 . I will test it in devstack next. I know that it is uggly and I have intention to clean it up as much as possible09:45
gibiI just need proof first that it helps my customer as well09:45
sean-k-mooney[m]cool ill take a look09:46
sean-k-mooney[m]ugly and works reliably is better then broken at least in the short to medium term09:46
sean-k-mooney[m]without buying in to any of the graphql hype i do wonder if there are larger refactors we may want to look at eventually. i know there was an experimetn to see if more could be done in sql in the past bt i dont know if that ever landed09:49
sean-k-mooney[m]gibi: one comment can you keep the assisted-By in the commit message only. i really dont think that belongs in commetnt or doc strings09:52
sean-k-mooney[m]gibi also that is not that ugly you just created your own product generatior, when you said ugly i was expectign somthing much more hack ish although im not a huge fan of the while true. i need to step away breifly but ill read it propler when i get back09:56
stephenfingibi: sean-k-mooney[m]: Can you review this test-only change? https://review.opendev.org/c/openstack/nova/+/95174410:02
stephenfinI'm trying to remove keystoneclient from keystonemiddleware, and lajoskatona is trying to remove python-neutronclient, so this will (hopefully) break at some point10:03
sean-k-mooneyack that makes sense to me10:54
gibisean-k-mooney[m]: I agree. I will move the assisted by tag to the commit message11:05
gibistephenfin: +2+A11:06
stephenfinty11:06
*** mhen_ is now known as mhen11:15
sean-k-mooneygibi: sambork: https://review.opendev.org/c/openstack/nova/+/962478/2 see comment in line i think we are leakying that executor between test runs11:31
sean-k-mooneyim happy to proceed with teh first 2 nova-conductor native threading patchs for what its  worth but the third i think has a bug11:32
gibisean-k-mooney: lets procede with the first two for now while Kamil checks the refactor. dansmith could you review https://review.opendev.org/c/openstack/nova/+/962478 ?11:49
opendevreviewMerged openstack/nova master: tests: Replace keystoneclient with keystoneauth1  https://review.opendev.org/c/openstack/nova/+/95174412:07
zigostephenfin: Thanks for taking over https://review.opendev.org/c/openstack/python-openstackclient/+/962487 !12:16
zigoMuch appreciated.12:16
stephenfinnw, actually need to approve that12:16
* stephenfin does the necessary12:16
opendevreviewMerged openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor  https://review.opendev.org/c/openstack/nova/+/95708813:40
opendevreviewTakashi Kajinami proposed openstack/placement master: Remove remaining basepython  https://review.opendev.org/c/openstack/placement/+/96280414:03
opendevreviewTakashi Kajinami proposed openstack/os-traits master: Drop basepython  https://review.opendev.org/c/openstack/os-traits/+/96280514:04
opendevreviewTakashi Kajinami proposed openstack/os-resource-classes master: Drop basepython  https://review.opendev.org/c/openstack/os-resource-classes/+/96280614:04
opendevreviewTakashi Kajinami proposed openstack/os-resource-classes master: Drop basepython  https://review.opendev.org/c/openstack/os-resource-classes/+/96280614:05
opendevreviewTakashi Kajinami proposed openstack/os-traits master: Drop basepython  https://review.opendev.org/c/openstack/os-traits/+/96280514:05
tkajinamanyone care to merge these trivial changes ? https://review.opendev.org/c/openstack/os-resource-classes/+/947488 https://review.opendev.org/c/openstack/os-resource-classes/+/932878 14:10
sean-k-mooneydone14:17
sean-k-mooneywell for the last 214:17
gibidone14:17
gibiahh14:17
tkajinamthanks both !14:17
gibi:)14:17
sean-k-mooneythe basepython thing we can do14:18
sean-k-mooneybut it also will nto break anything if we never do it14:18
sean-k-mooneyso ill look at it eventually but i need to go rebase things14:18
sean-k-mooneyso ill try to remember to loop back14:18
opendevreviewMerged openstack/os-resource-classes master: Drop unnecessary 'x' bit from doc config file  https://review.opendev.org/c/openstack/os-resource-classes/+/93287814:24
opendevreviewMerged openstack/os-resource-classes master: Replace UPPER_CONSTRAINTS_FILE  https://review.opendev.org/c/openstack/os-resource-classes/+/94748814:31
opendevreviewMerged openstack/os-traits master: Drop basepython  https://review.opendev.org/c/openstack/os-traits/+/96280515:50
opendevreviewMerged openstack/nova master: Run nova-conductor in native threading mode  https://review.opendev.org/c/openstack/nova/+/95857515:55
lajoskatonasean-k-mooney: after some desperate reading in n-client, neutron and nova I think the exotic exceptions like IpAddressGenerationFailureClient & ExternalIpAddressExhaustedClient and all similar ones are not really used anymore16:18
lajoskatonasean-k-mooney: https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#b309916:18
lajoskatonaas I see the method allocate_floating_ip is only called from nova/api/openstack/compute/floating_ips.py which is if I understand well is the deprecated FIP API in Nova which calls to Neutron (https://docs.openstack.org/api-ref/compute/#floating-ips-os-floating-ips-deprecated )16:20
lajoskatonasean-k-mooney: am I thinking the right way or I am totally lost in how these API exceptions work?16:20
lajoskatonaI checked on the Neutron side and for IpAddressGenerationFailureClient for example that catches the Neutron ipam http "exception" https://opendev.org/openstack/neutron/src/branch/master/neutron/ipam/exceptions.py#L6216:22
lajoskatonaI am not sure how that is done to tell the truth, but anyway the Neutron ipam IpAddressGenerationFailure 's base is Conflict so I can check the inside of the SDK ConflictException to check for msg "No more IP addresses available for subnet..."16:25
sean-k-mooneylajoskatona: ack reading back16:27
lajoskatonaso summary (I think) 1.) part of these exception consumer methods are for  deprecated Nova APIs (/os-floating-ips) 2.) it seems that as Neutron packs the msg of the http rsp with definite msg (like "No more IP addresses available for subnet....") I can catch these messages and raise different nova exceptions back based on the message16:28
lajoskatonasean-k-mooney: thanks, it is a summary for myself also to not forget it for tomorrow :-)16:28
sean-k-mooneylajoskatona: i belive you are correct that is is realted to the porxy apis 16:28
sean-k-mooneynova does not to my knowlage allcoate floating ips internally16:29
sean-k-mooneyso i cant think of any other reasonable usage of those methods16:29
lajoskatonasean-k-mooney: ack, so the possibility that I break something important is lower :-)16:30
lajoskatonathat is always good news ....16:30
sean-k-mooneyyep16:32
sean-k-mooneythe other thing to consier is while the error code is part of the api contract the exact details of the error message isnt nessisarly part of it16:33
sean-k-mooneyso if we anted to make these proxy apis bevhve a little more like neturon wew could but if we can do the convertion without a visible impact that is stil probly better16:33
noonedeadpunkhey folks! I've spotted that there's a spec regarding iothreads for virto-blk lying here: https://review.opendev.org/c/openstack/nova-specs/+/95163617:06
noonedeadpunkwhich should be placed to 2026.1 I guess17:06
noonedeadpunkBut I have a different, but related question17:06
noonedeadpunkI've spotted there's also an scsi blueprint without spec: https://blueprints.launchpad.net/nova/+spec/libvirt-add-support-for-virtio-scsi-multiqueue17:07
noonedeadpunkit seems that these 2 should not be conflicting with each other and I assume both can be implemented?17:09
noonedeadpunkas if I'm not mistaken, that Windows virtio-blk driver is always a single queue, so the way to get any disk performance on windows would be to have scsi and multiqueue there17:11
noonedeadpunkjsut trying to validate if I'm sane and can proceed to working on spec :)17:16
noonedeadpunk(or it could be specless one)17:16
dansmithnoonedeadpunk: we have at least three things that are all related, so probably best to have a PTG discussion on it17:17
dansmithdomain iothreads, device iothread pinning, and any of these queue things are probably related enough to combine into a single conversation17:18
noonedeadpunkalso ports multique I guess?17:18
noonedeadpunkyeah17:18
noonedeadpunkfair enough17:18
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747719:47
sean-k-mooneynoonedeadpunk: https://review.opendev.org/c/openstack/nova-specs/+/953940 i sthe related one that we created to try and scope down the propsoal to make some progres in 2025.2 but that also got hit by spec freeze20:10
sean-k-mooneynoonedeadpunk: im hoping that Masahito will pick up the prosal again this cycle if they have time20:11
sean-k-mooneythis was the other thing they were interested in https://review.opendev.org/c/openstack/nova-specs/+/93882320:12
sean-k-mooneyso there multiple iothreds, mapping disk queues to iothread and filterign service by netwrok id20:14
sean-k-mooneyi dont know which is there priority20:14
sean-k-mooneynoonedeadpunk: im just siging off for today but i assuem you want to progress the live migration concurncy feture as well in 2026.120:15
sean-k-mooneyi know there was some code up for that but i lost track for where that review was20:16
sean-k-mooneynoonedeadpunk: this was your spec for that https://review.opendev.org/c/openstack/nova-specs/+/95578320:16
sean-k-mooneybut i also belive there was a specless blueprint approved indepently?20:17
sean-k-mooneythis was your bluepint https://blueprints.launchpad.net/nova/+spec/libvirt-parallel-migrate but https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-parallel20:18
sean-k-mooneywas appoved then deferd20:18
sean-k-mooneynoonedeadpunk: so we currently have two competing propsoals for this one form you and another form Fabian Wiesel20:20
sean-k-mooneynoonedeadpunk: given they have revierd and +1 your versiohn i assume yours is the one that we inteded ot proceed with but we shoudl abandon one fo them and if decied if its goign to be specless or requrie a spec 20:22
sean-k-mooneyUggla: fyi ^ do you have any prefernce on which of the two blueprint we use and if we want to proceed specless or not20:24
melwittsean-k-mooney: do you happen to know if this needs to be changed to something else, perhaps devstack@q-ovn-metadata-agent ? now that q-agt is not used? https://github.com/openstack/nova/blob/master/roles/run-evacuate-hook/tasks/main.yaml#L2420:34
melwittI'm working on vtpm tempest tests and noticed the error "controller | Unit devstack@q-agt.service could not be found." in the zuul stream20:35
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747723:10
opendevreviewmelanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration  https://review.opendev.org/c/openstack/nova/+/96288923:10
opendevreviewmelanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration  https://review.opendev.org/c/openstack/nova/+/96288923:21
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747723:21

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