| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-06 | |||
| 16:28:00 | cardoe | Uggla: https://review.opendev.org/c/openstack/nova-specs/+/471815 is the spec that I've been trying to land with the implementation. I was told previously it was too late for 2026.1. This is the one that's had an implementation since 2024.x | |
| 16:28:14 | cardoe | sean-k-mooney: ^ that's the one we've talked about as well | |
| 16:34:50 | Uggla | cardoe, sorry but unless if I'm wrong this spec was not reproposed for 2026.1 and yes it is too late now. | |
| 16:35:31 | dansmith | Uggla: https://review.opendev.org/c/openstack/nova-specs/+/471815/11 | |
| 16:36:09 | sean-k-mooney | cardoe: oh the metadta one | |
| 16:36:26 | sean-k-mooney | cardoe: ya im still supprotive of actully geting that upstream | |
| 16:36:29 | dansmith | or maybe you mean wasn't tracked as such somewhere? I know @cardoe has been consistently harping on it so I don't think we can claim it was not proposed :) | |
| 16:37:03 | Uggla | cardoe, but I see this is a proposal for 2026.2 and I'll try to take care of it to land in 2026.2. | |
| 16:37:25 | sean-k-mooney | it was propsoed for the last few cycles | |
| 16:37:44 | sean-k-mooney | it just dint get reviewed beofre spec freeze | |
| 16:37:52 | cardoe | I'll do whatever you folks need from me. I'm happy to review other patches. I'm happy to attend team meetings. I'm happy to make whatever changes. | |
| 16:38:49 | sean-k-mooney | there is also a fully implemation of the feature that has been up for the last 2 cycles https://review.opendev.org/c/openstack/nova/+/941227 | |
| 16:39:30 | sean-k-mooney | i have lost context on the detials but i belive its complete | |
| 16:39:54 | cardoe | It is. I'll rebase it once the spec is approved. I'm running it locally. | |
| 16:39:58 | sean-k-mooney | or at leat a comple poc | |
| 16:40:01 | cardoe | There's also tempest tests for it. | |
| 16:40:14 | Uggla | dansmith, I mean it was in Launchpad as a BP. But missed the entry in release/approved directory. And it was not reviewed before SF as sean-k-mooney mentioned. | |
| 16:40:51 | dansmith | Uggla: it _was_ in the 2026.1 directory in PS11 (link above) | |
| 16:41:22 | sean-k-mooney | and in 2025.2 poir to that | |
| 16:41:23 | dansmith | not arguing that it wasn't reviewed in time, that's obviously correct, I just want to point out that it was definitely in the proper directory/state | |
| 16:41:25 | dansmith | yes | |
| 16:44:16 | Uggla | my bad the file is not there because not approved. Sorry. It's getting late here. :) | |
| 17:04:00 | nicolairuckel | stephenfin: thanks! | |
| 20:31:35 | opendevreview | Merged openstack/python-novaclient stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978649 | |
| 20:31:37 | opendevreview | Merged openstack/python-novaclient stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/python-novaclient/+/978650 | |
| 20:51:30 | 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 | |
| #openstack-nova - 2026-03-07 | |||
| 06:17:56 | opendevreview | Merged openstack/nova master: return error about external network to the user on build failure https://review.opendev.org/c/openstack/nova/+/972601 | |
| 13:54:45 | opendevreview | ChungRyeol Lee proposed openstack/nova master: Fix inconsistent description of volume attachment id in Nova API docs https://review.opendev.org/c/openstack/nova/+/979378 | |
| 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 | |