| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-06 | |||
| 11:59:45 | nicolairuckel | oh, now even more jobs are failing | |
| 15:16:33 | stephenfin | Uggla: Did you just update https://blueprints.launchpad.net/nova/+spec/remove-os-volumes-boot-api? If so (a) your date is wrong and (b) it's all merged | |
| 15:16:58 | stephenfin | Uggla: https://review.opendev.org/c/openstack/nova/+/958864 | |
| 15:17:11 | stephenfin | I lost the topic during a rebase, clearly | |
| 15:18:19 | Uggla | stephenfin, yet updating the status. I have just realized I copy/paste a wrong comment. | |
| 15:24:14 | opendevreview | ribaudr proposed openstack/nova-specs master: Move Gazpacho implemented specs https://review.opendev.org/c/openstack/nova-specs/+/979283 | |
| 15:29:08 | nicolairuckel | frickler: Thanks for triggering another recheck. One of the tox jobs is still failing though: https://zuul.opendev.org/t/openstack/build/59c9b161b7334605a7ced566038547d2 Or do you think that may be because of my changes? | |
| 15:42:27 | stephenfin | nicolairuckel: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ | |
| 15:58:03 | frickler | ah, why can't all openstack-tox-* jobs inherit from openstack-tox? *sigh* (I know why they don't, but that makes this pinning task tedious) | |
| 16:08:35 | opendevreview | ribaudr proposed openstack/nova master: DNM: Update min support for Hibiscus https://review.opendev.org/c/openstack/nova/+/979301 | |
| 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: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 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 | |
| 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 | sean-k-mooney | right i dont think you are | |
| 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: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? | |