Earlier  
Posted Nick Remark
#openstack-nova - 2025-10-01
10:46:07 sean-k-mooney https://github.com/openstack/nova/blob/b99a882366251f88d145e27312b94692e0b2266f/nova/tests/unit/virt/libvirt/volume/test_mount.py#L583
10:46:25 bauzas yup, there are examples, I just forgot them
10:46:28 sean-k-mooney so we typicly do that in a buch of place for unit test but it shoudl work the same for functional
10:46:50 bauzas mocking LOG is the right pattern for debug logs then, I forgot it
10:47:03 bauzas thanks
10:47:13 sean-k-mooney no worries
10:47:54 sean-k-mooney i also often just end up trying one way then the ohter depending on which works
10:48:07 sean-k-mooney i prefer ot not mock if i can avoid it but its just simpler in this case
12:23:17 opendevreview Kamil Sambor proposed openstack/nova master: [hacking] Improve N373 to catch also other primitives https://review.opendev.org/c/openstack/nova/+/958408
13:27:18 opendevreview Thomas Goirand proposed openstack/nova-specs master: Restrict booting from volume with disk https://review.opendev.org/c/openstack/nova-specs/+/960513
13:57:55 opendevreview Kamil Sambor proposed openstack/nova master: [hacking] Improve N373 to catch also other primitives https://review.opendev.org/c/openstack/nova/+/958408
14:28:41 opendevreview Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657
20:04:44 opendevreview Merged openstack/nova master: Centralize cooperative yield https://review.opendev.org/c/openstack/nova/+/950991
20:24:33 opendevreview Merged openstack/nova master: [hacking] N374 do not use time.sleep(0) to yield https://review.opendev.org/c/openstack/nova/+/950992
20:51:01 opendevreview melanie witt proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795
20:51:01 opendevreview melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502
20:51:02 opendevreview melanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483
20:51:02 opendevreview melanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData https://review.opendev.org/c/openstack/nova/+/952628
20:51:03 opendevreview melanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021
20:51:03 opendevreview melanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration https://review.opendev.org/c/openstack/nova/+/962051
20:51:04 opendevreview melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771
20:51:05 opendevreview melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975
20:51:05 opendevreview melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629
20:51:07 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
20:51:07 opendevreview melanie witt proposed openstack/nova master: Opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052
23:51:20 opendevreview melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477
#openstack-nova - 2025-10-02
07:15:21 jlejeune1 hello, 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 :)
09:43:24 opendevreview Balazs Gibizer proposed openstack/placement master: Reproduce GET a_c slowness https://review.opendev.org/c/openstack/placement/+/962596
09:43:25 opendevreview Balazs Gibizer proposed openstack/placement master: Prune search space with invalid prefixes https://review.opendev.org/c/openstack/placement/+/962776
09:43:25 opendevreview Balazs Gibizer proposed openstack/placement master: Remove excessive logging from GET a_c https://review.opendev.org/c/openstack/placement/+/962775
09:45:05 gibi dansmith: 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 possible
09:45:33 gibi I just need proof first that it helps my customer as well
09:46:17 sean-k-mooney[m] cool ill take a look
09:46:54 sean-k-mooney[m] ugly and works reliably is better then broken at least in the short to medium term
09:49:03 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 landed
09:52:51 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 strings
09:56:44 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 back
10:02:37 stephenfin gibi: sean-k-mooney[m]: Can you review this test-only change? https://review.opendev.org/c/openstack/nova/+/951744
10:03:31 stephenfin I'm trying to remove keystoneclient from keystonemiddleware, and lajoskatona is trying to remove python-neutronclient, so this will (hopefully) break at some point
10:54:28 sean-k-mooney ack that makes sense to me
11:05:17 gibi sean-k-mooney[m]: I agree. I will move the assisted by tag to the commit message
11:06:06 gibi stephenfin: +2+A
11:06:16 stephenfin ty
11:31:43 sean-k-mooney gibi: sambork: https://review.opendev.org/c/openstack/nova/+/962478/2 see comment in line i think we are leakying that executor between test runs
11:32:12 sean-k-mooney im happy to proceed with teh first 2 nova-conductor native threading patchs for what its worth but the third i think has a bug
11:49:22 gibi sean-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 ?
12:07:51 opendevreview Merged openstack/nova master: tests: Replace keystoneclient with keystoneauth1 https://review.opendev.org/c/openstack/nova/+/951744
12:16:15 zigo stephenfin: Thanks for taking over https://review.opendev.org/c/openstack/python-openstackclient/+/962487 !
12:16:19 zigo Much appreciated.
12:16:42 stephenfin nw, actually need to approve that
13:40:28 opendevreview Merged openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088
14:03:24 opendevreview Takashi Kajinami proposed openstack/placement master: Remove remaining basepython https://review.opendev.org/c/openstack/placement/+/962804
14:04:26 opendevreview Takashi Kajinami proposed openstack/os-traits master: Drop basepython https://review.opendev.org/c/openstack/os-traits/+/962805
14:04:49 opendevreview Takashi Kajinami proposed openstack/os-resource-classes master: Drop basepython https://review.opendev.org/c/openstack/os-resource-classes/+/962806
14:05:29 opendevreview Takashi Kajinami proposed openstack/os-resource-classes master: Drop basepython https://review.opendev.org/c/openstack/os-resource-classes/+/962806
14:05:45 opendevreview Takashi Kajinami proposed openstack/os-traits master: Drop basepython https://review.opendev.org/c/openstack/os-traits/+/962805
14:10:45 tkajinam anyone 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:17:08 sean-k-mooney done
14:17:22 sean-k-mooney well for the last 2
14:17:27 gibi done
14:17:34 gibi ahh
14:17:38 tkajinam thanks both !
14:17:44 gibi :)
14:18:14 sean-k-mooney the basepython thing we can do
14:18:22 sean-k-mooney but it also will nto break anything if we never do it
14:18:44 sean-k-mooney so ill look at it eventually but i need to go rebase things
14:18:55 sean-k-mooney so ill try to remember to loop back
14:24:21 opendevreview Merged openstack/os-resource-classes master: Drop unnecessary 'x' bit from doc config file https://review.opendev.org/c/openstack/os-resource-classes/+/932878
14:31:56 opendevreview Merged openstack/os-resource-classes master: Replace UPPER_CONSTRAINTS_FILE https://review.opendev.org/c/openstack/os-resource-classes/+/947488
15:50:25 opendevreview Merged openstack/os-traits master: Drop basepython https://review.opendev.org/c/openstack/os-traits/+/962805
15:55:17 opendevreview Merged openstack/nova master: Run nova-conductor in native threading mode https://review.opendev.org/c/openstack/nova/+/958575
16:18:33 lajoskatona sean-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 anymore
16:18:51 lajoskatona sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#b3099
16:20:14 lajoskatona as 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:53 lajoskatona sean-k-mooney: am I thinking the right way or I am totally lost in how these API exceptions work?
16:22:57 lajoskatona I 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#L62
16:25:22 lajoskatona I 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:27:14 sean-k-mooney lajoskatona: ack reading back
16:28:05 lajoskatona so 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 message
16:28:41 lajoskatona sean-k-mooney: thanks, it is a summary for myself also to not forget it for tomorrow :-)
16:28:57 sean-k-mooney lajoskatona: i belive you are correct that is is realted to the porxy apis
16:29:10 sean-k-mooney nova does not to my knowlage allcoate floating ips internally
16:29:22 sean-k-mooney so i cant think of any other reasonable usage of those methods
16:30:01 lajoskatona sean-k-mooney: ack, so the possibility that I break something important is lower :-)
16:30:15 lajoskatona that is always good news ....
16:32:21 sean-k-mooney yep
16:33:06 sean-k-mooney the 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 it
16:33:40 sean-k-mooney so 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 better
17:06:28 noonedeadpunk hey folks! I've spotted that there's a spec regarding iothreads for virto-blk lying here: https://review.opendev.org/c/openstack/nova-specs/+/951636
17:06:43 noonedeadpunk which should be placed to 2026.1 I guess
17:06:51 noonedeadpunk But I have a different, but related question
17:07:33 noonedeadpunk I've spotted there's also an scsi blueprint without spec: https://blueprints.launchpad.net/nova/+spec/libvirt-add-support-for-virtio-scsi-multiqueue
17:09:19 noonedeadpunk it seems that these 2 should not be conflicting with each other and I assume both can be implemented?
17:11:14 noonedeadpunk as 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 there
17:16:15 noonedeadpunk jsut trying to validate if I'm sane and can proceed to working on spec :)
17:16:27 noonedeadpunk (or it could be specless one)
17:17:39 dansmith noonedeadpunk: we have at least three things that are all related, so probably best to have a PTG discussion on it
17:18:02 dansmith domain iothreads, device iothread pinning, and any of these queue things are probably related enough to combine into a single conversation
17:18:05 noonedeadpunk also ports multique I guess?
17:18:16 noonedeadpunk yeah

Earlier   Later