| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-09 | |||
| 13:47:43 | 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:48:12 | 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:49:00 | 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:28 | cardoe | okay. | |
| 13:49:29 | sean-k-mooney | it would be nice to exclude hosts we know cant work however | |
| 13:49:36 | cardoe | speaking of specs... https://review.opendev.org/c/openstack/nova-specs/+/471815 :-D | |
| 13:49:39 | sean-k-mooney | but nice to have rahter then mvp | |
| 13:50:21 | 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:52:37 | cardoe | literally not a character has changed since it was +2. The only thing that changed is the version its targeting. | |
| 13:53:26 | 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:34 | 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:54:31 | 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:41 | cardoe | That's fine. | |
| 13:54:54 | sean-k-mooney | cardoe: im not aware of any of the top of my head | |
| 13:55:12 | cardoe | I just don't want to be on the hook to fix ambiguity in the current metadata format in this spec. | |
| 13:55:29 | 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:29 | sean-k-mooney | right i dont think you are | |
| 13:55:39 | cardoe | So I would do that in a follow on. | |
| 13:56:07 | 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:57:12 | sean-k-mooney | your fering to modifying the value of link to somethign that make sense to the guest? | |
| 13:57:39 | sean-k-mooney | or how we ferencie things in the id fields? | |
| 13:58:24 | 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 | |
| 14:01:15 | 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:53 | cardoe | Folks didn't like that the spec had {"vlan_link": "tap143d8632"} but that's literally just the reference back. | |
| 14:02:02 | sean-k-mooney | ya so that specifc calue is coming form neutron | |
| 14:02:07 | cardoe | I'm all for changing the value "tap143d8632" but that's a follow on. | |
| 14:02:13 | cardoe | Make sense? | |
| 14:02:16 | sean-k-mooney | and its the name of the device on the host which wont be visable on the guest | |
| 14:02:26 | sean-k-mooney | yep | |
| 14:03:05 | 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:24 | sean-k-mooney | and i belvie htey brok compatiyblity when they did that and change the value of it | |
| 14:03:39 | 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:43 | sean-k-mooney | that does not mean we shoudl not do this feature without changing that initally for neutorn in general | |
| 14:03:52 | sean-k-mooney | and then we can decied on normalisting the value seperately | |
| 14:04:33 | cardoe | Yep. I'll work with ya on a follow up. | |
| 14:06:05 | 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:11:03 | 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:42 | elodilles | Uggla: sure, no problem, i was just asking to not forget about it o:) | |
| 14:26:43 | elodilles | Uggla: also note, that RC1 patches are proposed for nova and placement on openstack/releases repository o:) | |
| 14:27:04 | Uggla | elodilles 👍 | |
| 14:32:36 | 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:44:01 | 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. | |
| 15:02:50 | 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:04:20 | sean-k-mooney | we just need ot docuemtn what will be generated and what the expected behvior is | |
| 15:13:06 | sean-k-mooney | cardoe: ok i have foudn the anser sort of in the schema | |
| 15:21:43 | Uggla | Reminder: Nova meeting in ~40mn | |
| 15:26:42 | ralonsoh | sean-k-mooney, ping me tomorrow about the vif type virtual thing | |
| 15:26:59 | ralonsoh | in a nutshell, we use it for the OVN virtual ports | |
| 15:27:01 | sean-k-mooney | ralonsoh: i think it may be buggy | |
| 15:27:06 | ralonsoh | why? | |
| 15:27:09 | sean-k-mooney | or logiclly incorrect | |
| 15:27:37 | sean-k-mooney | well how do you handel the same ip beigin allowed to fail over between 2 vms | |
| 15:27:44 | sean-k-mooney | where im using vrrp or somiler in the guest | |
| 15:28:14 | ralonsoh | sean-k-mooney, I don´t get your point | |
| 15:28:15 | sean-k-mooney | we cant assuem that allowed_address_pair values are uniquce on a network or subnet | |
| 15:28:26 | ralonsoh | yes | |
| 15:28:34 | sean-k-mooney | so we can assuem the port is bound to only one host | |
| 15:28:41 | sean-k-mooney | but its fien we can chat tomorrow | |
| 15:28:54 | ralonsoh | yeah, I need to go to the doctor in some minutes, sorry | |
| 15:28:56 | sean-k-mooney | ill read the bug report | |
| 15:29:13 | ralonsoh | add any comment there, please | |
| 15:29:20 | ralonsoh | I'll check it tomorrow morning | |
| 15:35:25 | opendevreview | Elod Illes proposed openstack/placement stable/2025.2: [CI][stable-only] Fix docs job https://review.opendev.org/c/openstack/placement/+/979685 | |
| 15:36:57 | opendevreview | Elod Illes proposed openstack/placement stable/2025.1: DNM: CI health test https://review.opendev.org/c/openstack/placement/+/979686 | |
| 15:38:08 | 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:37 | opendevreview | Elod Illes proposed openstack/osc-placement stable/2024.2: DNM: CI health test https://review.opendev.org/c/openstack/osc-placement/+/979688 | |
| 15:52:03 | 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:56:40 | Uggla | Hi elodilles | |
| 15:57:02 | Uggla | Do you have a specific deadline for RC1 ? Is Thursday ok ? | |
| 15:57:06 | 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:58:01 | elodilles | Uggla: thursday is OK | |
| 15:58:08 | elodilles | that is the official deadline | |
| 15:58:33 | 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:45 | Uggla | elodilles ok it is what I thought, but I'd like to crosscheck. | |
| 15:58:51 | elodilles | +1 | |
| 15:59:07 | Uggla | We will discuss that in the meeting. | |
| 15:59:17 | elodilles | ACK :) | |
| 16:00:17 | tkajinam | I always feel I get extra bonus when people are talking about "deadline" | |
| 16:00:28 | Uggla | #startmeeting nova | |
| 16:00:28 | 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:28 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:28 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:32 | tkajinam | thanks to time diff | |
| 16:00:34 | tkajinam | o/ | |
| 16:00:36 | Uggla | Hello everyone | |
| 16:00:52 | melwitt | o/ | |
| 16:00:52 | elodilles | o/ | |
| 16:00:54 | dansmith | o/ | |
| 16:01:12 | kaisers | o/ | |
| 16:01:12 | bauzas | o/ | |
| 16:02:31 | Uggla | Let's start | |
| 16:02:46 | Uggla | #topic Bugs (stuck/critical) | |
| 16:02:52 | Uggla | #info No Critical bug | |
| 16:02:52 | lajoskatona | o/ | |
| 16:03:30 | Uggla | https://bugs.launchpad.net/nova/+bug/2143057 is now closed | |
| 16:03:40 | Uggla | Thanks tkajinam | |
| 16:04:06 | Uggla | #topic Gate status | |
| 16:04:13 | Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:04:19 | tkajinam | oh the fix is still blocked by CI | |
| 16:04:20 | Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |