Earlier  
Posted Nick Remark
#openstack-nova - 2025-05-06
16:16:28 sean-k-mooney cool
16:16:38 gmaan yeah ^^
16:17:12 gmaan sometime we need to refactor test but not bug deal.
16:17:46 gmaan that is all on these, fell free to review, as I am only active core in tempest I will merge them but keep it open for sometime if anyone would like to review
16:18:14 gmaan most probably, i will keep all fixs open till job is green
16:18:14 Uggla thx gmaan
16:19:12 Uggla #topic Release Planning
16:19:19 Uggla #link https://releases.openstack.org/flamingo/schedule.html
16:19:24 Uggla #link https://releases.openstack.org/flamingo/schedule.html
16:19:56 Uggla The patch about nova deadlines has been merged so I think it is ok.
16:20:41 Uggla Please let me know if it is not the case or if something is wrong.
16:20:59 Uggla #topic Review priorities
16:21:06 Uggla #link https://etherpad.opendev.org/p/nova-2025.2-status
16:22:00 Uggla I'd like to progress on openapi and I'll try to check with stephenfin about it.
16:22:52 Uggla #topic Stable Branches
16:23:09 Uggla elodilles, the mic is yours
16:23:19 elodilles thanks Uggla , so
16:23:22 elodilles #info stable/2023.2 (bobcat) is End of Life, branch is deleted (tag: bobcat-eol)
16:23:31 elodilles #info maintained stable branches: stable/2025.1, stable/2024.2, stable/2024.1
16:23:49 elodilles down to 3 maintained branches again ;)
16:24:02 elodilles #info nova stable release from stable/2024.1 is out (29.2.1)
16:24:15 elodilles #info not aware of any stable gate failure
16:24:30 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:24:54 elodilles we had a broken gate on stable/2025.1 osc-placement,
16:25:07 elodilles but it is now fixed
16:25:15 elodilles thanks all for the help :)
16:25:30 elodilles and i think that's all from me
16:25:36 elodilles Uggla: back to you
16:25:39 Uggla elodilles, fyi 947847: nova: Release 2024.2 Dalmatian 30.0.1 | https://review.opendev.org/c/openstack/releases/+/947847 should be ok now.
16:25:52 Uggla As I have done 948811: Add uc check alternative method | https://review.opendev.org/c/openstack/requirements/+/948811
16:26:04 elodilles Uggla: thanks for working on that!
16:26:29 Uggla the path is on master with a backport to the stable branch.
16:26:30 elodilles i've just added a comment on your patch o:)
16:26:53 Uggla so it needs reviews.
16:27:22 Uggla but at least the verify is +1
16:27:51 opendevreview sean mooney proposed openstack/os-vif master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/os-vif/+/899946
16:28:19 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:28:35 fwiesel #info No updates
16:28:46 fwiesel Uggla: Back to you
16:28:52 Uggla fwiesel, btw welcome back, I hope you are good.
16:29:20 Uggla #topic Gibi's news about eventlet removal.
16:29:21 fwiesel Thanks! Just still catching up with everything.
16:29:24 gibi o/
16:29:31 Uggla #link Series: https://gibizer.github.io/categories/eventlet/
16:29:48 gibi so last week we saw nova-scheduler running with native threading. There is a blogpost about it
16:29:58 bauzas had no time to review those patches yet :(
16:29:59 gibi this week I started testing the non happy path of the scatter-gather
16:30:25 gibi good news both mysql server and pymysql client can be configured with timeouts to avoid handing gather threads
16:30:47 gibi I will add a new doc about it in tree
16:31:02 gibi bad news, the oslo.service threading backend uses forks
16:31:23 gibi which does not play nice with out global threadpools initialized before the service workers are forked off
16:31:32 gibi we have workarounds
16:31:41 gibi details are in https://review.opendev.org/c/openstack/oslo.service/+/945720/comments/fb5d6632_f0eaf102
16:31:51 gibi there are two patches to look at
16:32:09 gibi https://review.opendev.org/c/openstack/nova/+/948064?usp=search now with test coverage
16:32:15 gibi and
16:32:16 gibi https://review.opendev.org/c/openstack/nova/+/948437?usp=search
16:32:40 gibi this week I will work on cleaning up the long service to make more patches ready to review
16:32:43 gibi that is all
16:32:46 gibi Uggla: back to you
16:33:16 sean-k-mooney gmaan: Uggla: just a quick update on the pyproject.toml change if i may
16:33:28 sean-k-mooney https://etherpad.opendev.org/p/pep-517-and-pip-23 is my old ether pad to track that work
16:33:33 Uggla thx gibi
16:33:37 Uggla sean-k-mooney, sure go ahead
16:33:40 sean-k-mooney and only the os-vif change above is not mergd for nova
16:33:47 sean-k-mooney so i rebased and appvoed that
16:33:55 gmaan just saw, ++
16:33:57 sean-k-mooney once that is landed we shoudl be good
16:34:07 Uggla \o/
16:34:43 sean-k-mooney anyway that was all on that topic
16:35:09 Uggla gibi, just a question you have said : the oslo.service threading backend uses forks it means real processes and not threads ?
16:35:24 gibi Uggla: no we want worker processes with thread pool
16:35:26 gibi pools
16:35:44 gibi but it uses os.fork to create the worker from the main process
16:35:44 sean-k-mooney context is oslo service
16:35:55 sean-k-mooney allows you to have multiple workers
16:36:00 gibi fork copies the state of the process
16:36:01 sean-k-mooney we use that in the schduler and conductor
16:36:12 sean-k-mooney but not nava-comptue or the api
16:36:17 gibi we would need os.spawn to get a totally new worker process
16:36:22 gibi without inheriting state
16:37:04 Uggla ok I think I have understood the pb.
16:37:04 gibi the wa is to reset the problematic state
16:37:13 gibi after the fork
16:37:25 gibi but I think the real solution would be os.spawn
16:37:48 gibi but changing to that is not super simple as oslo.config has non pickleable lambdas :/
16:37:56 gibi details are in the linked gerrit comment
16:38:07 gibi and are up in the today IRC log
16:38:16 dansmith we can reset after the fork (as you're doing) or reset before the fork, as I suspect will also work and be less janky
16:38:23 gibi yepp
16:38:30 gibi I will try dansmith's suggestion next
16:38:40 gibi while we wait for the oslo folks to respond
16:38:47 sean-k-mooney https://github.com/openstack/oslo.config/blob/d6e5c96d6dbeec0db974dfb8afc8e508b74861e5/oslo_config/cfg.py#L1387
16:38:52 dansmith I agree the real solution is spawn, but we probably don't want to wait
16:38:55 sean-k-mooney that is there only use of lambda i think by the way
16:39:23 gibi dansmith: yepp we won't wait, we will go with the WA, and adapt when oslo makes the move
16:39:52 dansmith +1
16:40:39 Uggla moving on
16:40:49 Uggla #topic Open discussion
16:41:30 Uggla fwiesel, wants to propose something about Cross hypervisor resize.

Earlier   Later