| opendevreview | Doug Goldstein proposed openstack/nova master: feat: add get_vnic_type() to ComputeDriver and set for Ironic https://review.opendev.org/c/openstack/nova/+/979354 | 03:22 |
|---|---|---|
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | 07:55 |
| opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | 07:55 |
| masahito | hello nova team. Please review the lock API 500 error bug fix if you have time. https://review.opendev.org/c/openstack/nova/+/946223 | 08:12 |
| nicolairuckel | Are there any updates on https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ | 08:37 |
| nicolairuckel | I wasn't able to find any bug report on that on launchpad yet. | 08:44 |
| nicolairuckel | There's a good chance I'm looking in the wrong place though. | 08:44 |
| r-taketn | gibi: bauzas: Could you please take another look at sev refcator series(https://review.opendev.org/q/topic:%22bp/generalize-sev-code%22)? I’ve updated the code and comments based on the feedbacks from gibi last week. | 11:02 |
| elodilles | Uggla: hi o/ is the cycle highlights patch ready for merge? or do you want to update it before the merge? | 11:17 |
| opendevreview | Anton Iacobaeus proposed openstack/nova-specs master: Intel TDX confidential VM support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/979608 | 12:36 |
| opendevreview | Anton Iacobaeus proposed openstack/nova-specs master: Intel TDX support in libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/979608 | 12:49 |
| opendevreview | Elod Illes proposed openstack/placement stable/2024.2: [CI][stable-only] Workaround for missing pkg_resources https://review.opendev.org/c/openstack/placement/+/979642 | 13:16 |
| opendevreview | Elod Illes proposed openstack/placement stable/2025.2: DNM: CI health test https://review.opendev.org/c/openstack/placement/+/979644 | 13:21 |
| opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.2: DNM: CI health test https://review.opendev.org/c/openstack/osc-placement/+/979646 | 13:24 |
| cardoe | Do I need a spec for https://review.opendev.org/c/openstack/nova/+/979354 to be able to be considered? | 13:27 |
| dansmith | cardoe: as it affects all the drivers and sort of alters the compute manager behavior, it might be a good idea.. like to explain if/how another driver might ever use that and what the other options are | 13:32 |
| dansmith | like, AFAIK, other drivers support _multiple_ VNIC types so a driver method that returns only one might be kinda fundamentally not useful for others (IDK) | 13:32 |
| dansmith | also, this seems like less of a "feat"ure and more like a bug fix | 13:33 |
| dansmith | so you could try arguing it with a bug, although I'll have the same questions | 13:33 |
| sean-k-mooney | cardoe: one of my consuer is nova and ironci should never modify the vnic type | 13:38 |
| sean-k-mooney | the existing bevhiaor in ironic is violating that | 13:39 |
| sean-k-mooney | cardoe: this touches on the fact taht ironic is techinly not ment to be modifying the port bindig for nova ironic isntances but is for legacy reaons | 13:39 |
| sean-k-mooney | we have again for legacy reason restited proviing a way for nova ot create port with a vnic type other then normal | 13:40 |
| sean-k-mooney | forcing the pre creation of port for dpdk, sriov or ironic networing | 13:41 |
| sean-k-mooney | i had suggested allowing the vnic type to be specified when you provide a network in the past and that was rejected or haveing nova determin it so i think this really woudl need a spec to get agreement | 13:42 |
| dansmith | ^ | 13:42 |
| sean-k-mooney | cardoe: we never blocked --nework form being used with irionic flavors partly due to the upgrade impact but its also techinally incorrect to use that today | 13:43 |
| sean-k-mooney | it only works becuase ironic "fixes" it eventhough it not really ment to modify the neutron ports | 13:43 |
| sean-k-mooney | also to be clear im not really agaisnt the idea of having a hyperviosr specific default vnic type. just pointing out the history of why its not done that way today | 13:44 |
| cardoe | dansmith: yeah so this function is more like "default VNIC type" | 13:45 |
| dansmith | I assume that there's also value in having a driver reject a type it doesn't support, or expose the list of supported ones? | 13:46 |
| cardoe | dansmith: that would make sense for me. | 13:46 |
| dansmith | like libvirt should refuse type "baremetal" as much as ironic should allow it | 13:46 |
| cardoe | essentially Ironic will never work with VNIC_NORMAL | 13:46 |
| cardoe | exactly. | 13:46 |
| sean-k-mooney | there would be value in reporting this to placement as taits too. i think neutorn may actuly do that in some cases | 13:46 |
| dansmith | cardoe: this is all stuff that the spec could/would shake out, so I think you're making that case for yourself | 13:47 |
| cardoe | yep. | 13:47 |
| sean-k-mooney | i.e. so you can shudle dpdk vms (with vnic-type=vhsot-user) to dpdk host based on the trait | 13:47 |
| sean-k-mooney | although i woudl expect neutron to provide those required traits not nova | 13:47 |
| cardoe | I would ask for your guys help if that's okay. My focus area is gonna be the Ironic side. But I can see value for libvirt and others advertising what they support. | 13:47 |
| sean-k-mooney | well maybe not we cant get the info form neuton until we bind the port so nova would have to do that in a prefilter | 13:48 |
| sean-k-mooney | cardoe: the selectionof host based on vnic type could be declared out of scope as a followup but shoudl be noted in the spec | 13:49 |
| cardoe | okay. | 13:49 |
| sean-k-mooney | it would be nice to exclude hosts we know cant work however | 13:49 |
| cardoe | speaking of specs... https://review.opendev.org/c/openstack/nova-specs/+/471815 :-D | 13:49 |
| sean-k-mooney | but nice to have rahter then mvp | 13:49 |
| sean-k-mooney | cardoe: ill see if i can get to that again this week. i dont think it has chagne much since i was orginally +2 | 13:50 |
| cardoe | literally not a character has changed since it was +2. The only thing that changed is the version its targeting. | 13:52 |
| cardoe | I agree there's ambiguity but the ambiguity that folks have an issue with is fields that currently exist in the metadata and the current spec is ambiguous. | 13:53 |
| sean-k-mooney | well litrally that not quite ture https://review.opendev.org/c/openstack/nova-specs/+/471815/10..12/specs/2026.2/approved/expose-vlan-trunking.rst but they were just typo/spelling/grammer fixes like adding puncution | 13:53 |
| sean-k-mooney | cardoe: the reason im not restoreing my +2 is i have not re read it to see if any of the changes we have made in the last 2 cycles break any of the assumations or behvioir | 13:54 |
| cardoe | That's fine. | 13:54 |
| sean-k-mooney | cardoe: im not aware of any of the top of my head | 13:54 |
| cardoe | I just don't want to be on the hook to fix ambiguity in the current metadata format in this spec. | 13:55 |
| cardoe | I'm all for fixing the ambiguity but that's something different because that's touching a different part of the metadata. | 13:55 |
| sean-k-mooney | right i dont think you are | 13:55 |
| cardoe | So I would do that in a follow on. | 13:55 |
| cardoe | Cause that would involve changing the "eth" type (I might be wrong on the name but whatever the regular network interface name is). | 13:56 |
| sean-k-mooney | your fering to modifying the value of link to somethign that make sense to the guest? | 13:57 |
| sean-k-mooney | or how we ferencie things in the id fields? | 13:57 |
| sean-k-mooney | cardoe: i will not that ironic decieed to implemnt this on there side last cycle or the one before and they now rewite this contnet and use the uuids i belive | 13:58 |
| cardoe | Well the feedback I got was that "id" exposed hypervisor specific info to the guest since it did {"id": "tap143d8632"} but that's how the libvirt driver works today. The only part of the spec that makes mention of that is that we use the id to say "this VLAN is on that interface" | 14:01 |
| cardoe | Folks didn't like that the spec had {"vlan_link": "tap143d8632"} but that's literally just the reference back. | 14:01 |
| sean-k-mooney | ya so that specifc calue is coming form neutron | 14:02 |
| cardoe | I'm all for changing the value "tap143d8632" but that's a follow on. | 14:02 |
| cardoe | Make sense? | 14:02 |
| sean-k-mooney | and its the name of the device on the host which wont be visable on the guest | 14:02 |
| sean-k-mooney | yep | 14:02 |
| sean-k-mooney | that is fine what im tellign you is that if your primay use case is for ironic they now add some of this info to the metadata and mofiy what nova returns | 14:03 |
| sean-k-mooney | and i belvie htey brok compatiyblity when they did that and change the value of it | 14:03 |
| cardoe | My primary use case is Ironic but it's still a valid libvirt use case (honestly when I worked on Xen this would have been a great use case there as well) | 14:03 |
| sean-k-mooney | that does not mean we shoudl not do this feature without changing that initally for neutorn in general | 14:03 |
| sean-k-mooney | and then we can decied on normalisting the value seperately | 14:03 |
| cardoe | Yep. I'll work with ya on a follow up. | 14:04 |
| sean-k-mooney | https://review.opendev.org/c/openstack/ironic/+/946677 that provides part of the info right, the mtu specificly bu tyour going beyond that and providign the vlan subport configution based on neutron trunks | 14:06 |
| Uggla | elodilles sorry I missed your earlier message. Can we hold the patch for now. There is something to discuss in today's meeting. | 14:11 |
| elodilles | Uggla: sure, no problem, i was just asking to not forget about it o:) | 14:11 |
| elodilles | Uggla: also note, that RC1 patches are proposed for nova and placement on openstack/releases repository o:) | 14:26 |
| Uggla | elodilles 👍 | 14:27 |
| sean-k-mooney | cardoe: +1 on https://review.opendev.org/c/openstack/nova-specs/+/471815 can you confirm or document what type:ovs means in the metadata that really my main open quetion | 14:32 |
| cardoe | I can remove that. I believe the author intended for that to be clear that was on the hypervisor side it was being trunked. | 14:44 |
| sean-k-mooney | well i think you need to represent the guest interface that the vlans are commign form i just dont know what the type shoudl be | 15:02 |
| sean-k-mooney | we just need ot docuemtn what will be generated and what the expected behvior is | 15:04 |
| sean-k-mooney | cardoe: ok i have foudn the anser sort of in the schema | 15:13 |
| Uggla | Reminder: Nova meeting in ~40mn | 15:21 |
| ralonsoh | sean-k-mooney, ping me tomorrow about the vif type virtual thing | 15:26 |
| ralonsoh | in a nutshell, we use it for the OVN virtual ports | 15:26 |
| sean-k-mooney | ralonsoh: i think it may be buggy | 15:27 |
| ralonsoh | why? | 15:27 |
| sean-k-mooney | or logiclly incorrect | 15:27 |
| sean-k-mooney | well how do you handel the same ip beigin allowed to fail over between 2 vms | 15:27 |
| sean-k-mooney | where im using vrrp or somiler in the guest | 15:27 |
| ralonsoh | sean-k-mooney, I don´t get your point | 15:28 |
| sean-k-mooney | we cant assuem that allowed_address_pair values are uniquce on a network or subnet | 15:28 |
| ralonsoh | yes | 15:28 |
| sean-k-mooney | so we can assuem the port is bound to only one host | 15:28 |
| sean-k-mooney | but its fien we can chat tomorrow | 15:28 |
| ralonsoh | yeah, I need to go to the doctor in some minutes, sorry | 15:28 |
| sean-k-mooney | ill read the bug report | 15:28 |
| ralonsoh | add any comment there, please | 15:29 |
| ralonsoh | I'll check it tomorrow morning | 15:29 |
| opendevreview | Elod Illes proposed openstack/placement stable/2025.2: [CI][stable-only] Fix docs job https://review.opendev.org/c/openstack/placement/+/979685 | 15:35 |
| opendevreview | Elod Illes proposed openstack/placement stable/2025.1: DNM: CI health test https://review.opendev.org/c/openstack/placement/+/979686 | 15:36 |
| opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.1: DNM: CI health test https://review.opendev.org/c/openstack/osc-placement/+/979687 | 15:38 |
| opendevreview | Elod Illes proposed openstack/osc-placement stable/2024.2: DNM: CI health test https://review.opendev.org/c/openstack/osc-placement/+/979688 | 15:38 |
| opendevreview | Elod Illes proposed openstack/osc-placement stable/2024.2: [CI][stable-only] Workaround for missing pkg_resources https://review.opendev.org/c/openstack/osc-placement/+/979691 | 15:52 |
| Uggla | Hi elodilles | 15:56 |
| Uggla | Do you have a specific deadline for RC1 ? Is Thursday ok ? | 15:57 |
| opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.1: [CI][stable-only] Fix docs job https://review.opendev.org/c/openstack/osc-placement/+/979692 | 15:57 |
| elodilles | Uggla: thursday is OK | 15:58 |
| elodilles | that is the official deadline | 15:58 |
| elodilles | if you want to include something that is not yet merged, then add a -1 to the patch and we can wait a bit | 15:58 |
| Uggla | elodilles ok it is what I thought, but I'd like to crosscheck. | 15:58 |
| elodilles | +1 | 15:58 |
| Uggla | We will discuss that in the meeting. | 15:59 |
| elodilles | ACK :) | 15:59 |
| tkajinam | I always feel I get extra bonus when people are talking about "deadline" | 16:00 |
| Uggla | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Mon Mar 9 16:00:28 2026 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| tkajinam | thanks to time diff | 16:00 |
| tkajinam | o/ | 16:00 |
| Uggla | Hello everyone | 16:00 |
| melwitt | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| dansmith | o/ | 16:00 |
| kaisers | o/ | 16:01 |
| bauzas | o/ | 16:01 |
| Uggla | Let's start | 16:02 |
| Uggla | #topic Bugs (stuck/critical) | 16:02 |
| Uggla | #info No Critical bug | 16:02 |
| lajoskatona | o/ | 16:02 |
| Uggla | https://bugs.launchpad.net/nova/+bug/2143057 is now closed | 16:03 |
| Uggla | Thanks tkajinam | 16:03 |
| Uggla | #topic Gate status | 16:04 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| tkajinam | oh the fix is still blocked by CI | 16:04 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:04 |
| opendevreview | Thibaut Démaret proposed openstack/nova master: Add default SSD rotation rate for instance disks https://review.opendev.org/c/openstack/nova/+/979693 | 16:04 |
| tkajinam | let me rerun CI | 16:04 |
| Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:04 |
| fwiesel | o/ | 16:04 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:04 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:04 |
| Uggla | Look quickly at the reports, I have not seen something wrong. Please tell me if I'm wrong? | 16:05 |
| tkajinam | I'm not aware of any problem so far | 16:06 |
| Uggla | #topic Release Planning | 16:07 |
| Uggla | #link https://releases.openstack.org/gazpacho/schedule.html | 16:07 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:07 |
| Uggla | #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg | 16:07 |
| Uggla | I will probably open 2026.2 this week | 16:07 |
| Uggla | #info This week is RC1 target week. | 16:08 |
| Uggla | We will probably hold the RC1 until Thursday. | 16:08 |
| dansmith | "hold" it? | 16:09 |
| dansmith | like delay it? | 16:09 |
| Uggla | yep delay. :) | 16:09 |
| Uggla | reasons in the next points. | 16:10 |
| dansmith | okay | 16:10 |
| Uggla | #topic Review priorities | 16:10 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2026.1-status | 16:10 |
| Uggla | Starting here: https://etherpad.opendev.org/p/nova-2026.1-status#L70 there are interesting bugs to improve live migration. So I would like cores to review them. | 16:10 |
| Uggla | I know some of them have already been merged. | 16:10 |
| Uggla | And others seem in a good shape. | 16:11 |
| dansmith | the first I clicked on has a -1 from you still | 16:11 |
| dansmith | but yeah will take a look | 16:11 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979694 | 16:11 |
| Uggla | dansmith the are others with +2 from sean-k-mooney | 16:12 |
| dansmith | ack | 16:12 |
| dansmith | they seem to conflict with each other and aren't stacked though, which is unfortunate | 16:12 |
| Uggla | so first reason of delaying is to try to introduce these patches. | 16:12 |
| dansmith | or at least, two do | 16:12 |
| Uggla | Second reason, if about the confidential computing refactoring. gibi is following it. | 16:13 |
| * sean-k-mooney looks at meeting | 16:14 | |
| Uggla | Last reason is what we will discuss later in open topics. | 16:15 |
| sean-k-mooney | Uggla: not sure which patch our refeing to | 16:15 |
| sean-k-mooney | but i can catch up later | 16:15 |
| bauzas | I can try to look at some | 16:16 |
| dansmith | Uggla: what about the refactor? I don't see that on the status page | 16:16 |
| bauzas | the SEV refactor series is a blueprint so it can't be merged now | 16:16 |
| dansmith | the status page has quite a list to cram in before thursday.. and I guess I'm wary of the neutron SDK stuff | 16:16 |
| dansmith | those sorts of things tend to have corner cases and since they're not fixing anything or anything that should be user-visible they seem high risk, low reward to me | 16:17 |
| Uggla | sean-k-mooney I was refering to 965927: Add regression test for bug #2088066 | https://review.opendev.org/c/openstack/nova/+/965927 | 16:17 |
| dansmith | bauzas: yeah, anything refactor seems like undue risk given where we are | 16:17 |
| opendevreview | Thibaut Démaret proposed openstack/nova master: Add default SSD rotation rate for instance disks https://review.opendev.org/c/openstack/nova/+/979693 | 16:17 |
| sean-k-mooney | Uggla:ack thanks | 16:17 |
| Uggla | dansmith, I don't want to force anything. Just trying to land what is possible. | 16:18 |
| Uggla | So if you think it is not ready, or risky, it will be for next cycle. | 16:19 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979694 | 16:19 |
| sean-k-mooney | at this point if its not a regressioin intoduced this cycle i would wait until we have cut RC1 | 16:19 |
| dansmith | sean-k-mooney: ++ | 16:19 |
| sean-k-mooney | that happeinginn on thurday if i recall correctly | 16:19 |
| Uggla | sean-k-mooney yes. | 16:20 |
| dansmith | I'll have to look at the other fixes here like the volume stuff but I suspect they're all fairly latent state tracking things that aren't hugely recent/relevant | 16:20 |
| Uggla | dansmith ok | 16:21 |
| Uggla | I have nothing else. So we can move on unless someone wants to add something else. | 16:22 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696 | 16:22 |
| Uggla | #topic Stable Branches | 16:23 |
| * Uggla giving the mic to elodilles | 16:23 | |
| elodilles | thanks o/ | 16:23 |
| elodilles | #info stable/2026.1 branch were cut for libraries | 16:23 |
| elodilles | #info stable/2026.1 branch will be cut for nova and placement this week, along with RC1 releases | 16:24 |
| elodilles | #info nova stable gates should be OK, but placement and osc-placement have blocked stable gates (setuptools/pkg_resources issue), see details in tracking pad | 16:24 |
| elodilles | i forgot about these in the past weeks ^^^^ :S | 16:24 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:24 |
| elodilles | Uggla: that's all from me about stable things | 16:24 |
| Uggla | thx elodilles. | 16:25 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696 | 16:25 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:26 |
| * Uggla giving the mic to fwiesel | 16:26 | |
| fwiesel | Hi, no updates from my side. | 16:26 |
| Uggla | ok thx fwiesel | 16:26 |
| Uggla | skipping next point as gibi is not available. And eventlet was merge already. | 16:27 |
| Uggla | #topic Nova using openstack sdk for neutron | 16:27 |
| lajoskatona | o/ | 16:28 |
| * Uggla giving the mic to lajoskatona | 16:28 | |
| lajoskatona | No progress since last week, as we agreed to push these patches early 26.2 | 16:28 |
| dansmith | ++ early in a cycle is the time for stuff like this :) | 16:28 |
| lajoskatona | +1 | 16:29 |
| Uggla | yep it is what we mentionned last week. We will try to merge lajoskatona sdk client stuff earmy next cycle. | 16:29 |
| dansmith | cool | 16:30 |
| Uggla | #topic Open discussion | 16:30 |
| Uggla | We have a topic from melwitt | 16:31 |
| * Uggla giving the mic to melwitt | 16:31 | |
| melwitt | hi, yes, wanted to discuss about the possibility of an exception for vtpm live migration remaining patches | 16:32 |
| melwitt | the 'host' security mode for live migration has merged but the 'deployment' mode is still outstanding | 16:32 |
| melwitt | the 'deployment' mode is the one where the nova service user owns the barbican secrets. | 16:33 |
| dansmith | I haven't reviewed above what we've merged... well, except for the fixup patch | 16:33 |
| bauzas | it will be difficult to review it for 3 days left given the RC1 deadline | 16:33 |
| dansmith | looks like the last review from anyone on that patch was almost two years ago (Aug 2024) | 16:34 |
| dansmith | yeah, I'm not sure how we could even consider this an FFE candidate given it's not like "reviewed but just didn't make the deadline"... | 16:35 |
| dansmith | and as sean-k-mooney just said above, candidates for things right now should really be "regression introduced this cycle" | 16:35 |
| sean-k-mooney | im a littel sad the deployment mode was not done first | 16:35 |
| sean-k-mooney | but ya i think it woudl be better to finish it early next cycle | 16:36 |
| dansmith | really? i think host is the most useful mode | 16:36 |
| sean-k-mooney | deployment requried the least code chage | 16:36 |
| dansmith | I guess we don't know until ops start deciding but I guess I think host is what most of them will want | 16:37 |
| sean-k-mooney | that why i asked for it to be first since it did nto need to object change | 16:37 |
| sean-k-mooney | but i didnt object to the current order | 16:37 |
| sean-k-mooney | just suggested the other one was less invaisve | 16:37 |
| dansmith | *shrug* I was more focused on getting host in because I _suspect_ it's the thing people will want | 16:37 |
| dansmith | but yeah I get your point | 16:37 |
| melwitt | yeah, the less change makes sense as a subset of that is what would be needed for 'user' mode live migration as well | 16:38 |
| sean-k-mooney | anyway i woudl not be against re reviewing the spec and appoving it and contining to review/merge the feature | 16:38 |
| sean-k-mooney | even before we offically release 2026.1 | 16:38 |
| sean-k-mooney | i just think we should take the checkpoint with rc1 and create the sable branch first | 16:39 |
| dansmith | sean-k-mooney: you mean once rc1 is cut and master becomes 2026.2 right? | 16:39 |
| sean-k-mooney | yep | 16:39 |
| dansmith | yeah, agree, I don't see how it could be any other way | 16:39 |
| sean-k-mooney | im not commeting on the readyness of the remaining patches because the last time i looked in detail was december | 16:39 |
| bauzas | at least operators can support vtpm live migration by G, which is cool | 16:40 |
| dansmith | last actual review on the deployment patch was you, from Aug 2024 :) | 16:40 |
| dansmith | sean-k-mooney: ^ | 16:40 |
| bauzas | they will only set it per host | 16:40 |
| bauzas | for the deployment support, we can make it a short-term priority for Hibiscus given the existing momentum | 16:41 |
| sean-k-mooney | :) i deployed something in decemer and played with the series a bit before going on PTO but i have entirlly ejected that form my memory | 16:41 |
| dansmith | sean-k-mooney: even though I get your point about minimal code change for deployment, it's still the largest perceptual change of the lot | 16:41 |
| dansmith | sean-k-mooney: it puts the users not in control of their TPM key | 16:41 |
| sean-k-mooney | yep | 16:41 |
| dansmith | _that_ is why it seemed it should go last to me | 16:42 |
| sean-k-mooney | yep i get that | 16:42 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696 | 16:42 |
| sean-k-mooney | if we are agreed that this is not in socpe of a FFE are we ok to repoease and review the spec/code once rc1 is cut and master is 2026.2 | 16:43 |
| sean-k-mooney | i mean the repopposal can happen now | 16:43 |
| sean-k-mooney | just are we ok with that directionally so we can move on to other topic or is there anything else to raise | 16:44 |
| dansmith | yeah, are we going to just kick the whole spec to 2026.2 or trim it down to just the "...add deployment" part? | 16:44 |
| bauzas | we can trim it if we want | 16:44 |
| dansmith | but that detail aside, yep, good to move on | 16:44 |
| dansmith | I think it might be nice to mark the first two modes as completed in this cycle | 16:44 |
| dansmith | and then just deployment for 2026.2... I know that's more work for melwitt tho... | 16:44 |
| sean-k-mooney | trim is proably better but i dont have a strong prefence either way | 16:44 |
| melwitt | I wondered about that too. to maybe trim and then make a new blueprint also or? | 16:44 |
| sean-k-mooney | yep that proably for the best | 16:45 |
| melwitt | yeah I was thinking about that about being able to mark the host mode as completed tihs cycle. ok, I will do this | 16:46 |
| dansmith | ++ | 16:46 |
| sean-k-mooney | that wasy we can close the curent oen and leave a not the the deployment part was defereed | 16:46 |
| melwitt | ++ | 16:46 |
| melwitt | ok, thanks all for the discussion | 16:47 |
| Uggla | melwitt just ping me when the trim is ok. | 16:48 |
| melwitt | will do, thanks Uggla | 16:48 |
| Uggla | so I could adjust BP and spec move patch. | 16:48 |
| Uggla | ok I guess we are good with this topic. | 16:50 |
| Uggla | Does someone want to discuss something else. | 16:50 |
| nicolairuckel | Is https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ covered by https://review.opendev.org/c/openstack/placement/+/979685? Unfortunately, that bug blocks my backports of the vTPM and NVRAM patches. :/ | 16:50 |
| tkajinam | nicolairuckel, I think that config_format problems is different but it was fixed by https://review.opendev.org/c/zuul/zuul-jobs/+/979136 | 16:51 |
| Uggla | melwitt can you answer ^ ? | 16:51 |
| tkajinam | nicolairuckel, but we still need 979685 to fix doc job in 2025.2 | 16:52 |
| elodilles | yepp, what tkajinam says. i can second that | 16:52 |
| nicolairuckel | thanks, I missed the first fix | 16:52 |
| elodilles | nicolairuckel: i'll review your backport when i get there o:) | 16:53 |
| nicolairuckel | After 979685 I can restart the CI jobs? | 16:53 |
| nicolairuckel | Thanks. :D | 16:53 |
| elodilles | no problem | 16:54 |
| tkajinam | or you can rebase your backport on 979685 | 16:54 |
| tkajinam | I think even depends-on works | 16:54 |
| tkajinam | (to check whether 979685 fixes the problem blocking your backport | 16:54 |
| tkajinam | we can discuss it outside of the meeting, I think | 16:55 |
| nicolairuckel | oh, that's a good idea | 16:55 |
| nicolairuckel | yeah | 16:55 |
| Uggla | ok some last minute point to discuss ? | 16:57 |
| Uggla | seems not. | 16:58 |
| Uggla | I'm skipping bug scrubbing part because we are at the top of the hour. | 16:58 |
| Uggla | so time to close, thanks for joining this meeting. Have a nice day/evening and see you next week. | 16:59 |
| Uggla | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Mon Mar 9 16:59:53 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-09-16.00.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-09-16.00.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-09-16.00.log.html | 16:59 |
| elodilles | thanks Uggla! have a nice evening o/ | 16:59 |
| kaisers | After meeting follow up request: https://review.opendev.org/c/openstack/nova/+/977300 needs a second +2, it’s a small driver re-support change I brought up here recently already, would be great to have this back in sync with Cinder before the release. | 17:00 |
| Uggla | elodilles thank you, same for you. | 17:00 |
| kaisers | thnx | 17:00 |
| kaisers | & o/ | 17:00 |
| nicolairuckel | thanks, have a nice day | 17:00 |
| nicolairuckel | Can I do the depends-on in Gerrit? | 17:01 |
| tkajinam | thanks | 17:01 |
| tkajinam | nicolairuckel, can you provide the link to your backport ? | 17:01 |
| sean-k-mooney | nicolairuckel: in genral that shoudl work on stable as well yes | 17:01 |
| nicolairuckel | https://review.opendev.org/c/openstack/nova/+/978908/7 | 17:01 |
| opendevreview | Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696 | 17:01 |
| tkajinam | nicolairuckel, Add Depends-on: https://review.opendev.org/c/openstack/placement/+/979685 to the commit message. Probably right above Signed-Off-By | 17:02 |
| tkajinam | oh, wait | 17:03 |
| tkajinam | not that one | 17:03 |
| sean-k-mooney | https://review.opendev.org/c/openstack/placement/+/979685 | 17:03 |
| sean-k-mooney | is fixing the docs job in placment | 17:03 |
| tkajinam | I guess we need the fix for nova | 17:03 |
| sean-k-mooney | right | 17:03 |
| tkajinam | yeah | 17:03 |
| elodilles | nicolairuckel: i think you don't need to do a depends-on as your patch is in nova repo and the broken job is not placement related | 17:03 |
| sean-k-mooney | there actul failre is the tox-cover job | 17:03 |
| sean-k-mooney | and that was fixed globally right | 17:03 |
| tkajinam | oh yes | 17:04 |
| tkajinam | just recheck | 17:04 |
| elodilles | tkajinam: nicolairuckel: i think we don't need the fix as it was already fixed on Friday | 17:04 |
| nicolairuckel | So just recheck? | 17:04 |
| elodilles | yepp, what sean-k-mooney | 17:04 |
| elodilles | says | 17:04 |
| tkajinam | AttributeError: 'Parsed' object has no attribute 'config_format' | 17:04 |
| tkajinam | that's the root cause and that was fixed by the zuul-job update | 17:04 |
| tkajinam | nicolairuckel, yup | 17:04 |
| sean-k-mooney | ya that was fixed in zuul-jobs | 17:04 |
| elodilles | nicolairuckel: i'll try to look into your patch tomorrow as it's already end of day to me now o:) | 17:05 |
| nicolairuckel | For me too | 17:06 |
| nicolairuckel | thanks | 17:06 |
| sean-k-mooney | nicolairuckel: https://review.opendev.org/c/zuul/zuul-jobs/+/979136 for context | 17:06 |
| sean-k-mooney | nicolairuckel: while we often have interestign ci issue near feature freeze this cycle has been extra special due to all the upstream packaging changes | 17:06 |
| nicolairuckel | I'm just always confused when jobs that I can't reproduce locally break. | 17:09 |
| dansmith | Uggla: this is not a regression, but probably pretty safe and the case it makes is pretty compelling: https://review.opendev.org/c/openstack/nova/+/958556 | 17:09 |
| dansmith | I had not seen this before, unfortunately | 17:09 |
| Uggla | dansmith, I said there are interesting patches in the list. :) | 17:13 |
| Uggla | At least for me it is ok to merge things even if it is safe and useful. | 17:15 |
| dansmith | sean-k-mooney: thoughts? ^ | 17:16 |
| sean-k-mooney | Uggla: my question would be what benifit does merging them now vs backporting them in a week by? | 17:16 |
| sean-k-mooney | if its a bug that we feel comfortable merging 2 day before RC1 while we may not consider it valid for an RC2 | 17:17 |
| sean-k-mooney | we likely woudl condier backportign it to sable after the release is done | 17:17 |
| sean-k-mooney | if its not a bug i.e. a small feature we are well past FF | 17:17 |
| sean-k-mooney | if there was a small spefic patch you tought was worth merging i am not against lookign at that | 17:18 |
| sean-k-mooney | jsut the tiem to "merge the thign that are close" in my mind was the week before FF | 17:18 |
| dansmith | sean-k-mooney: linked above.. it's sort of a performance bug, 2s query every give minutes in a periodic that goes to 0s with an index | 17:19 |
| sean-k-mooney | dansmith: on where you askign for https://review.opendev.org/c/openstack/nova/+/958556 specificly | 17:19 |
| dansmith | it's also DB so probably not a good one to backport, but yeah maybe should just wait | 17:19 |
| sean-k-mooney | ok ill take a look at that now | 17:19 |
| sean-k-mooney | sorry i tough you were pointing at Uggla message | 17:19 |
| dansmith | nope, sorry | 17:19 |
| sean-k-mooney | so a db index is pretty safe to add in genral although it may have a upgrade on upgrade | 17:20 |
| Uggla | sean-k-mooney benefit, assuming that's something not risky. Having it the release is cool. People will have it day 1 and I could eventually announced if in the highlights. | 17:20 |
| sean-k-mooney | i.e. in terms fo time of the deb has to compute the index | 17:21 |
| sean-k-mooney | dansmith: with alembic we nolonger need ot have the placeholer so it proablme more backporable then it was but let me take a look i guess | 17:21 |
| dansmith | sean-k-mooney: I was also going to ask.. I'm not polished with alembic.. is upgrade the synchronous stage? | 17:21 |
| dansmith | sean-k-mooney: yeah, but still not great to backport unless it fixes a big bug or something | 17:22 |
| Uggla | but again I'm not pushing/forcing to have them by all mean. Relying on your (core) judgement. | 17:22 |
| sean-k-mooney | upgrade in our case i think is part of the expand set | 17:22 |
| sean-k-mooney | but also not an expret on this i would have ot look it up or read our docs | 17:22 |
| dansmith | yeah, so I think that's the right phase for it | 17:22 |
| dansmith | upgrade is what you can run before you deploy new code, so that's right | 17:23 |
| dansmith | anyway, maybe the fact that we're even discussing means it should wait, it's just a juicy performance bug with a very simple solution | 17:24 |
| sean-k-mooney | as a mitigation will alembic complain if you manually added the same index? | 17:24 |
| dansmith | like if the operator has done this manually already? | 17:24 |
| sean-k-mooney | im not sure how picky it is to schema deviation | 17:25 |
| sean-k-mooney | ya | 17:25 |
| dansmith | I also don't know that.. I thought it has to look and see if the uuid of the migration is recorded or not, but I also thought it was supposed to be sort of idempotent, so idk | 17:25 |
| dansmith | I think the fact that we're not positive here means we should wait, | 17:25 |
| sean-k-mooney | basiclly im askign if the down revisiohn has is based on our model defintion or 2903cd72dc14 by looking at the tables in the db | 17:25 |
| sean-k-mooney | fine by me i normally ask stephenfin about ^ or melwitt | 17:26 |
| sean-k-mooney | anyway without diging into those detail the patch looks vaild to me so ill +1 it but beyond that i would have to read up on the detials | 17:27 |
| dansmith | ack Uggla let's punt, but I think this is a good one to track and nag people to look at as soon as H opens | 17:28 |
| Uggla | dansmith 👍 | 17:29 |
| stephenfin | sean-k-mooney: dansmith: if the question is about backporting migrations, if you're going back further than the release the last migration was added in, then you'll end up creating a branch https://alembic.sqlalchemy.org/en/latest/branches.html#working-with-branches | 17:32 |
| dansmith | I don't want to backport this | 17:33 |
| sean-k-mooney | stephenfin: it more how safe to we feel https://review.opendev.org/c/openstack/nova/+/958556 is and what its upgrade impact | 17:33 |
| dansmith | I think sean-k-mooney's question was what happens if someone has manually done this or something | 17:33 |
| sean-k-mooney | also that | 17:34 |
| sean-k-mooney | the current patch does not have an upgrade release note and i suspect this will take some time to caluate the inde of there are a large number of rows | 17:34 |
| dansmith | also true | 17:34 |
| sean-k-mooney | i belive this will be appled as part of the db sync when we do the expand migritons | 17:34 |
| dansmith | but if it's in the upgrade phase it should be pre-doable | 17:35 |
| stephenfin | Well they're already out of support, but I believe you'll simply end up with a duplicate index with a different name | 17:35 |
| stephenfin | it would be a 5 minute test if you'd a devstack to hand | 17:35 |
| sean-k-mooney | stephenfin: basicly i was wondering if we fix this in master in 2026.2 | 17:35 |
| sean-k-mooney | can operator "fix it themselve" by just creating the index on older rellease without breaking our upgrades | 17:36 |
| sean-k-mooney | or will almebic be unhapply | 17:36 |
| sean-k-mooney | if its just a duplcit index and it wont break future migration that proably ok | 17:36 |
| sean-k-mooney | to be clear 2.264 sec to 0.006 sec for 500k rows is nice but for a perodic that runs every 5 minutes its not unworkable at 2.5seconds | 17:38 |
| sean-k-mooney | defintly worth fixing on master however | 17:38 |
| dansmith | I thought the claim was that this overwhelms conductors when you have a ton of nodes doing it | 17:38 |
| dansmith | "NOTE: missing index for a query that gets regulary executed by every nova-compute node this can overwhelm the nova-conductor service in large scale deployments" | 17:39 |
| dansmith | (from the etherpad, maybe should be copied into the bug) | 17:39 |
| sean-k-mooney | oh its every 5 mintes per compute | 17:39 |
| dansmith | yeah | 17:39 |
| sean-k-mooney | ok that scaling diffently then i initally tought | 17:39 |
| dansmith | and probably scales like n^2 almost because each compute doing it is scanning each other compute record that you ad | 17:39 |
| dansmith | *add | 17:40 |
| sean-k-mooney | although ya it makes sense this is per compute | 17:40 |
| sean-k-mooney | we already have indexs on source_compute and dest_compute and source_node and dest node | 17:41 |
| stephenfin | sean-k-mooney: I can't say, but we've never written our migrations on the assumption that the operator has manually hacked in their own migrations | 17:41 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/958556/1/nova/db/main/models.py#895 | 17:41 |
| stephenfin | so I'm not sure how this would be any different | 17:41 |
| stephenfin | however, if they *had* done that, they can always dummy apply the migration using the stamp command | 17:41 |
| sean-k-mooney | im actully surpised that a quey on teh subset is not coverd by htat | 17:42 |
| stephenfin | https://alembic.sqlalchemy.org/en/latest/api/commands.html#alembic.command.stamp | 17:42 |
| sean-k-mooney | stephenfin: well in the very old days we assumed the dba may create indexes ro set coalation types to optimise for there usecase | 17:42 |
| sean-k-mooney | im not saying that a good thing just that it was a thing | 17:43 |
| sean-k-mooney | the ops guided uses to have soem recomentions for adding indexes but that was eons ago | 17:43 |
| dansmith | Uggla: the other volume bugs there are good things to fix, but I'm not sure in the best way.. I've left some comments | 18:25 |
| opendevreview | Merged openstack/os-traits master: Remove MANIFEST.in https://review.opendev.org/c/openstack/os-traits/+/975992 | 18:42 |
| opendevreview | Merged openstack/osc-placement master: Remove MANIFEST.in https://review.opendev.org/c/openstack/osc-placement/+/975984 | 18:44 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!