| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-07 | |||
| 21:00:26 | opendevreview | Ilia Baikov proposed openstack/nova master: compute: Pre-load flavor and system_metadata in init_host https://review.opendev.org/c/openstack/nova/+/977037 | |
| #openstack-nova - 2026-03-08 | |||
| 10:40:58 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use native interface to implement own is_admin check https://review.opendev.org/c/openstack/nova/+/979428 | |
| #openstack-nova - 2026-03-09 | |||
| 03:22:20 | 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 | |
| 07:55:33 | 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:33 | 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 | |
| 08:12:17 | 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:37:56 | nicolairuckel | Are there any updates on https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ | |
| 08:44:32 | nicolairuckel | I wasn't able to find any bug report on that on launchpad yet. | |
| 08:44:53 | nicolairuckel | There's a good chance I'm looking in the wrong place though. | |
| 11:02:17 | 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:17:45 | elodilles | Uggla: hi o/ is the cycle highlights patch ready for merge? or do you want to update it before the merge? | |
| 12:36:55 | 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:49:09 | opendevreview | Anton Iacobaeus proposed openstack/nova-specs master: Intel TDX support in libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/979608 | |
| 13:16:55 | 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:21:47 | opendevreview | Elod Illes proposed openstack/placement stable/2025.2: DNM: CI health test https://review.opendev.org/c/openstack/placement/+/979644 | |
| 13:24:29 | opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.2: DNM: CI health test https://review.opendev.org/c/openstack/osc-placement/+/979646 | |
| 13:27:51 | cardoe | Do I need a spec for https://review.opendev.org/c/openstack/nova/+/979354 to be able to be considered? | |
| 13:32:30 | 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:54 | 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:33:27 | dansmith | also, this seems like less of a "feat"ure and more like a bug fix | |
| 13:33:55 | dansmith | so you could try arguing it with a bug, although I'll have the same questions | |
| 13:38:49 | sean-k-mooney | cardoe: one of my consuer is nova and ironci should never modify the vnic type | |
| 13:39:02 | sean-k-mooney | the existing bevhiaor in ironic is violating that | |
| 13:39:51 | 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:40:41 | 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:41:11 | sean-k-mooney | forcing the pre creation of port for dpdk, sriov or ironic networing | |
| 13:42:29 | 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:59 | dansmith | ^ | |
| 13:43:06 | 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:26 | sean-k-mooney | it only works becuase ironic "fixes" it eventhough it not really ment to modify the neutron ports | |
| 13:44:33 | 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:45:50 | cardoe | dansmith: yeah so this function is more like "default VNIC type" | |
| 13:46:01 | 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:12 | cardoe | dansmith: that would make sense for me. | |
| 13:46:21 | dansmith | like libvirt should refuse type "baremetal" as much as ironic should allow it | |
| 13:46:22 | cardoe | essentially Ironic will never work with VNIC_NORMAL | |
| 13:46:26 | cardoe | exactly. | |
| 13:46:53 | 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:47:03 | 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:19 | cardoe | yep. | |
| 13:47:27 | 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:38 | sean-k-mooney | although i woudl expect neutron to provide those required traits not nova | |
| 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 | |