| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-06-29 | |||
| 16:38:29 | dansmith | I mean, you can still have a wishlist bug, but the actual resolution will be more complicated than just a bugfix | |
| 16:38:37 | dviroel | yeah | |
| 16:38:42 | dansmith | I also don't really think it's a bug anyway, since there's a reason they're not included | |
| 16:38:53 | dansmith | but it's easy to understand from the outside why it looks like a bug, so ... :) | |
| 16:39:43 | dviroel | yeah, for watcher means to issue a api to nova when receiving a instance.create notification... | |
| 16:39:53 | dviroel | which is no desirable | |
| 16:40:05 | dansmith | is that really the case though? | |
| 16:40:20 | dansmith | I guess I'm surprised that you would not be issuing such calls regularly | |
| 16:40:23 | gibi | if this is just for instance.create in watcher then listening to scheduler.select_destinations.start as well could help | |
| 16:40:53 | dviroel | gibi: i will spend some time investigating it, thanks for the tip | |
| 16:41:01 | dansmith | but also, why does watcher need to urgently know about pinned_az? I would expect that would only come into play when acting on (or preparing some) action plan | |
| 16:41:35 | dansmith | is it just that watcher is trying to re-create all the nova state internally from notifications? | |
| 16:42:26 | dviroel | we are trying to build watcher internal cluster database more based in notitications other than many api call to external services | |
| 16:43:01 | dansmith | okay I'm not sure that being able to do that is (or should be) a goal of our notifications and their schema, but still: | |
| 16:43:04 | dviroel | it happens that for big environments, this cost a lot | |
| 16:43:29 | dansmith | does watcher need to know the pinned_az always or only if/when it's deciding on what to do in a particular situation? | |
| 16:44:09 | dviroel | when it selects which server to migrate, it needs to know limitations | |
| 16:44:28 | dviroel | so it is really during audits/strategy algorithym process] | |
| 16:44:31 | dansmith | if it really needs to always know this and thus it has to always poll for that piece of data, then I guess we need to provide it in a notification, but if it's only for the 10% of instances that are being moved in a given plan or something... meh | |
| 16:45:01 | dansmith | yeah, so I guess I would expect it would be more reasonable to patch up the internal state with details like that if/when forming an action plan | |
| 16:45:13 | dviroel | taking a maintanence strategy as example, it will need to check all instances in that node | |
| 16:45:23 | gibi | We currently have instance.update notification wired up in the ovo Instance.save() method. So one can say we add something similar for the RequestSpec ovo as well. But this is spec territory now in my head. | |
| 16:45:26 | dviroel | before planing migrations | |
| 16:45:44 | dansmith | I guess I would expect there are plenty of other things that would affect migrate-ability that aren't included in those, like storage affinity, pci devices that aren't migratable, etc, but maybe not | |
| 16:46:08 | dviroel | there is, and we plan to cover them incrementally | |
| 16:46:18 | dansmith | gibi: yeah that's what I meant by scheduler.update_request .. basically a notification for "this instance's request parameters were updated" | |
| 16:46:23 | dviroel | scheduler hints is one that we could start looking at | |
| 16:47:00 | dviroel | checking other notification is also feasible for watcher | |
| 16:47:02 | dansmith | dviroel: right, so polling the instances on a given node is not a huge undertaking.. if it was every instance ever created always, then that's a big deal, but polling for pinned_az and hints for instances on a node.. seems not so bad | |
| 16:48:07 | dansmith | anyway, probably don't need to do this with an audience, but I think dviroel got the idea and we got some context on why it might be important | |
| 16:48:16 | dviroel | ++ | |
| 16:48:24 | dviroel | ack, thanks for the help | |
| 16:48:51 | dviroel | we can circle back again once I check the other notifications as recommended | |
| 16:48:58 | dviroel | thanks dansmith gibi | |
| 16:49:07 | gibi | cool | |
| 16:49:15 | dviroel | Uggla: i think that is that, thanks | |
| 16:49:16 | dansmith | yep, if the select_destinations thing is workable for you for create, then let's just discuss the update notification add and go that route | |
| 16:49:37 | dviroel | ack | |
| 16:49:38 | Uggla | dviroel good. | |
| 16:50:22 | Uggla | anything else to discuss ? | |
| 16:51:33 | Uggla | if not I guess we are done for today. | |
| 16:51:44 | Uggla | Thanks for joining this meeting. Have a nice day/evening. | |
| 16:51:50 | Uggla | #endmeeting | |
| 16:51:50 | opendevmeet | Meeting ended Mon Jun 29 16:51:50 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:51:50 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-29-16.01.html | |
| 16:51:50 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-29-16.01.txt | |
| 16:51:50 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-29-16.01.log.html | |
| 16:51:56 | lajoskatona | o/ | |
| 16:52:00 | elodilles | thanks Uggla o/ | |
| 16:52:02 | tkajinam | thanks | |
| 16:52:03 | gibi | thanks | |
| 16:52:12 | elodilles | Uggla: maybe a special link for you: https://review.opendev.org/q/is:open+project:openstack/releases+reviewer:self | |
| 16:52:15 | elodilles | o:) | |
| 16:52:26 | dansmith | gibi: I don't want to start a big conversation now, but just curious based on your notification experience: do you consider our notifications to be a mechanism by which a consumer should be able to fully reconstruct nova's state? | |
| 16:52:47 | elodilles | (we are at Hibiscus-2 milestone and it seems there is a nova CVE fix release patch as well :S) | |
| 16:53:02 | dansmith | I typically think of them as "enough information to know if action needs to be taken" .. where action might be "update my view of the instance" | |
| 16:53:07 | Uggla | elodilles I'll have a look. But tomorrow, it too hot at the moment. My brain is fried. | |
| 16:53:33 | elodilles | Uggla: sure thing, the milestone release patches are due at Thursday, so no hurry at all | |
| 16:53:48 | Uggla | elodilles 👍 | |
| 16:54:20 | elodilles | maybe the CVE is better for tomorrow, but probably 1-2 days don't make any difference | |
| 16:55:44 | elodilles | I don't know how is it in France currently but here the heatwave will keep itself until Wednesday evening as they say... so fingers crossed o:) | |
| 16:55:49 | gibi | dansmith: we have data rich notifications. I.e. we don't just say, hey this instance is moved. But we send a lot of details about that instance in the notification body. | |
| 16:56:12 | gibi | now, fully recreate is a stretch for sure | |
| 16:57:04 | dansmith | right, we're clearly not saying "hey instance changed, you go figure out why/how" but I also feel like we're not fully saying "here's all the information you could possibly need" | |
| 16:57:27 | dansmith | and "information from a completely separate database" would be a reasonable seam by which to limit scope :) | |
| 16:57:33 | gibi | yeah, definitely, we are actively filtering down the instance ovo into a notification ovo. So it is just a subset of data | |
| 16:57:33 | dansmith | although I totally get the need here | |
| 16:58:35 | dansmith | a new notification for update along with hopefully the existing select_destinations one feels like a nice separation of where/what the information is relevant for, but I also don't want to make consumer life more difficult because of internal architecure | |
| 16:59:24 | dansmith | but I also don't want to end up with a bunch of different and fragmented notifications for every possible changed field, so idk | |
| 16:59:55 | dansmith | "actively filtering down the instance ovo into a notification ovo" is a good summary | |
| 17:08:17 | gibi | let's continue form here. I need to drop | |
| 17:10:29 | dansmith | o/ | |
| 17:21:59 | opendevreview | Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235 | |
| 17:52:46 | rm_work[m] | stephenfin: yeah sorry should have pinged you here -- anyway I am kind of excited about the potential of this effort and I'm researching the feasibility -- if you are also interested (I noticed you added yourself to the WIP CR) LMK as I am looking for folks to brainstorm with and maybe join an effort if I propose it to TC as a real goal (was working on a draft). if I am overindexing your interest based on just a stray 'cc' on a CR | |
| 17:52:46 | rm_work[m] | tho, no worries :P | |
| 18:25:56 | opendevreview | Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235 | |
| 19:07:37 | opendevreview | Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235 | |
| 19:33:03 | opendevreview | Ghanshyam Maan proposed openstack/nova master: Remove disabling the scope enforecment https://review.opendev.org/c/openstack/nova/+/994950 | |
| 19:41:35 | opendevreview | Ghanshyam Maan proposed openstack/nova master: Remove disabling the scope enforecment https://review.opendev.org/c/openstack/nova/+/994950 | |
| 19:43:28 | opendevreview | Erlon R. Cruz proposed openstack/nova master: Adding regression test to reproduce bug 1741364 https://review.opendev.org/c/openstack/nova/+/993597 | |
| 19:43:29 | opendevreview | Erlon R. Cruz proposed openstack/nova master: Add RBD XML update functionality for migration process https://review.opendev.org/c/openstack/nova/+/974032 | |
| 19:45:11 | opendevreview | Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235 | |
| 20:29:29 | opendevreview | Stephen Finucane proposed openstack/nova master: network: Remove 'kwargs' from 'get_instance_nw_info' https://review.opendev.org/c/openstack/nova/+/744872 | |
| 20:29:30 | opendevreview | Stephen Finucane proposed openstack/nova master: network: Remove unused 'affect_auto_assigned' parameter https://review.opendev.org/c/openstack/nova/+/744871 | |
| 20:29:30 | opendevreview | Stephen Finucane proposed openstack/nova master: network: Add type hints for various allocate functions https://review.opendev.org/c/openstack/nova/+/744870 | |
| 20:29:31 | opendevreview | Stephen Finucane proposed openstack/nova master: network: Add type hints for deallocate functions https://review.opendev.org/c/openstack/nova/+/787516 | |
| 20:29:31 | opendevreview | Stephen Finucane proposed openstack/nova master: network: More allocate, deallocate type hints https://review.opendev.org/c/openstack/nova/+/787517 | |
| 20:29:32 | opendevreview | Stephen Finucane proposed openstack/nova master: network: Add type hints for attach, detach functions https://review.opendev.org/c/openstack/nova/+/787518 | |
| 21:38:11 | opendevreview | Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235 | |
| 22:53:09 | opendevreview | Ghanshyam Maan proposed openstack/placement master: DNM: Test removal of enforce_scope https://review.opendev.org/c/openstack/placement/+/995421 | |
| #openstack-nova - 2026-06-30 | |||
| 04:57:25 | opendevreview | Masanori Ueno proposed openstack/nova stable/2026.1: Add regression test for bug #2153425 https://review.opendev.org/c/openstack/nova/+/995437 | |
| 05:03:34 | opendevreview | Masanori Ueno proposed openstack/nova stable/2026.1: live-migration: Ensure limits are set before _call_livem_checks_on_host https://review.opendev.org/c/openstack/nova/+/995438 | |
| 06:54:06 | opendevreview | Tobias Urdin proposed openstack/nova master: Prevent leaking host info when HostMappingNotFound https://review.opendev.org/c/openstack/nova/+/959296 | |
| 07:00:45 | opendevreview | Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381 | |
| 07:01:06 | opendevreview | Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381 | |
| 09:08:31 | opendevreview | Kamil Sambor proposed openstack/nova master: Add concurrency_backend config option for Nova services https://review.opendev.org/c/openstack/nova/+/993760 | |
| 10:06:36 | opendevreview | Masanori Ueno proposed openstack/nova stable/2025.2: Add regression test for bug #2153425 https://review.opendev.org/c/openstack/nova/+/995458 | |
| 11:39:15 | opendevreview | Alexandre Engloner proposed openstack/nova master: Replace ServerUpdateResponse server_groups array property https://review.opendev.org/c/openstack/nova/+/995470 | |
| 13:30:55 | opendevreview | Tobias Urdin proposed openstack/nova master: Fail nova-compute startup when RP cannot be created https://review.opendev.org/c/openstack/nova/+/904381 | |
| 13:48:11 | cardoe | Uggla: apologies I've been on PTO again | |