| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-06 | |||
| 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 | sean-k-mooney | context is oslo service | |
| 16:35:44 | gibi | but it uses os.fork to create the worker from the main process | |
| 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 | gibi | the wa is to reset the problematic state | |
| 16:37:04 | Uggla | ok I think I have understood the pb. | |
| 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. | |
| 16:41:45 | gibi | I guess that was last week's topic | |
| 16:42:07 | Uggla | yep but I understood you wanted to discuss it more. | |
| 16:42:09 | gibi | or maybe a continuation | |
| 16:42:21 | fwiesel | Yes, but there was limited feedback. I mean, if no one feels strongly about it, then I can go forward with a blueprint. | |
| 16:43:39 | fwiesel | We would like to allow mobility between two hypervisors, and I was thinking the cross-cell migration might already cover it to a large degree. | |
| 16:44:05 | fwiesel | The question is though, if that is a use-case you would feel worthwhile supporting or rather not. | |
| 16:44:50 | dansmith | I think it _has_ to be more like cross-cell migration than regular | |
| 16:45:10 | dansmith | I'm a bit mixed on whether or not I think this is worth it, because I suspect there will be a lot of gotchas in the image properties | |
| 16:45:24 | dansmith | and because you can pretty much do this with snapshot yourself now | |
| 16:45:37 | dansmith | and because we won't really be able to test it regularl I don't think | |
| 16:46:27 | gibi | yeah testing this will be painful | |
| 16:46:32 | fwiesel | Okay, got it. That's fine. | |