| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-25 | |||
| 15:20:09 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: Use built-in firmware auto-selection for UEFI firmware https://review.opendev.org/c/openstack/nova-specs/+/966584 | |
| 16:11:22 | opendevreview | Merged openstack/nova stable/2024.2: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967569 | |
| 16:14:45 | opendevreview | Merged openstack/placement master: pre-commit: Bump versions https://review.opendev.org/c/openstack/placement/+/967602 | |
| 16:18:33 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: Use built-in firmware auto-selection for UEFI firmware https://review.opendev.org/c/openstack/nova-specs/+/966584 | |
| 16:21:32 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: Use built-in firmware auto-selection for UEFI firmware https://review.opendev.org/c/openstack/nova-specs/+/966584 | |
| 16:32:59 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: Use built-in firmware auto-selection for UEFI firmware https://review.opendev.org/c/openstack/nova-specs/+/966584 | |
| 17:22:05 | opendevreview | Merged openstack/nova stable/2024.2: nova-conductor puts instance in error state https://review.opendev.org/c/openstack/nova/+/961775 | |
| 18:42:15 | nelljerram | FYI all backports for the "libvirt-tap-managed-no" topic have been merged now. Thanks so much to elodilles for nudging these along. masahito you may like to abandon https://review.opendev.org/c/openstack/nova/+/940135 now. If there are any related loose ends that I should work on, please do let me know. (I'm already thinking about how to plumb in a third-party Calico CI...) | |
| 20:43:48 | nicolairuckel | Does migrate_disk_and_power_off not get called for cold migration? I thought that would be a good place to copy the NVRAM. | |
| 21:28:09 | opendevreview | Ghanshyam proposed openstack/nova master: [Trivial]: Remove unused RBAC default alias https://review.opendev.org/c/openstack/nova/+/968410 | |
| 21:29:52 | gmaan | Uggla: ^^ adding some notes and removing the common alias which should not be used. | |
| 22:48:34 | opendevreview | Sean Mooney proposed openstack/nova-specs master: add spec for resouce notifications https://review.opendev.org/c/openstack/nova-specs/+/967712 | |
| #openstack-nova - 2025-11-26 | |||
| 09:39:55 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963848 | |
| 09:39:56 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2085135 https://review.opendev.org/c/openstack/nova/+/963849 | |
| 09:39:57 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Reset the mapped field of nodes at service deletion https://review.opendev.org/c/openstack/nova/+/963850 | |
| 09:58:53 | Uggla | gmaan, lgtm. +1 on https://review.opendev.org/c/openstack/nova/+/968410, I have added bauzas and gibi because I think we can go ahead. | |
| 11:27:03 | opendevreview | Dominik proposed openstack/nova master: Remove Placement allocations in the broken build cleanup https://review.opendev.org/c/openstack/nova/+/968446 | |
| 13:55:12 | gibi | dansmith: bauzas: Uggla: Kamil: I need to skip the eventlet sync today. Sorry. Feel free to have it without me. | |
| 13:55:20 | gibi | sean-k-mooney: ^^ | |
| 13:59:33 | sean-k-mooney | ack, i have a meeting before it which might over run so i may or may not be there either | |
| 14:04:08 | sean-k-mooney | gibi: heh fun, you know the way we say we dont reallly supprot runing addtional libvirt vms on the same host even though its techinally possible | |
| 14:04:11 | sean-k-mooney | https://paste.opendev.org/show/beuKA1lA9Pt5xDTYYwJR/ | |
| 14:04:24 | sean-k-mooney | this is one of hte way tha tcan break things | |
| 14:05:23 | sean-k-mooney | basicaly if nova cant access the disk images then it would break update aviable resouces | |
| 14:41:02 | noonedeadpunk | sean-k-mooney: hey! have a discussion point around one of the comment on https://review.opendev.org/c/openstack/nova-specs/+/900296/7/specs/2026.1/approved/cross-az-instance-scheduling.rst if you have a minute | |
| 14:41:18 | noonedeadpunk | I've addressed all points (did not push them yet), except `cross_az_attach` | |
| 14:41:50 | noonedeadpunk | As my way of thinking was that I don't need care about that in this spec, as it will be handled here anyway: https://opendev.org/openstack/nova/src/commit/23b462d77df1a1d09c43d0918bca853ef3af1e3f/nova/compute/api.py#L1429-L1430 | |
| 14:42:22 | noonedeadpunk | so if it won't be matching, `MismatchVolumeAZException` will be raised | |
| 14:49:02 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963848 | |
| 14:49:03 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2085135 https://review.opendev.org/c/openstack/nova/+/963849 | |
| 14:49:04 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Reset the mapped field of nodes at service deletion https://review.opendev.org/c/openstack/nova/+/963850 | |
| 14:49:56 | sean-k-mooney | noonedeadpunk: so cross_az attach is a per compute node opiton | |
| 14:50:27 | noonedeadpunk | it seems it's currently verified on api side already? | |
| 14:50:47 | noonedeadpunk | as iirc nova.compute.api is api-side? | |
| 14:51:09 | sean-k-mooney | my point is if you dont configure in the api and only configure it the comptue nodes which is allowed then it will fail late | |
| 14:51:19 | noonedeadpunk | oh, yes | |
| 14:51:49 | noonedeadpunk | but I think it's already the case today? I am just thinking if this is smth which should be addressed in spec at all | |
| 14:52:16 | sean-k-mooney | we just need to document that in the spec | |
| 14:52:48 | sean-k-mooney | in generally i woudl prefer to remove that config option entirly and either replace it with nothing or a flavor extra spec | |
| 14:52:57 | sean-k-mooney | this shoudl never have been setable on a per compute basis | |
| 14:53:11 | sean-k-mooney | but that proably not somethign we can do at this point | |
| 14:53:36 | noonedeadpunk | the reason why I'm raising this, is that we are actually having cross_az_attach=False here.... | |
| 14:53:46 | noonedeadpunk | And made it working *somehow* | |
| 14:53:52 | sean-k-mooney | it built on the false premiss that nova AZ names and AZ names in any other service shoudl align | |
| 14:53:52 | noonedeadpunk | In *some* cases... | |
| 14:54:48 | sean-k-mooney | so if you set cross_az_attach=False in the api then we will end up pinnign the vm to the az of the voluem if and only if you pass in a volume | |
| 14:54:53 | noonedeadpunk | So I'd really love to leave "status quo" for this specific spec wrt cross_az_attach | |
| 14:55:14 | sean-k-mooney | if on the other hand nova creates the voluem i dont think we pin it because we create teh volume after schdulign i think | |
| 14:55:32 | noonedeadpunk | Yes, I think it's true actually | |
| 14:55:33 | sean-k-mooney | noonedeadpunk: yes im not asking you to change the behvior fomr today | |
| 14:55:37 | sean-k-mooney | just document what it iss | |
| 14:55:40 | noonedeadpunk | ++ | |
| 14:55:53 | noonedeadpunk | ok, shoot... | |
| 14:56:15 | noonedeadpunk | so basically, it would make things worse, or indeed I'd need to address that in implementation.... | |
| 14:56:24 | noonedeadpunk | or well... | |
| 14:56:42 | sean-k-mooney | you can litrally punt an just say "this will not change the behvior of cross_az_attach" and if its disabel then it will fail if there is a confilct | |
| 14:57:22 | noonedeadpunk | ++ | |
| 14:57:59 | noonedeadpunk | I am literally failing now to set in my head cross_az_attach behavior in all scenarios.... | |
| 14:58:13 | noonedeadpunk | ok, thanks, will do that then | |
| 14:59:26 | sean-k-mooney | yep because its stupily complicated. the default is true which mean sthe api does nto condier the voluem az by default | |
| 14:59:40 | sean-k-mooney | if you only set it to false on the compute we only check it there | |
| 15:00:05 | sean-k-mooney | if you onely set it on the api we will validate teh az request in the build request vs the volume | |
| 15:00:22 | sean-k-mooney | and we will use the volume's az if there isnt a conflict | |
| 15:00:40 | sean-k-mooney | there is some other behvior thace chages as well | |
| 15:00:56 | noonedeadpunk | unless you create an instance with `--boot-fropm-volume` | |
| 15:01:17 | sean-k-mooney | yep in which case the voluem i think get create on the compute node :) | |
| 15:02:42 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296 | |
| 15:12:27 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296 | |
| 17:21:01 | opendevreview | Merged openstack/nova-specs master: Re-propose vTPM live migration https://review.opendev.org/c/openstack/nova-specs/+/961564 | |
| 17:26:46 | tkajinam | dansmith, hi ! It'd be nice if you can spare some time to check this discussion with Uggla https://review.opendev.org/c/openstack/nova-specs/+/966584/comment/24e4946c_0522d2cf/ ,regarding how we handle firmware used by existing vms during hard-reboot. | |
| 17:27:45 | dansmith | okay I'll try.. my list is stacked pretty deep and we're off the rest of the week here, as you probably know | |
| 17:29:25 | tkajinam | dansmith, thx and yeah I heard that | |
| 17:30:57 | tkajinam | I'll check with Uggla if I can update that part later (after merging the current version) or I can get spec freeze exception, if we need some more time/discussions | |
| 17:31:46 | Uggla | tkajinam, that's ok for me | |
| 18:47:05 | opendevreview | Will Szumski proposed openstack/nova master: Randomise best hosts https://review.opendev.org/c/openstack/nova/+/968544 | |
| 19:56:51 | opendevreview | Sean Mooney proposed openstack/nova master: [WIP] create ResourceSummaryNotification object https://review.opendev.org/c/openstack/nova/+/968558 | |
| #openstack-nova - 2025-11-27 | |||
| 02:17:10 | opendevreview | Seyeong Kim proposed openstack/nova master: libvirt: Support boot_index for multiple block devices https://review.opendev.org/c/openstack/nova/+/963665 | |
| 09:25:24 | opendevreview | Will Szumski proposed openstack/nova master: Randomise best hosts https://review.opendev.org/c/openstack/nova/+/968544 | |
| 10:38:02 | opendevreview | Johannes Kulik proposed openstack/nova-specs master: Spec for asynchronous volume-attach API https://review.opendev.org/c/openstack/nova-specs/+/958900 | |
| 11:15:57 | opendevreview | Johannes Kulik proposed openstack/nova-specs master: Spec for asynchronous volume-attach API https://review.opendev.org/c/openstack/nova-specs/+/958900 | |
| 11:33:12 | r-taketn | Hello everyone. I have uploaded the SEV/SEV-ES refactoring codes. Could you please review it and provide some feedback? | |
| 11:33:20 | r-taketn | #link https://blueprints.launchpad.net/nova/+spec/generalize-sev-code | |
| 11:37:23 | r-taketn | It was discussed at PTG (https://etherpad.opendev.org/p/nova-2026.1-ptg#L687) and decided to make this specless. And, I have run SEV/SEV-ES tests (both manually and using tempest) with uploaded codes. | |
| 11:49:14 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296 | |
| 14:34:46 | masahito | hi nova team, please review the bug fix for 500 Internal Server error in the lock API https://review.opendev.org/c/openstack/nova/+/946223 . Thanks. | |
| 17:16:04 | noonedeadpunk | sean-k-mooney: sorry for bothering you again... I'm trying to process reviews on the spec, and got confused myself as well. Given that weights are run per hypervisor, then basically we can't use heapq basically? | |
| 17:17:54 | noonedeadpunk | there's no reason to build AZ to Host mapping, as we just need to get current hypervisor aggregates, and fetch AZs from it. And then fetch azs foreach request_spec.instance_group.members | |
| 17:18:44 | noonedeadpunk | and then like count how many instances are in the same az, and use that as a negative multiplier? | |
| 17:19:09 | sean-k-mooney | we can the heap woudl need to be be in the request spec object | |
| 17:19:27 | sean-k-mooney | althernitively you can impelent the wigher by overriding the follow fucntion | |
| 17:19:49 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/weights.py#L100-L120 | |
| 17:20:06 | sean-k-mooney | that will allow it to process all hosts at once and you jsut return the list of wights | |
| 17:20:56 | sean-k-mooney | noonedeadpunk so the point i was orgianly trying to make is you rare not ment to fetch data in the weighers | |
| 17:21:17 | sean-k-mooney | only use the data form the host state or request spec | |
| 17:22:38 | sean-k-mooney | we do not have any weigher that operate on aggreats today btu we do have filters that do | |
| 17:22:48 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_instance_extra_specs.py#L50 | |
| 17:23:00 | noonedeadpunk | ok, I was just looking at existing weighters, but seems none of them is actually using weigh_objects | |
| 17:23:05 | sean-k-mooney | but even then you lotice that we never do lookups on object or db queries | |
| 17:23:28 | sean-k-mooney | noonedeadpunk: correct non of the intree ones weigh all the hosts at once | |
| 17:23:47 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py | |