Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-06-29
16:08:39 Uggla fwiesel anything to report ?
16:08:45 Uggla ok thanks
16:08:56 fwiesel Sorry for the last time. I had PTO, and forgot about it the time before.
16:08:57 Uggla #topic Kamil's news about eventlet removal
16:09:18 gibi sambork|afk cannot join today so I'm summarizing
16:09:19 Uggla gibi, something you'd like to say.
16:09:35 gibi Waiting for review: -Add concurrency_backend config option for Nova services: This replaces the OS_NOVA_DISABLE_EVENTLET_PATCHING env var with a proper [DEFAULT]/concurrency_backend config option. Accepted values are auto, threading, and eventlet.
16:09:43 opendevreview Takashi Kajinami proposed openstack/nova master: Replace deprecated remotable_classmethod https://review.opendev.org/c/openstack/nova/+/995370
16:09:55 gibi Recently landed: Avoid stacktrace at CLI exit: This fixes a Python 3.14 regression in eventlet mode
16:10:45 gibi This is the one that needs a bit of review https://review.opendev.org/c/openstack/nova/+/993760
16:10:51 gibi (sorry I was not prepared)
16:11:04 gmaan will check it todsay
16:11:24 gibi thanks, I also need to check it again. I saw it working locally but somehow CI needed more code
16:11:41 gibi that is it from me
16:11:56 Uggla thanks gibi
16:12:07 Uggla #topic Nova using openstack sdk for neutron
16:12:21 Uggla lajoskatona, something you'd like to share ?
16:12:58 lajoskatona Yes, some
16:13:20 lajoskatona last week we had a chat with gibi for filtering the API calls, like we had in neutronclient:
16:13:50 lajoskatona show_network(id='....', fields=[id, subnet_ids...etc]....)
16:14:09 gibi yeah, context is that I have a perf optimization patch https://review.opendev.org/c/openstack/nova/+/994896 that relys on that
16:14:11 lajoskatona and to tell the truth I had to check today if something is there in SDK for such thing
16:15:09 lajoskatona and if I understand well perhaps the _quesry_mapping filed of resource classes is similar, but Ihave to test it, like her: https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/port.py#L30
16:16:00 gibi stephenfin: ^^ if you are around then we could use your experties later on this
16:16:10 lajoskatona if there is a field in that list we can filter, but I have to read more code and test if it is really the same behaviour
16:16:26 lajoskatona s/field/fields
16:16:52 lajoskatona yeah, and I have to ask around to be sure perhaps
16:17:31 opendevreview Adam Harwell proposed openstack/placement master: Add native ASGI application for Placement API https://review.opendev.org/c/openstack/placement/+/995235
16:17:43 lajoskatona as I see just few neutron resources have this "fields" _query_param, so I have to update the resource classes in sdk itself if it is really for this kind of API field filtering
16:18:23 gibi I haven't looked recently in the SDK series (I should) but I feel that this can introduce perf regression if we just ignore the fields= filter during the translation of our code to use the SDK
16:18:39 gibi so lets dig in and find a way :)
16:18:43 lajoskatona I suppose it is not only me who had no idea about it as only few Neutron resource has this (like port) but i.e. network has no such
16:19:32 lajoskatona my homework is to check this in SDK now and update the series, because I blamely removed as I was sure that it is not possible with SDK :-(
16:19:51 lajoskatona that's it for this topic
16:20:04 Uggla thx lajoskatona
16:20:08 gibi lajoskatona: thanks. Feel free to ping me if need some extra set of eyes on this
16:20:36 Uggla #topic Confidential computing, status of SNP and TDX features
16:20:52 lajoskatona gibi: thanks
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?

Earlier   Later