| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-25 | |||
| 17:39:02 | sean-k-mooney | i dont think they are but that still an open | |
| 17:39:46 | sean-k-mooney | for the start up case we dont even really need a full ironic just enouch to hae the api +db so we can add the nodes that nova cna then discover/enmerate | |
| 17:40:03 | JayF | > create a devstack with the fake ironic <-- this is #3 on my list r/n | |
| 17:40:29 | sean-k-mooney | are there docs that cover that or example local.confs | |
| 17:40:38 | JayF | there will be when I get there on my list | |
| 17:41:09 | sean-k-mooney | cardoe: ack for what its worth nova only supprot prot with vnic_tyupe normal for --network or --subnet | |
| 17:41:36 | sean-k-mooney | cardoe: that why we have alwasy said to use ironic you must precreate teh neutron port with vnic-type=baremetal | |
| 17:41:58 | cardoe | I understand that. Ironic has never supported VNIC_NORMAL and this has been the behavior since Nova added Ironic support on day 1. | |
| 17:41:59 | JayF | sean-k-mooney: what's the path to changing that? | |
| 17:41:59 | sean-k-mooney | we dont block that using --network and --subnet with ironci flavor today however | |
| 17:42:13 | JayF | sean-k-mooney: changing the support for --network/--subnet to include baremetal vnic | |
| 17:42:26 | cardoe | It's invalid for Nova to ever create the port and send it to the hypervisor backend. | |
| 17:42:26 | sean-k-mooney | JayF: that was rejected in the past as wont do | |
| 17:42:32 | JayF | why? | |
| 17:42:41 | JayF | It's the future now! | |
| 17:42:46 | sean-k-mooney | JayF: i tried to get that change approved as part fo the get me a newtrork work | |
| 17:42:54 | cardoe | In fact there's a couple of hypervisor backends that don't support VNIC_NORMAL and Nova shouldn't do that for them. | |
| 17:43:04 | sean-k-mooney | but tldr was a mix of the no more proxy adn no more orchstration policy | |
| 17:43:05 | cardoe | JayF: https://review.opendev.org/c/openstack/nova/+/979354 I wrote the fix already. | |
| 17:43:33 | sean-k-mooney | cardoe: ironic is the only one im aware of tha tdoes nto work with normal | |
| 17:45:00 | sean-k-mooney | JayF: im not against it but we basiclly nova didnt want to keep adding new proxy comamdn for port creation aspect and standardise on you alwasy create a port ahead of tiem | |
| 17:45:18 | sean-k-mooney | we obviously cant remove the exisitng fucntionaltiy but that is the history of why it was rejected before | |
| 17:45:34 | JayF | Might be interesting to revisit, if for nothign else than backwards compat with existing broken Ironic flows (Which have been in use, even if "broken" for a decade+) | |
| 17:46:11 | sean-k-mooney | one suggetion that i didnt really by was this can be automated in the cli/sdk | |
| 17:46:24 | sean-k-mooney | technaily anythign can be but that felt like a non answer | |
| 17:46:44 | JayF | I just need better reasons for my downstream about making their flows more complex | |
| 17:46:48 | sean-k-mooney | we have the exact same gap for neutron sriov ports | |
| 17:47:00 | JayF | precreating ports in Nova makes us inch closer and closer to deployments w/nova being as complex as deployments w/o nova | |
| 17:47:11 | cardoe | Yep. | |
| 17:47:52 | sean-k-mooney | that is true but that is offically the only thing nova ahs ever supproted | |
| 17:48:08 | sean-k-mooney | the changing of the vnic type by ironic after the fact is techniclly not supproted | |
| 17:48:16 | sean-k-mooney | even thought at what everyone relies on | |
| 17:48:21 | JayF | okay; it's been working great and not supported for a decade | |
| 17:48:28 | JayF | so that's sorta an oroboros-y thing to say at some point | |
| 17:48:38 | cardoe | I'm really trying hard to contribute to Nova. To tell others to contribute to Nova. But I'm just constant told no. | |
| 17:48:45 | sean-k-mooney | well it violating nueton api contract too | |
| 17:48:57 | sean-k-mooney | serivce are not ment to modify the vnice tyep and it not supproted to change it on a bound port | |
| 17:49:09 | cardoe | Literally the first commit adding support for Ironic into Nova relied on that behavior. So I'm at a loss how it's unsupported. | |
| 17:49:33 | JayF | ^^ this is what I'm saying, I would love real reasoning other than "because it's always been that way" | |
| 17:49:36 | cardoe | sean-k-mooney: you can change the type of an unbound port. The port isn't yet bound. It's valid by Neutron spec and API. | |
| 17:49:57 | cardoe | That was confirmed during the last PTG. | |
| 17:50:08 | sean-k-mooney | you can but a service shoudl not the vnice tyep is a request form the end user | |
| 17:50:25 | sean-k-mooney | and a port with a nova isntane atach shoudlnot be modifed by ironic but it will be | |
| 17:50:33 | sean-k-mooney | as i said this is how it works today | |
| 17:50:51 | sean-k-mooney | but it has been a long standing pain point that ironic is not workign liek every other virt dirver | |
| 17:50:52 | cardoe | s/today/has always worked/ | |
| 17:51:04 | sean-k-mooney | right and it has alwasy been a mild security issue | |
| 17:51:22 | sean-k-mooney | nova actully did have a security issue which we have fix related to vnic types beign changed | |
| 17:51:54 | sean-k-mooney | anywya im not agains supprotign specifying a vnic type but other are | |
| 17:52:11 | sean-k-mooney | so this would be an api change and one requiring a spec | |
| 17:52:34 | sean-k-mooney | valid to dicuss just ohters woudl prefer not too change this | |
| 17:52:41 | cardoe | Well I've been trying to get a spec approved for 2 years and now ya want me to write another? | |
| 17:52:58 | sean-k-mooney | all api changes require specs that unconditional | |
| 17:53:01 | JayF | maybe we can find what needs to change in your spec to be what sean-k-mooney needs? | |
| 17:53:06 | sean-k-mooney | so this woudl never be conidered a bug in nova | |
| 17:53:06 | JayF | can that be put in review? | |
| 17:53:38 | sean-k-mooney | JayF: im +2 on the ohter spec by the way and have been for 3 cycles :) | |
| 17:53:49 | cardoe | It's absolutely a Nova bug. The Nova Ironic driver creates a Port that cannot work with Ironic. | |
| 17:55:16 | sean-k-mooney | no the compute manger does | |
| 17:55:38 | sean-k-mooney | vnic_type=normal is the only thing that nova can create | |
| 17:55:50 | sean-k-mooney | and we have alwasy say that to use ironic you must pass a port | |
| 17:55:59 | sean-k-mooney | as a reasult of the requrieemnt for vnic tyep baremental | |
| 17:57:30 | cardoe | Can you point me to the docs which say to use Ironic with Nova you must pass your own Port? | |
| 17:57:36 | cardoe | https://docs.openstack.org/nova/2025.2/admin/configuration/hypervisor-ironic.html doesn't show it | |
| 17:59:14 | cardoe | https://docs.openstack.org/nova/2025.2/user/support-matrix.html even shows the operation where Nova is creating the Port itself and as supported. | |
| 18:02:12 | sean-k-mooney | cardoe: its partly a sideffe of nova only supprot vnic_type=normal prot when it creats them and https://review.opendev.org/c/openstack/nova-specs/+/672400 was the last tiem we propsed this as a spec | |
| 18:02:26 | sean-k-mooney | cardoe: ill see fi we have an explcit doc or not | |
| 18:21:06 | sean-k-mooney | cardoe: ironic has https://cdn.maingear.com/docs/ironic/2025.1/admin/networking.html#vif-attachment-flow the srong recoemdation to alwasy create the prot in advnce. one thing to note is while teh current flow was orgianly approved in https://github.com/openstack/nova-specs/blob/master/specs/mitaka/approved/ironic-networks-support.rst#tenant-networking-support-for-ironic-driver | |
| 18:21:08 | sean-k-mooney | with the modification of the vnic type out of band by ironic that spec was never reappovoed and accpated for a later release but the code wa smerged for some unknow reason | |
| 18:21:53 | sean-k-mooney | at the time this was approve the only usecase for a non defautl vnic type was neutron sriov prot which requried the port to be precreated. | |
| 18:21:59 | cardoe | Let's just abandon my proposed change. I'll go away. | |
| 18:22:20 | sean-k-mooney | cardoe: i think the idea of a hypervior depenent defualt vnic type is not a bad one | |
| 18:22:50 | sean-k-mooney | so im not against this just provideign the wider context | |
| 19:00:52 | JayF | Yeah I think we have the fix in line with cardoe's change, just need to figure out the right way to market it to at least one other Nova core and if needed update the paperwork to be in line with whatever is expected if they consider that a feature and not a bugfix | |
| 20:07:24 | sean-k-mooney | JayF: next step would be nova irc meeting. it would be better in the long term if we also had a path to growign more nova cores with ironic expertiese. in the past john garbut was one but they have less time for nova these days | |
| 20:07:39 | sean-k-mooney | JayF: im +1 on the patch over all. | |
| 20:08:39 | JayF | sean-k-mooney: similarly on the Ironic side; I've tried to take the mantle of "expert in the driver", which I think I've "hit" but many of the things here are lower level than that. Between the group of us we can find a solution I'm sure :) | |
| 20:10:58 | opendevreview | Antonin Ruan proposed openstack/nova-specs master: Temp URL download spec https://review.opendev.org/c/openstack/nova-specs/+/975883 | |
| 20:22:00 | opendevreview | Erlon R. Cruz proposed openstack/nova master: Add RBD XML update functionality for migration process https://review.opendev.org/c/openstack/nova/+/974032 | |
| 22:41:11 | opendevreview | Merged openstack/nova master: Update min support for Hibiscus https://review.opendev.org/c/openstack/nova/+/979301 | |
| #openstack-nova - 2026-03-26 | |||
| 08:47:09 | priteau | Hello Nova team. I have just hit the `mkfs.vfat: Label can be no longer than 11 characters` issue while live migrating an instance. There is a fix in Nova but backports are waiting for review. Could you please merge? https://review.opendev.org/c/openstack/nova/+/952003 | |
| 10:04:22 | priteau | Uggla: Would it be possible to merge these backports? | |
| 10:09:05 | Uggla | priteau, I think so. I'll try to have them merged. | |
| 10:09:25 | priteau | Thank you! | |
| 10:16:16 | gibi | priteau: approved the backort now | |
| 10:36:15 | opendevreview | Doug Szumski proposed openstack/nova master: Stop corrupting ephemeral volumes during cold migration https://review.opendev.org/c/openstack/nova/+/940900 | |
| 10:46:11 | priteau | Thanks gibi. I might ping you for the next ones! | |
| 10:47:06 | gibi | priteau: sure | |
| 10:58:38 | nathharp | hey knowledgable nova people. I'm having problems with driving Ironic via nova-compute: when building multiple instances, i see errors like: "status": 409, "title": "Conflict", "detail": "There was a conflict when trying to complete your request.\n\n resource provider generation conflict ", "code": "placement.concurrent_update". Is this likely to be an issue with nova, or placement? This is a 2025.1 cloud | |
| 11:23:00 | nicolairuckel | https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/vtpm-live-migration.html Is it correct, that there is nothing to be implemented for the user mode since in that case live migration is not possible? | |
| 12:50:56 | opendevreview | Merged openstack/nova stable/2025.1: libvirt: Use common naming convention for ephemeral disk labels https://review.opendev.org/c/openstack/nova/+/952003 | |
| 12:56:24 | priteau | gibi: 2025.1 backport has merged, thanks! 2024.2 backport is ready too: https://review.opendev.org/c/openstack/nova/+/952004 | |
| 13:29:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: Default native threading for conductor and compute https://review.opendev.org/c/openstack/nova/+/982237 | |
| 14:32:20 | opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet with standard threading in novncproxy https://review.opendev.org/c/openstack/nova/+/976089 | |
| 15:09:45 | opendevreview | Merged openstack/nova stable/2024.2: libvirt: Use common naming convention for ephemeral disk labels https://review.opendev.org/c/openstack/nova/+/952004 | |
| 16:06:11 | opendevreview | Kamil Sambor proposed openstack/nova master: Replace eventlet with standard threading in novncproxy https://review.opendev.org/c/openstack/nova/+/976089 | |
| 17:11:13 | clif | sean-k-mooney: could you give me some context on ProviderTree? does the tree represent a heirarchical relationship between nodes? I also see ProviderTree calls out the ironic driver specifically for having 'large number of roots' | |
| 17:15:09 | sean-k-mooney | clif: placement is a forset data stucre where we have a forest of provider that are them selve aranged in a tree stucture with root RPs representign a comptue node and potically nested resouce provider as childer repcesting gpus or pci device on that compute host | |
| 17:15:50 | sean-k-mooney | clif: in the context of ironic each ironic node is create in placement as a seperate resouce provider with invetory of 1 resouce class fo custom_baremtal_something | |
| 17:16:18 | sean-k-mooney | so a single nova compute agent with the ironic driver manage a set of trees of depht 1 | |