Monday, 2026-03-09

opendevreviewMerged openstack/ironic stable/2025.2: Properly register [agent_container] config  https://review.opendev.org/c/openstack/ironic/+/97945004:14
rpittaugood morning ironic! o/08:01
opendevreviewMerged openstack/ironic master: Add admin-guide documentation around container hwm  https://review.opendev.org/c/openstack/ironic/+/97903508:56
rpittauFYI the issues we're seeing in some bifrost (and maybe in ironic) jobs are probably due to a systemd dependency cycle in glean, this should fix the issue https://review.opendev.org/c/opendev/glean/+/97947109:23
dtantsurJayF: hey, would you be fine if we move on with https://review.opendev.org/c/openstack/ironic-specs/+/972754 and figure out the exact implementation on the actual patch? Or did you have any other blocking comments?12:05
dtantsurI think people shy away from W+1 until they get an ack from you :)12:06
mnasiadkadtantsur: I’ve noticed https://review.opendev.org/c/openstack/bifrost/+/920057 - are you fine with me picking that up?12:09
mnasiadkaGood morning12:09
dtantsurmnasiadka: I'll be very grateful if you do12:09
dtantsurI 100% don't have time for it12:09
mnasiadkaThanks, I’ll have a go :)12:10
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005712:22
JayFdtantsur: is a +1,. Not a -112:59
JayF🛳️🛳️🛳️🛳️12:59
TheJuliagood morning13:01
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005713:02
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005713:04
clifIs weekly meeting in 45 minutes or 1:45 minutes?13:15
JayF1:4513:16
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005713:20
dtantsurJayF: you surely know that +1 is kinda ambiguous in our world..13:22
dtantsurmorning TheJulia, maybe you happen to have time for https://review.opendev.org/c/openstack/ironic-specs/+/972754? You may have opinions about scaling13:22
rpittauwhen any core is available, please review the standalone ironic networking support for bifrost, thanks https://review.opendev.org/c/openstack/bifrost/+/96239413:27
opendevreviewHarald Jensås proposed openstack/networking-generic-switch master: AttributeError: delete_port_postcommit segment=None  https://review.opendev.org/c/openstack/networking-generic-switch/+/97935013:31
opendevreviewHarald Jensås proposed openstack/networking-generic-switch master: Fix KeyError in vlan_has_vni for Cisco NX-OS  https://review.opendev.org/c/openstack/networking-generic-switch/+/97935113:31
opendevreviewHarald Jensås proposed openstack/networking-generic-switch master: Enable L2VNI support for Cisco NX-OS switches  https://review.opendev.org/c/openstack/networking-generic-switch/+/97935213:32
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP] Experimental support for ARM64 hosts on Debian  https://review.opendev.org/c/openstack/bifrost/+/92005713:36
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP]: Switch to Debian Trixie  https://review.opendev.org/c/openstack/bifrost/+/97965113:44
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP]: Switch to Debian Trixie  https://review.opendev.org/c/openstack/bifrost/+/97965113:49
cardoerpittau: done.13:56
TheJuliadtantsur: in principal, I think its a decent spec. I have some concerns around caching, but I also think your being pragmatic overall. It feels like the caching stuff would be a little easier to tackle, and the model has some concerns around it, but that being said I don't think its a bad path.14:36
dtantsurThanks, will ponder your feedback after the current meetings (sigh)14:37
JayFdtantsur: I will personally *never* put a +1 on something I'd be upset it if merged. :) 14:39
TheJuliaI don't think any of my feedback is change the world, just my perception :)14:39
JayFdtantsur: and I don't treat +1s as blocking unless they come with an actionable comment14:39
TheJuliaYeah, at most I have a nit, so dtantsur I'm happy to workflow the spec if you read my comments and have $thoughts or whatever.14:40
dtantsurJust hold on, I'm in the middle of a fascinating exercise: a full call of people discussing a thing that not a single person on the call understands at all.14:43
TheJuliaoh, no worries!14:43
JayFyou explained better than I ever could why I didn't want to upgrade to a +2 on that spec with that comment LOL14:43
JayF(I don't fully understand all the moving parts and don't want our specs to turn into that conference call)14:44
TheJulia++14:44
dtantsurheh14:44
TheJuliaI do sort of understand a lot of the parts which is why I'm like "uhh, hold up on this caching bit..."14:44
JayFyeah I grok like 75%+ of it14:44
JayFso I'm not like, outta the loop14:44
JayFjust being aware I don't have the juice to get to 100% 14:45
cardoerpittau: what do we need to do to confirm that glean fix and get IPA built with it?14:47
TheJuliawhat about glean?14:52
rpittaucardoe: yes14:53
rpittaufrom what I can see glean CI is quite broken14:54
TheJuliaIt is not an openstack delierable so it can be fixed whenver convenient14:58
JayF#startmeeting Ironic15:00
opendevmeetMeeting started Mon Mar  9 15:00:03 2026 UTC and is due to finish in 60 minutes.  The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'ironic'15:00
alegacyo/15:00
kubajjo/15:00
Mahnooro/15:00
clifo/15:00
JayFHello everyone! Many of your clocks may look strange but the meeting is right on (UTC) time :D 15:00
TheJuliao/15:00
TheJuliaGood morning!15:00
JayFThis is your courtesy annual warning that meetings shared between US-ians and non-US-ians are going to be silly for a few weeks as clocks mismatch :D 15:00
JayF#topic Announcements/Reminders15:01
dtantsuro/15:01
JayF#link https://tinyurl.com/ironic-weekly-prio-dash15:01
rpittauo/15:01
JayFMake sure to review #ironic-week-prio patches, please. We are nearly at 0 last I checked.15:01
TheJulia2, we have 2.15:01
JayFAlso set hashtag:ironic-week-prio on things you want reviewed15:01
JayFGazpacho release is flying down the track, it's R-3 which is RC1 target week for most (not us) openstack deliverables15:02
JayF#link https://releases.openstack.org/gazpacho/schedule.html15:02
rpittauwe're definitely on track :)15:02
JayF#topic Working Group Updates15:02
cardoeAnd make sure your stuff is actually ready to review... otherwise I'm kicking it outta that tag.15:02
JayFspeaking of being on track, I think we're going to have a lot of "it's done" for these :D 15:02
JayFAny updates for Standalone networking? alegacy?15:02
dtantsurI think Allain is now busy with the Metal3 side mostly15:03
alegacyLooks like the last change (bifrost) is going to merge soon.  Other than that working on getting this integrated into Metal3!!15:03
JayF#note Standalone networking is feature-complete for Gazpacho, and focus has moved on to implementing it in Metal3.15:03
alegacy...and working on some minor follow-ups that I owe15:03
JayFGood stuff!15:03
JayFAsyncIO updates? dtantsur 15:04
dtantsurI need to check the comments on the spec15:04
dtantsurAfter that, I'll be looking for someone to help me with actual coding, unless I magically find much more time :-/15:04
JayFI don't have any suggestions; I don't think that's likely to be a priority for my team.15:05
TheJuliaSensor data is sort of useful :)15:06
JayF#note AsyncIO spec nearing merge; looking for interested volunteers to help implement asyncio for sensor data in H15:07
JayFfinally, VXLAN networking. TheJulia? cardoe? 15:07
cardoeI think we're in a good place.15:07
cardoeI need to deploy what we've landed and kick the tires some in a real environment.15:07
TheJuliaVxlan got all the key patches landed. That being said hjensas has been moving through individual switch drivers and working on doing specific case testing where we will have some backportable fixes as we move forward and it looks like I'll need to do multicast vxlan support as well which we'll land in the next cycle.15:08
JayF#note VXLAN implementation is in place. Fixes are coming as the implementation integrates with the real world. Next up will be multicast support in VXLAN in H.15:09
JayF#topic Discussion Topics15:09
JayFWe have a PTG incoming!15:09
JayF#link https://etherpad.opendev.org/p/ironic-ptg-2026.215:09
JayFEveryone should be dedicating time to reviewing PTG etherpad, putting details on ideas in there and such.15:10
JayFI'll personally be sending an email this week proposing a nova/ironic shared PTG session around impoving the startup story for nova-compute w/ironic driver15:10
TheJuliaI reached out to Neutron, they are likely a few weeks behind us in figuring out their PTG but there does already seem to be consensus in doing some sort of session15:11
JayFAbout what, specifically?15:11
TheJuliaTwo items, they have a bug regarding our lacking support of vlan transparency which is their name for handing whole trunk ports to "instances"15:12
cido/15:12
TheJuliaThe other is in hind sight looking at the networking-baremetal mech driver stuff, I think mech drivers should be able to "push an e-stop on binding"15:12
JayFoh, neat. We have no way of modeling that whatsoever. That sounds like it's going to be painful.15:12
JayF++15:12
JayF#action JayF emailing list about nova/ironic shared PTG session around nova-compute onlining (resource tracking, placement, etc)15:13
TheJuliabecause it *IS* actually possible for the mech driver to sanity check and say "no, this ain't going to work" and we really should use a defensive with feedback model as a opportunistically try to make this work model with ml2 drivers.15:13
JayF#note TheJulia working with neutron for a joint session on vlan transparency and failure modes inside ML2 drivers15:13
JayF#topic Bug Deputy Updates15:15
TheJuliaActually, vlan transparency is one of those cases where we should likely go  "no, you don't bind this"15:15
JayFwe don't have labelled here who the deputy was15:15
TheJuliaOh, sorry, I was15:15
JayF#undo15:15
opendevmeetRemoving item from minutes: #topic Bug Deputy Updates15:15
TheJuliawe had one bug come in15:15
JayFWhy wouldn't Ironic support binding trunk ports?15:15
JayFdo we require more information? e.g. we won't hook into a network at L2 only, we need L3 deets?15:16
TheJuliaWell, today we can't and in that model if it was QinQ, it would be okay15:16
TheJuliabut ultimately at some level also handing an "instance" "everything vlan wise" and having no outer bound on what gets passed, it starts to get a bit concerning.15:17
JayFyou'd almost have to have code in ironic that borderline could be used to create a full router/switch15:17
JayFif you were trying to serve use cases like passing thru an l2 vlan, without having an ip on it, to a VM15:17
JayFany case you get to of "I want this bare metal machine to have a trunk port, but I don't want to tell you the VLANs/networks/IPs off that trunk port" would end up with unbounded complexityh15:18
TheJuliaThat is orthognal to the issue really. The use case for vlan transparency is "I have a VNF workload, and I 'trust' it to do what it needs to do networking wise15:18
JayFI think I see what you're saying now15:18
JayFTheJulia: like, deploying an application image onto bare metal that contained [networking lb software] for instance?15:18
JayFI am trying to crystalize this into a use case so I can understand15:19
TheJuliayeah, and the application and even it's configuration is a blackbox to the infrastucture, but it has to tie in deeply with it15:19
TheJuliaOr maybe not, *shrug*. Sort of why we need to have a longer chat than a short back and forth in a bug15:19
JayFI guess if we were somehow able to scope out configdrive information15:19
JayFit might be at least a small enough feature to implement15:19
JayFbut if we had to write out a network_json for god-knows-what 15:20
JayF:-| 15:20
JayFclearly PTG-level of discussion to happen there15:20
TheJuliaor, nobody knows what the config really is, but yeah15:20
JayF#topic Bug Deputy Updates15:20
JayFTheJulia was the bug deputy15:20
TheJuliaSo yes, one new item15:20
TheJulia#link https://bugs.launchpad.net/ironic/+bug/214367515:20
TheJuliaReads as a bug to me15:20
JayFAh yeah, I agree, clif found that doing TBN milestone 215:21
JayFIt should be pretty straightforward if someone wanted an easy fix15:21
JayFI'll point my brain and/or claude at it eventually if we don't get someone plucking the low hanging fruit soon enough :)15:21
clifif no one takes it I'll work on it once I've got TBN milestone 2 mostly done15:21
TheJuliaSeems logical15:22
shermanmif there are there cases where we know in advance that "x won't work", would it make sense to fail during precommit in the ml2 driver?15:22
TheJuliashermanm: ideally yes, but today the ml2 manager code just ignores the exception15:22
JayFshermanm: I think that was the second prong of what TheJulia said our session with Neutron was for; improving failure cases when dedected in an ML2 mech driver15:22
opendevreviewMerged openstack/bifrost master: Add support for standalone ironic networking  https://review.opendev.org/c/openstack/bifrost/+/96239415:23
JayFWho will be the next bug deputy?15:24
cidI will!15:25
JayFThanks! 15:25
JayFNo RFEs for review, skipping that topic.15:26
JayF#topic Open Discussion15:26
JayFno topics preseeded here, the floor is open if anyone has an item for the meeting15:26
clifI'll just say I'm aiming to have code up for review for TBN milestone 2 in the next day or so15:27
clifPlease take a look if you're interested15:27
TheJuliaclif: ack, thanks!15:27
JayFNice, thank you! I am working on ramdisk driver stuff too, doug w/stackhpc is testing my changes now so hopefully we can get that in too15:27
JayFWhile the floor is open for more discussion items, someone want to volunteer to run the next meeting?15:29
JayFI'm willing to if folks want me to keep running them, I don't really mind and it gives me a nice Monday morning kickstart15:29
JayFespecially now that it's 8a local instead of 7a local so I don't have to run the first 10 minutes of the meeting while finding caff :D 15:29
TheJuliaI can likely run the next one if folks want15:30
JayFYou and I can trade off for a while, sure :D 15:30
JayF#note March 16 meeting to be chaired by TheJulia 15:30
JayFLast call for meeting discussion items.15:30
JayFThanks for coming!15:32
JayF#endmeeting15:32
opendevmeetMeeting ended Mon Mar  9 15:32:56 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:32
opendevmeetMinutes:        https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-03-09-15.00.html15:32
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-03-09-15.00.txt15:32
opendevmeetLog:            https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-03-09-15.00.log.html15:32
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP]: Switch to Debian Trixie  https://review.opendev.org/c/openstack/bifrost/+/97965115:36
opendevreviewMichal Nasiadka proposed openstack/bifrost master: [WIP]: Switch to Debian Trixie  https://review.opendev.org/c/openstack/bifrost/+/97965115:42
opendevreviewJulia Kreger proposed openstack/networking-baremetal master: Revise localnet port text  https://review.opendev.org/c/openstack/networking-baremetal/+/97969916:47
TheJuliaJayF: hjensas: commented on https://review.opendev.org/c/openstack/networking-generic-switch/+/979350  this race concern concerns me but I've got an idea in it17:53
TheJuliahjensas: regarding https://review.opendev.org/c/openstack/networking-generic-switch/+/979350, would a better approach be to see if original_bottom_bound_segment and original_top_bound_segment would work for that since they should, ideally, still have data18:25
hjensasTheJulia: yes, see what you mean it would be better to try to do best effort to ensure vlans are removed. hmm, looking at neutron_lib/plugins/ml2/api.py checking the original_*_bound_segments looks promising.18:31
TheJuliahttps://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/driver_context.py#L12418:31
TheJuliaYeah, does look promising there18:31
hjensasI'll be afk for a while, driving hat on - kid need a ride.18:35
TheJuliaok, fun factoid, networking-cisco uses original as well18:35
opendevreviewLéonard Suslian proposed openstack/ironic master: Use ServiceRoot.Vendor for detect_vendor() instead of System.Manufacturer  https://review.opendev.org/c/openstack/ironic/+/97843918:55
clifIf I'm in the middle of NeutronVIFPortIDMixin what is the 'right' way to create a new portgroup? Is it objects.Portgroup.create? or some other way?19:04
clifI should say NeutronVIFPortIDMixin.vif_attach I suppose19:04
TheJuliato create, create the object19:06
TheJuliavif_attach is calling networking backend and saying "make this attachment"19:07
clifwell, what I mean is pg = objects.Portgroup() then pg.create()19:07
TheJuliayes19:08
clifthis is for group_and_attach_ports support19:08
TheJuliait might be objects.Portgroup() and then pg.save(), I just don't remember the lowest level primiatives off of the portgroup object at the moment19:09
clifI'm trying to at least unit test my change but I'm getting:     oslo_versionedobjects.exception.OrphanedObjectError: Cannot call create on orphaned Portgroup object 19:17
clifand it appears that even though I'm passing the context in through create() the function itself ignores it and I end up with None for the context19:18
TheJuliawhat does the api for portgroups do?19:20
clifI guess mainly call into dbapi19:20
clifohhh, I think I have to set the context when creating the object first19:23
TheJuliahttps://github.com/openstack/ironic/blob/master/ironic/api/controllers/v1/portgroup.py#L48919:23
clifI just got it19:23
TheJuliaawesome19:24
clifty :)19:24
*** alegacy_ is now known as alegacy19:54
cardoedtantsur: I tried to enable verify bmc clock like metal3... https://bugs.launchpad.net/ironic/+bug/214377220:15
opendevreviewcid proposed openstack/ironic master: Check port physnet against portgroup on first add  https://review.opendev.org/c/openstack/ironic/+/97972120:40
TheJuliaoh my :)20:40
opendevreviewDoug Goldstein proposed openstack/ironic master: fix(redfish): avoid supplying DateTimeLocalOffset if its not needed  https://review.opendev.org/c/openstack/ironic/+/97972220:45
opendevreviewcid proposed openstack/ironic master: Check port physnet against portgroup on first add  https://review.opendev.org/c/openstack/ironic/+/97972120:49
opendevreviewDoug Goldstein proposed openstack/ironic master: fix(redfish): correct submission of DateTime to BMC  https://review.opendev.org/c/openstack/ironic/+/97972221:19
opendevreviewMichael Sherman proposed openstack/networking-generic-switch master: docs: address nits for 978799  https://review.opendev.org/c/openstack/networking-generic-switch/+/97976121:40

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!