| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-06 | |||
| 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), | |
| 09:26:25 | sean-k-mooney | ) | |
| 09:26:27 | sean-k-mooney | but you only did that to your test | |
| 09:26:43 | sean-k-mooney | the function you added is called in several other test that do not have the mock in place | |
| 09:27:35 | sean-k-mooney | so for the 5 failing test you also need to mock the call to has_quota_details_extension | |
| 12:05:37 | gibi | sean-k-mooney: dansmith: FYI I noted some memory consumption numbers with the reduced scatter-gather pool size in https://review.opendev.org/c/openstack/nova/+/948450/comments/9ff461df_ec6381b2 It seems we have a good handle on managing memory consumption by managing the pool size. | |
| 12:07:27 | gibi | 40 threads -> 122MB RSS, 5 threads -> 85MB RSS, eventlet based scheduler 56MB RSS | |
| 12:14:12 | sean-k-mooney | cool that looks reasonable. although we are planning to have multiple pools in some cases | |
| 12:14:34 | sean-k-mooney | i guess for conductor api and schduelr we likely will only need the scater gater pool | |
| 12:14:50 | sean-k-mooney | and for the compute we will only need the io one | |
| 12:14:57 | sean-k-mooney | out side of the oslo.messaging one | |
| 12:15:21 | sean-k-mooney | so we are proably fine | |
| 12:16:18 | sean-k-mooney | i belive in my paches i reused the generic io threadpool for ceph but if we are removing that expict usage anyway and leavign the librbd/rados package handel that internally then that fine too | |
| 12:16:29 | gibi | yeah currently I have no data abou the pool in oslo.messaging. But obviously that is changed too as soon as we switched off monkey patching | |
| 12:17:06 | gibi | but we have a config option to limit that pool too (default is 64) | |
| 12:17:09 | sean-k-mooney | i assume that if that is configurable it will be expsoed as an oslo.messaging config option which we will jsut inherit | |
| 12:17:15 | gibi | yepp | |
| 12:17:17 | gibi | it is | |
| 12:17:25 | sean-k-mooney | cool | |
| 12:17:47 | sean-k-mooney | 64 seam a little higher then i woudl expect but we can role with it and see | |
| 12:18:34 | sean-k-mooney | for the conductor or schduler i guess that might be reasonable to have 64 RPCs in flight at once | |
| 12:18:53 | sean-k-mooney | the api and comptue dont really need it that large | |
| 12:19:29 | sean-k-mooney | tooling and admins can tune it however once we gain experince iwth the impact on scaling | |
| 12:23:46 | gibi | yepp | |
| 12:23:55 | gibi | I will include a list of tunables in a new doc | |
| 15:40:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/947966 | |