Wednesday, 2026-01-21

opendevreviewMerged openstack/ironic master: Fix firmware update failure when task remains in RUNNING state  https://review.opendev.org/c/openstack/ironic/+/97099800:21
opendevreviewMerged openstack/ironic master: Fix BIOS firmware not flashing when task completes before first poll  https://review.opendev.org/c/openstack/ironic/+/97099900:28
opendevreviewMerged openstack/ironic master: Fix BMC resource validation to catch all sushy exceptions  https://review.opendev.org/c/openstack/ironic/+/97100000:36
opendevreviewVerification of a change to openstack/ironic master failed: Fix heartbeat for steps with requires_ramdisk=False  https://review.opendev.org/c/openstack/ironic/+/97115200:38
opendevreviewVerification of a change to openstack/ironic master failed: Add retry logic for boot device changes during POST  https://review.opendev.org/c/openstack/ironic/+/97115000:38
opendevreviewMerged openstack/ironic master: Fix introspection failure handling  https://review.opendev.org/c/openstack/ironic/+/97356001:07
TheJuliaSo, I'm starting to think that my headache is more a result of configuration, but haven't qtuie figured it out yet01:12
TheJuliaOkay, I've got it binding01:59
TheJuliait was my own doing, but now need to get/ensure packets flow02:00
TheJuliaThat is for tomorrow02:00
cardoe:/ I was gonna push my update but it sounds like ya do it.02:34
opendevreviewJulia Kreger proposed openstack/networking-baremetal master: WIP: l2vni baremetal mech driver  https://review.opendev.org/c/openstack/networking-baremetal/+/97388904:03
TheJuliaThats my current state, but if that does work entirely, then I suspect we sort of boil down to the far end port management. I need to take a look at your structure a little more closely04:04
opendevreviewVerification of a change to openstack/ironic master failed: Add retry logic for boot device changes during POST  https://review.opendev.org/c/openstack/ironic/+/97115007:42
opendevreviewVerification of a change to openstack/ironic master failed: Fix heartbeat for steps with requires_ramdisk=False  https://review.opendev.org/c/openstack/ironic/+/97115207:42
rpittaugood morning ironic! o/07:43
kubajjgood morning Ironic! o/07:52
kubajjcardoe: dtantsur, Do I understand it correctly that the inspection rules were not 100% complete in Epoxy? (Want to retire inspector before upgrading further)07:53
rpittaujanders cardoe what's the issue with the Metal3 integration job? Happy to help fix that07:53
rpittaukubajj: inspection rules were completed during epoxy (2025.1), at least for in-band inspection, but I would suggest using 2025.2 for out-of-band compatibility plus improvements and bug fixes08:50
kubajjrpittau: ok, we are trying to keep up at least with SLURPs, so we will start using them when we upgrade to Gazpacho09:01
opendevreviewMerged openstack/python-ironicclient stable/2025.2: fix: report compatibility with 2025.2 release of Ironic  https://review.opendev.org/c/openstack/python-ironicclient/+/97329509:06
jandersrpittau it looks like some artifact was missing from GH, seems like a lag between generation and publishing (subsequent runs passed)09:16
jandershttps://zuul.opendev.org/t/openstack/builds?job_name=metal3-integration09:23
jandersit was repeatedly failing but recovered and has many good runs now 09:23
rpittaujanders: I see, CAPI release change cause some mess09:47
rpittauwe could hardcode the version, dynamic resolution as we do now can fail on edge cases like this one09:47
rpittausomethin to discuss on metal3 meeting today maybe09:47
janders++09:47
kubajjcardoe: sorry, somehow I removed the "work in progress" from the change by commenting09:53
dtantsurkubajj: note that cardoe found a series of issues with the new implementation, so you may want to keep an eye on his patches09:54
kubajjdtantsur: yep, will do, thanks09:54
rpittaujanders: without hardcoding, this should help preventing those issues https://github.com/metal3-io/metal3-dev-env/pull/162910:04
opendevreviewMerged openstack/ironic master: Fix heartbeat for steps with requires_ramdisk=False  https://review.opendev.org/c/openstack/ironic/+/97115211:02
opendevreviewMerged openstack/ironic master: Add retry logic for boot device changes during POST  https://review.opendev.org/c/openstack/ironic/+/97115011:02
jandersthanks rpittau11:34
cardoekubajj: no worries. I'm aiming to have a local tool for testing inspection rules.14:00
alegacy_dtantsur: thanks for your feedback on https://review.opendev.org/c/openstack/ironic/+/966470.  I've addressed your comments.14:12
* dtantsur will check after the meeting14:14
opendevreviewnidhi proposed openstack/ironic master: Add LLDP collect for DRAC Redfish inspection  https://review.opendev.org/c/openstack/ironic/+/97063014:15
TheJuliagood morning14:22
TheJuliagood morning again, because I'm a zombie14:25
dtantsurTheJulia: good morning, zombie Julia!14:26
kubajjeicieekddjnflkljehbtcnjgrftlubvrilkfnclinkcd14:32
kubajjoops, sorry 🥲14:32
dtantsurHello, kubajj's cat!14:32
TheJuliameow! pspsppspsppsmeow114:32
cardoeA couple of checks / backports if folks have time: https://review.opendev.org/c/openstack/python-ironicclient/+/973440 https://review.opendev.org/c/openstack/ironic/+/973532 https://review.opendev.org/c/openstack/ironic/+/97353314:36
cardoeHonestly https://review.opendev.org/c/openstack/ironic/+/973557 is another big-ish one that I think improves the behavior and safety of VIF handling.14:37
cardoerpittau: can I ask for a python-ironicclient stable/2025.2 release? Just so I've got a pypi installable version that reports compat with the 2025.2 API version of Ironic?14:38
rpittaucardoe: they're all up, the releases I mean, from 2024.2 to 2026.114:39
cardoesweet thank you!14:39
opendevreviewDoug Goldstein proposed openstack/ironic stable/2025.2: Fix introspection failure handling  https://review.opendev.org/c/openstack/ironic/+/97406914:39
TheJuliahas a release_mapping patch been posted for ironic?14:40
cardoeI don't see one14:42
opendevreviewDoug Goldstein proposed openstack/ironic bugfix/33.0: Fix introspection failure handling  https://review.opendev.org/c/openstack/ironic/+/97407014:43
cardoeDo we have it documented how to make one?14:43
TheJuliaYou just map the current master versions to the released numbered version in the file14:43
TheJuliaI think we link to an example in the docs, its a little different at cycle end because we update the release name to the version as well14:44
rpittauwhy the release_mapping? it14:44
rpittauit's ironicclient14:44
rpittauoh well, I guess we need one as next bugfix is coming out next week :D14:45
TheJuliayeah, for that14:46
rpittaucardoe: an example https://review.opendev.org/c/openstack/ironic/+/96830614:48
cardoeSo there's the node health patch which will bump the version... https://review.opendev.org/c/openstack/ironic/+/966946 do we want to let that land first?14:48
TheJuliaIf we can, it woudl be ideal14:49
cardoeI believe that's the last API bump we've got in the pipeline for 2026.114:49
cardoeI think that node health patch is pretty solid at this point. Assuming it passes tests I gave it my +2. I just re-reviewed it.14:49
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/973440 should land before the node health change to the client.... it fixes the test to actually do something instead of being papered over. The node health client patch continues the papering over the test so it conflicts. But that change shouldn't be in the node health client patch.14:53
cardoeif we're gonna land the node health API bump, rpittau do we want to hold off on 5.15.0 until we get the client patch in there to support that API?15:00
cardoerpittau: actually... -1 on the 5.15.0.. cause we need to fix the portgroup API change15:00
rpittaucardoe: is the fix going to merge soon?15:01
cardoeI'll work on that this morning... then get back to networking with TheJulia 15:01
cardoerpittau: yep I'll link ya... https://review.opendev.org/c/openstack/python-ironicclient/+/973440 is needed first.15:01
rpittauok, letm eblock that then15:01
opendevreviewMerged openstack/python-ironicclient master: fix: test determining latest API version  https://review.opendev.org/c/openstack/python-ironicclient/+/97344015:21
opendevreviewDoug Goldstein proposed openstack/python-ironicclient master: feat: add 'physical_network' and 'category' to portgroup object  https://review.opendev.org/c/openstack/python-ironicclient/+/97409715:36
cardoe^ adds API 1.102 and 1.103 support to the client15:36
cardoeWe've already landed 1.10415:36
cardoe1.105 doesn't need a client change15:37
cardoe1.106 is https://review.opendev.org/c/openstack/python-ironicclient/+/97056215:37
cardoe1.107 is already supported15:39
opendevreviewDoug Goldstein proposed openstack/python-ironicclient master: Filter portgroups by shard  https://review.opendev.org/c/openstack/python-ironicclient/+/97056215:41
opendevreviewMerged openstack/ironic master: Add configuration options for Trait Based Networking  https://review.opendev.org/c/openstack/ironic/+/96805415:41
cardoejanders: please rebase https://review.opendev.org/c/openstack/ironic/+/966946 and we can land that15:43
opendevreviewClif Houck proposed openstack/ironic master: Integrate TBN with vif_attach  https://review.opendev.org/c/openstack/ironic/+/97369015:47
opendevreviewClif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning  https://review.opendev.org/c/openstack/ironic/+/97369115:47
clifcardoe: ^^^ first patch that might possibly be functional wrt TBN + vif_attach?15:48
clifunit tests pass, I need to actually functionally test though15:48
clifthere's some TODOs still that I should address before it merges but I feel like it's very close15:49
clifand I still need to update the sim to model vif_attach flow15:51
cardoegood deal. I'll give it a shot.15:51
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/974097 should be the API needful for your portgroup changes.15:51
cardoeWe've got a ton of openstacksdk stuff in flight too.16:22
cidErm, assuming I rechecked a change that I had open all along and forgot to reload it to know the latest state before doing, what happens if the PR is already merged :) 16:24
JayFNothing!16:25
JayF:D 16:25
opendevreviewDoug Goldstein proposed openstack/python-ironicclient master: feat: add 'physical_network' and 'category' to portgroup object  https://review.opendev.org/c/openstack/python-ironicclient/+/97409716:26
dtantsurYeah, nothing16:26
dtantsurSo, folks. From the look of the code, on any "abort" action, we're doing a complete clean-up: disconnect virtual media, power off, etc. Was it intended?16:26
dtantsurI'm looking into a workflow which is similar to "abort the action, figure out the state of the node, maybe retry", but this behavior gets in the way16:27
JayFabort takes you to a fail state16:27
dtantsur(ref https://github.com/metal3-io/baremetal-operator/issues/2923)16:27
JayFfail state cleans up all the stuff16:27
JayFthat's been the operator expectation long enough that I'd be very, very hesitant to change it16:27
JayFwe've never approached the idea of e.g. resuming cleaning16:28
JayFwith the assumption being a machine is only "cleaned" (or "verb'ed") until it did the process start to finish successfully16:28
dtantsuryeah, I'm not talking about resuming where we left16:28
JayFI'm not clear what you want then16:28
dtantsurmore of: my personal assumption was that we clean up on the way *from* clean fail16:28
dtantsurI want the machine left intact for investigation without it going through any processes16:29
dtantsur(and staying there for any time if needed)16:29
JayFHm.16:29
JayFI... don't really have good ideas for this.16:30
JayFmaintenance would be how to do it if you were there pre-fail16:30
dtantsurMaintenance does not stop all actions in Ironic16:31
JayFIt (at least last release I actively maintained a cloud) would effectively pause in-band cleaning16:31
JayFsince hte heartbeat woudl be ignored16:31
JayFI'm sure it's not quite as clean for oob16:31
dtantsurAnother complication: one of the possible actions is "just remove the node, it's too broken". It's possible in DEPLOYFAIL but not in DEPLOYWAIT IIRC.16:32
dtantsurFunnily, we have these options https://opendev.org/openstack/ironic/src/branch/master/ironic/conf/conductor.py#L505-L518 and they default to *false*16:35
dtantsurBut I don't think they fully work. And it looks like you assume they default to true :)16:36
JayFpoweroff in cleanfail defaults to false16:43
JayFwhcih means your desired behavior should already be there16:43
JayFand if it's not, it's a regression16:43
dtantsurI need to check it in reality (probably next week), but it looks like we also call tear_down_cleaning, which calls power off unconditionally..16:43
opendevreviewDoug Goldstein proposed openstack/python-ironicclient master: feat: add 'physical_network' and 'category' to portgroup object  https://review.opendev.org/c/openstack/python-ironicclient/+/97409716:44
cardoeIf someone else would +2 and +W, https://review.opendev.org/c/openstack/python-ironicclient/+/970562 that's another API tweak that's in gazpacho and makes the client compatible. Trying to push these through so that rpittau can make a gazpacho release of the client that's compatible with ironic gazpacho API.16:47
JayFI refuse to +2W that (I'm the author) :D 16:48
cardoeFair but then what about... https://review.opendev.org/c/openstack/python-ironicclient/+/974097 :-D16:49
cardoeJayF: I don't understand why your download performance patch breaks metal3 but it definitely does.16:49
rpittauwe don't really need to add all the features now :)16:49
JayFcardoe: I couldn't even figure out where to get the damn logs to troubleshoot it, so I'm mildly screwed there unless I can get rpittau or dtantsur to help :)16:50
rpittauJayF: which patch ?16:50
JayFit certainly doesn't /seem/ like something that should only impact metal316:50
cardoerpittau: https://review.opendev.org/c/openstack/ironic/+/96450216:50
JayFhttps://review.opendev.org/c/openstack/ironic/+/96450216:51
cardoerpittau: just trying to marshal in the last of the API tweaks to make everything compatible.16:51
rpittauwaiting for the patch to spit new logs16:52
rpittaucardoe: ack16:52
rpittaucardoe: are the API related changes already released?16:53
cardoeYes.16:53
rpittauok16:53
cardoeThis is just catching the client up.16:53
rpittauI blocked the release again16:54
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/970562 and https://review.opendev.org/c/openstack/python-ironicclient/+/974097 make the client compatible with what's currently in ironic master.16:54
rpittauah16:54
rpittauthen that's a nope16:54
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/974097 brings compatibly to what we released as bugfix/33.016:55
rpittauok so anything in master can wait from client perspective16:55
rpittauotherwise we release a client that is not compatible with ironic latest release16:56
opendevreviewVerification of a change to openstack/python-ironicclient master failed: Filter portgroups by shard  https://review.opendev.org/c/openstack/python-ironicclient/+/97056216:56
rpittauso https://review.opendev.org/c/openstack/python-ironicclient/+/970562 and https://review.opendev.org/c/openstack/python-ironicclient/+/974097 are nope16:56
cardoe?16:57
cardoegazpacho is master?16:57
rpittauyep16:57
cardoeSo those are patches against master of the client?16:57
rpittauyeah but we don't need to wait for them for the release :)16:57
cardoeokay. I was just trying to get everything on equal level16:58
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/974097 is what's in bugfix/33.016:58
rpittauwhich is ok, but we can't release on client something that is not released on server16:58
cardoeWell there's already a few patches in client master for APIs that aren't released.16:59
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/955102 for example from December is in client master and that's only in ironic master17:00
rpittauthen we wait for the client release17:00
rpittauI will do a bugfix anyway next week, or even end of this week17:00
cardoeThe client code will omit things that are too new anyway.17:01
rpittauuhm the instance_name is in 33.017:01
rpittauso that client patch is legit17:01
cardoeoh you're right that was 1.0417:02
cardoeer 1.10417:02
cardoeso then yes https://review.opendev.org/c/openstack/python-ironicclient/+/974097 adds 1.102 and 1.103 support which is in 33.017:02
rpittauyeah17:02
rpittauI checked the list before submitting the release, I didn't spot anything weird17:02
rpittauok17:02
rpittauso we can go ahead with the release after that17:03
rpittauI will block the others17:03
cardoesounds good17:04
cardoeI'll work with janders to rebase his node health... I think we'll get him to renumber it to 1.109. And take cid's https://review.opendev.org/c/openstack/ironic/+/973016 as 1.108 since that's about to pass tests and not have any conflicts.17:05
cardoeI've gone through all the open Ironic changes and that's the extent of the API changes.17:09
cardoeAt least those that seem ready for 2026.117:09
cardoeSo rough line in the sand for 2026.1 will be 1.10917:09
rpittaucardoe: sounds about right, I will review the release mapping before the bugfix release anyway, we can leave the final changes for the final G release17:12
JayFcardoe: I'm trying a new thing. Feeding claude-code the failure logs from that image test17:13
rpittauJayF: have you checked the ironic logs ?17:15
rpittauhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_e70/openstack/e704ed6f05c74fa1a620279f09023fe2/controller/before_pivoting/ironic.log17:15
rpittauHttpImageService.download() got an unexpected keyword argument 'checksum': TypeError:17:15
JayFoh, perfect17:16
JayFthank you 17:16
JayFI can fix it! I have the technology! :D 17:17
JayFclaude came to the same conclusion too, fwiw17:17
JayFdownload logs -> point claude at them might not be the worst CI troubleshooting pattern17:17
rpittauI'm glad I'm as good as Claude :D17:17
JayFwell, claude isn't busy doing 4000000 other things :)17:18
rpittaulol17:18
JayFif I had rpittau as a executable on my CLI to think for me, I'd be SUPER productive ;) 17:18
rpittauthanks, too kind :)17:18
cardoesudo rpittau is probably safer than sudo claude too17:51
cardoeAlright https://review.opendev.org/c/openstack/python-ironicclient/+/974097 passed tests and when that gets +W'd that'll unblock the client releases.17:53
opendevreviewDoug Goldstein proposed openstack/ironic stable/2025.2: fix redfish inspect system product name  https://review.opendev.org/c/openstack/ironic/+/97148718:08
opendevreviewcid proposed openstack/ironic master: Type annotation guide  https://review.opendev.org/c/openstack/ironic/+/97422418:09
* dtantsur welcomes rpittau-as-a-service20:33
dtantsurFolks, I'll be out for this week, back on Monday (likely later than usual)20:33
opendevreviewJulia Kreger proposed openstack/networking-baremetal master: WIP: l2vni baremetal mech driver  https://review.opendev.org/c/openstack/networking-baremetal/+/97388920:55
opendevreviewSteve Baker proposed openstack/ironic master: WIP autodetect deploy interface  https://review.opendev.org/c/openstack/ironic/+/97318720:58
opendevreviewSteve Baker proposed openstack/ironic master: Add an autodetect deploy interface  https://review.opendev.org/c/openstack/ironic/+/97318722:30
opendevreviewSteve Baker proposed openstack/ironic master: Replace ironic-tempest-bios-ipmi-direct with -autodetect  https://review.opendev.org/c/openstack/ironic/+/97426022:30
opendevreviewJay Faulkner proposed openstack/ironic master: Improve image download performance  https://review.opendev.org/c/openstack/ironic/+/96450222:48
opendevreviewSteve Baker proposed openstack/ironic master: Document autodetect deploy interface  https://review.opendev.org/c/openstack/ironic/+/97426223:01

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