Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-06-29
16:21:02 Uggla tkajinam, antia something you'd like to share ?
16:21:39 tkajinam Uggla, yes
16:22:36 tkajinam so I've created the series of patches for SEV-SNP support and pushes these to gerrit. These can be found in this query https://review.opendev.org/q/topic:%22bp/amd-sev-snp-libvirt-support%22
16:23:24 antia Small update from me. I spent some time on rebasing with the SNP changes and will keep it up to date with that in the future since it is further along. I also have PTO this week and parts of next week so a small stop in development.
16:23:43 tkajinam I initially planned to address the start up validation part ( https://review.opendev.org/c/openstack/nova/+/994342 ) but eventually decided to create the whole series from scratch because the existing PoC patch needs some amount of rework due to refactoring on top of that validation.
16:24:11 tkajinam gibi already gave initial round of reviews for some of these patches (thanks !) and I appreciate additional eyes on that series
16:24:23 mhen so, tkajinam you are doing these now? during the last PTG LY Corporation said they would implement something asap; I guess that didn't happen? I haven't seen anything from them yet
16:24:37 gibi tkajinam: I looked at most of your series and I'm pretty happy with it. I'm in the process of hunting down some HW downstream to try the patches.
16:25:00 gibi tkajinam: thanks for pushing it forward
16:25:11 mhen either way, I will review these patches asap, tkajinam
16:25:17 bauzas I need to review the patches ditrto
16:25:41 tkajinam mhen, that's my expectation though I didn't see anything from them either. I didn't really want to block TDX work due to it so decided to push the patches from my end for early review
16:26:02 tkajinam mhen, I'll ask hiroki to review/check these, too. I think he's been on conference trip and is supposed to come back online this week.
16:26:30 gibi yeah I suggested antia to rebase the TDX on top of SNP as SNP series was closer to completion and the two series are in merge conflict with each other
16:26:51 gibi I will keep reviewing both SNP and TDX.
16:26:59 gibi antia: thanks for the work on it
16:27:05 mhen I have recent test results with SNP on 2026.1 (after the outsourcing of the QEMU firmware JSON selection to Libvirt and removal from Nova) that indicated some necessary changes and will have a look at your SNP patches accordingly.
16:27:53 mhen tkajinam: thank you for taking over by the way
16:29:22 Uggla I think we are good on this topic, thanks tkajinam and antia!
16:29:37 Uggla #topic Bug scrubbing
16:29:42 Uggla #info up to 94 (+0)
16:29:49 Uggla #link https://etherpad.opendev.org/p/nova-bug-triage-roster
16:29:55 Uggla #link https://truc.uggla.fr/ to follow the trend.
16:30:02 Uggla Next meeting (this week): [public] Upstream bug triage. Wednesday, July 1st · 15:30 – 16:00 UTC. Video call link: meet.google.com/zjr-rxus-hzj
16:30:05 dviroel i would like to quick sync about a LP bug that I filed last week, if possible
16:30:19 Uggla #topic Open discussion
16:30:32 Uggla dviroel please go ahead.
16:30:36 dviroel #link https://bugs.launchpad.net/nova/+bug/2158477 'pinned_az' and 'scheduler_hints' missing from instance.create versioned notifications
16:30:48 dviroel the TL;DR; is that some fields were added to server responses (GET /servers/detail), but not to versioned notifications like instance.create
16:31:08 dviroel and services that consume instance notifications — such as Watcher - have no way to learn about pinned_availability_zone or scheduler_hints from notifications, and need to issue additional REST API calls to retrieve this info
16:31:13 dviroel so
16:31:19 dviroel the question really is: can this be treated as a Bug? Or as Wishlist Bug?
16:31:47 dansmith dviroel: those are request-oriented things
16:31:54 dansmith not really appropriate for instance notifications, IMHO
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-29-16.01.log.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 Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-06-29-16.01.html
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 Uggla #endmeeting
16:51:56 lajoskatona o/
16:52:00 elodilles thanks Uggla o/
16:52:02 tkajinam thanks

Earlier   Later