| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-06 | |||
| 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. | |
| 16:46:55 | dansmith | yeah, all that kind of stuff | |
| 16:46:55 | sean-k-mooney | dansmith: specicly like updating the hw_vif_model for say the vmware one to virtio if they dont happen to have common values already | |
| 16:47:21 | fwiesel | Well, we would set those in the flavours and that would override that. | |
| 16:47:39 | sean-k-mooney | so general question. is there anyting we know off that would prevent you form shelving, modifying them in glance and unshleving? | |
| 16:47:54 | fwiesel | No, it is more a usability issue. | |
| 16:48:02 | fwiesel | For our users. | |
| 16:48:08 | dansmith | sean-k-mooney: if the flavor you booted from was vmware-specific you can't unshelve to a libvirt-y one right? | |
| 16:48:18 | sean-k-mooney | fwiesel: so historically flavors are for amounts and images propereis are for changing how the devices are presented | |
| 16:48:31 | fwiesel | And we were thinking of using shared NFS shares to avoid going through image upload, etc... | |
| 16:48:36 | sean-k-mooney | fwiesel: so in the past the precendet was dont put device models in flavors | |
| 16:48:49 | sean-k-mooney | dansmith: correct | |
| 16:49:01 | sean-k-mooney | dansmith: what im thinkign is we dicussed allowing resize in the sheleved state | |
| 16:49:08 | dansmith | to me, snapshot, tweak, boot fresh is the best pattern here | |
| 16:49:18 | sean-k-mooney | so the workflow would be shelve. resize , update image properties and then unshleve | |
| 16:49:22 | dansmith | sean-k-mooney: that's a whole other conversation | |
| 16:49:48 | fwiesel | But I got it... hard to test so, no takers... Perfectly understandable. | |
| 16:49:49 | sean-k-mooney | ya im just confirming if there is a way to do that today with the api we have and i think the gaps are resize while shleved | |
| 16:50:23 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | |
| 16:50:36 | sean-k-mooney | but ya snapshot. detach volumes/ports and boot new vms with thos is a valid workflow too | |
| 16:50:36 | fwiesel | Thanks for the feedback. | |
| 16:52:49 | Uggla | Shall I say it is ok for fwiesel to propose something that goes in that direction ? | |
| 16:53:44 | fwiesel | My understanding is, I won't propose things as it is doable with the existing API and implementing it within Nova is hard to test and maintain. | |
| 16:53:48 | dansmith | I think anyone can propose anything they want :) | |
| 16:54:02 | dansmith | fwiesel: ++ | |
| 16:54:32 | Uggla | oh ok good. | |
| 16:56:11 | Uggla | We are almost at the top of the hour. Are you ok triaging a couple of bugs or would you prefer to do it next week ? | |
| 16:58:00 | Uggla | sean-k-mooney, dansmith ^^ | |
| 16:59:48 | Uggla | ok no answer so you might be busy. So closing the meeting. | |
| 16:59:59 | Uggla | thanks all | |
| 17:00:02 | gibi | Uggla: thanks | |
| 17:00:06 | fwiesel | thanks everyone | |
| 17:00:10 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-05-06-16.02.log.html | |
| 17:00:10 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-05-06-16.02.txt | |
| 17:00:10 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-05-06-16.02.html | |
| 17:00:10 | opendevmeet | Meeting ended Tue May 6 17:00:10 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:10 | Uggla | #endmeeting | |
| 17:00:20 | bauzas | thanks Uggla | |
| 17:00:42 | Uggla | thank you. We will try to do the bug scrubbing next week | |
| 17:01:36 | dansmith | sorry, multitasking | |
| 17:01:50 | elodilles | thanks Uggla o/ | |
| 17:04:04 | gibi | sean-k-mooney: I stop for today but I will get back to forking tomorrow :) | |
| 17:19:19 | sean-k-mooney | gibi: no worries | |
| 17:19:40 | sean-k-mooney | i started at 7am because i woke at 5 so i shoudl also finsih for today | |
| 20:48:44 | opendevreview | Merged openstack/os-vif master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/os-vif/+/899946 | |
| 22:40:36 | opendevreview | Merged openstack/nova master: [quota]Refactor group counting to scatter-gather https://review.opendev.org/c/openstack/nova/+/948064 | |
| #openstack-nova - 2025-05-07 | |||
| 06:13:39 | ishanwar[m] | Hi Everyone... (full message at <https://matrix.org/oftc/media/v1/media/download/ATMsTmYRC_O_5NLksmXpDcjurxmdUL5FvXvyOxE41THD5qlnXpbAklDgHgDUmLVge3chX9vGZMMSxjhL6pv2-jxCeW8Xnj2gAG1hdHJpeC5vcmcvcVNBSnNRU2tBaXZkck1PcEJLQVBLYWN6>) | |
| 06:54:17 | opendevreview | Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks [FIX]: added error handling for .get() statements [FIX]: pep8 formatting fixed for changes https://review.opendev.org/c/openstack/nova/+/948988 | |
| 06:56:40 | opendevreview | Ishan Shanware proposed openstack/nova master: [FEAT]: using quota_details to optimize validate networks [FIX]: added error handling for .get() statements [FIX]: pep8 formatting fixed for changes https://review.opendev.org/c/openstack/nova/+/945204 | |
| 06:58:22 | ishanwar[m] | <ishanwar[m]> "Hi Everyone..." <- I want to get this merged so need your help | |
| 09:25:00 | sean-k-mooney | ishanwar[m]: the failed indicate taht your missing mocking | |
| 09:26:17 | sean-k-mooney | you added | |
| 09:26:19 | sean-k-mooney | @mock.patch( | |
| 09:26:21 | sean-k-mooney | "nova.network.neutron.API.has_quota_details_extension", | |
| 09:26:23 | sean-k-mooney | new=mock.Mock(return_value=True), | |