Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-06-29
16:32:18 dansmith or at least, not in the current sense of it
16:32:40 dansmith we'd need to pass those down to the cell which doesn't know about such things just for instance.create, or store them there for instance.update type things,
16:32:54 dansmith or introduce a new notification that is more top-level-oriented in some way
16:33:32 gibi where do we store these? in the request_spec?
16:33:36 dansmith yeah
16:33:49 dviroel yeah
16:34:25 dviroel and recently support for updating pinned_az was also added, which would also mean update in instance.update notif too...]
16:34:30 dansmith yeah
16:35:00 gibi the scheduler.select_destinations.start already exposes some request_spec fields
16:35:38 gibi so we could extend that
16:35:44 dansmith that would work for create but not update
16:35:50 gibi but I'm not sure if that notification is useful for watcher
16:35:56 dansmith unless we added a notification for scheduler.update_request or something
16:36:24 dviroel is not the kind of notification that watcher currently process
16:37:10 dviroel ok, so it seems that isn't straightforward as I was thinking
16:37:53 dviroel which wouldn't fit into a wishlist bug, would require more discussion, is that it?
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

Earlier   Later