15:01:26 <TheJulia> #startmeeting ironic
15:01:26 <opendevmeet> Meeting started Mon Jan 12 15:01:26 2026 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:26 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:26 <opendevmeet> The meeting name has been set to 'ironic'
15:01:30 <alegacy> o/
15:01:32 <TheJulia> Good morning Ironic!
15:01:33 <dtantsur> o/
15:01:37 <clif> o/
15:01:43 <JayF> o/
15:01:52 <janders> o/
15:02:29 <TheJulia> This will be our first meeting of 2026!
15:02:38 <clif> \o/
15:02:45 <TheJulia> Consider it a slightly slow meeting, because it looks like we need to update the agenda
15:03:10 <TheJulia> Our agenda, as always can be found on the wiki.
15:03:44 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic
15:04:00 <TheJulia> Everyone have coffee?
15:04:13 <TheJulia> #topic Announcements / Reminders
15:04:15 <JayF> That's what the 5 minutes was for 😂
15:04:21 <TheJulia> lol, true!
15:04:28 <kubajj> o/
15:04:33 <TheJulia> Our first item is a general reminder for folks to review the patches tagged ironic-week-prio.
15:04:41 <TheJulia> #link https://tinyurl.com/ironic-weekly-prio-dash
15:04:52 <TheJulia> There are 31 patches, lets try to get that below 25 again
15:05:11 <TheJulia> Furthermore, in terms of general reminder of where we are in the release cycle for 2026.1
15:05:24 <TheJulia> #link https://releases.openstack.org/gazpacho/schedule.html
15:05:43 <dtantsur> There is no such thing as enough coffee this January
15:05:50 <TheJulia> This week is week R-11. A few reminders will follow on.
15:05:55 <janders> coffee++
15:06:35 <TheJulia> R-6 is final release for non-client libraries. R-5 is final release for client libraries. If your working on API surface changes, or have one which will impact the API surface, please highlight your work and remember to use the hashtag ironic-week-prio.
15:06:58 <TheJulia> Moving on!
15:07:00 <TheJulia> #topic Working Group Updates
15:07:11 <TheJulia> First update, alegacy are you around regarding standalone networking?
15:07:18 <alegacy> yep, i'm here
15:07:29 <alegacy> Looks like a few patches merged this morning.  thank you!
15:07:47 <alegacy> hoping to be able to continue that momentum in the coming weeks and wrap this up.
15:08:27 <alegacy> only 1 big patch left in the ironic repo... the other 3 small ones are cleanup/doc.
15:08:36 <TheJulia> cool cool
15:08:39 <alegacy> and then the 1 other patch over in bifrost.
15:08:45 <cid> o/
15:08:47 <TheJulia> Very cool, anything else?
15:09:02 <alegacy> nope, i'll keep an eye on incoming review comments.
15:09:08 <TheJulia> Awesome!
15:09:38 <TheJulia> Onward! Async IO. cid/dtantsur, any update? I'll apologize now I didn't look at the outstanding WIP patches yet.
15:09:46 <dtantsur> I have some, yes
15:10:06 <dtantsur> First, we have a proof-of-concept for asynchronous sensor collection: https://review.opendev.org/c/openstack/ironic/+/970450 and https://review.opendev.org/c/openstack/ironic/+/970842
15:10:22 <dtantsur> The latter is just for testing without refactoring the conductor
15:10:43 <dtantsur> The former can be treated as a preview of how the asynchronous API may look like (don't worry too much about implementation details so far).
15:10:51 <TheJulia> Good details, thanks!
15:10:53 <dtantsur> I made two very opinionated decisions there
15:11:14 <dtantsur> 1) The new client is inside Ironic not Sushy. Given the discussion around moving Sushy in, I think it's a valid thing to do.
15:11:27 <dtantsur> 2) The new client is also low-level, it does not come with ready-to-use structures.
15:11:56 <dtantsur> Here is where we may end up arguing quite a bit. I'm honestly quite tired of keeping sushy's structures up-to-date, especially since we use a tiny share of them.
15:12:06 <rpittau> o/
15:12:12 <dtantsur> Check the script in the 2nd patch for how the API is *used* in practice. It's not as crazy as it may initially sound.
15:12:24 <dtantsur> Finally, I'm working on the spec for all this:
15:12:28 <TheJulia> I think #2 makes a ton of sense given some of the object instantiation overhead which exists, but it really just depends more so on the end result of "what"
15:12:31 <dtantsur> #link https://review.opendev.org/c/openstack/ironic-specs/+/972754 WIP spec for async sensor collection
15:12:45 <dtantsur> It has the motivational section and the high-level implementation proposal, so ready for early feedback.
15:12:53 <TheJulia> cool cool
15:12:56 <TheJulia> Anything else?
15:13:02 <opendevreview> Jacob Anders proposed openstack/ironic master: Add hardware health monitoring via management interface  https://review.opendev.org/c/openstack/ironic/+/966946
15:13:04 <dtantsur> I've also tried a purely threaded approach, and our futurist pool is not suitable for 3500 threads
15:13:18 <cid> tks, dtantsur. I took a quick look at what you have going on in those patches. No updates on my side regarding Async
15:13:20 <dtantsur> While the async script finishes in 30 seconds on 3500 fake nodes from sushy-tools (not VM based).
15:13:33 <dtantsur> That's all from me. A bit verbose, but it summarizes a month worth of work :)
15:13:57 <cid> ++
15:14:32 <TheJulia> Cool cool
15:14:35 <TheJulia> Okay, onward!
15:14:52 <TheJulia> VXLAN Networking. That is my area mostly, although cardoe feel free to chime in.
15:15:16 <cardoe> bleep blorp
15:15:25 <TheJulia> The spec is in a ready to review state over at https://review.opendev.org/c/openstack/ironic-specs/+/959401 and provides the overview of attachments and required steps.
15:16:32 <TheJulia> The implementation is basically 3 parts, two of which are needed as well for Neutron EVPN to be used later on if an operator chooses to do so, but the model is more a physcial bridge/connection model to the fabric allowing for operators to make decisions based on their traffic *and* loads, i.e. leaning more towards ASICs doing things than CPUs and network card acceleration features.
15:17:14 <TheJulia> We're starting to see some initial implementation patches at this point in time.
15:17:19 <TheJulia> cardoe: do you have anything else to add?
15:17:38 <cardoe> No I think that's spot on.
15:17:58 * TheJulia reloads the agenda to see if anyone snuck a discussion topic in
15:18:15 <cardoe> If I could get the little time trinket from Happy Potter that Dumbledore gives Hermoine, I'd make a lot more progress.
15:18:29 <TheJulia> Okay, Given we have no discussion topics, we can proceed to Bug Deputy updates!
15:18:50 <TheJulia> #topic Bug Deputy Updates
15:19:05 <cid> That's me
15:19:16 <cid> I triaged two bugs and a new RFE enabling direct deploy interface to switch to ramdisk https://bugs.launchpad.net/ironic/+bug/2137729.
15:19:44 <JayF> that's my RFE if anyone has questions when we get there
15:20:15 <cid> Also, I would love to get feedback on this change: https://review.opendev.org/c/openstack/ironic/+/973016
15:20:54 <TheJulia> Okay, so who would like to serve as the deputy for next week?
15:21:01 <TheJulia> (for the next week)
15:21:15 <cardoe> cid: yeah I'm a +1 on that change. I've got it opened to fully review it so that I can give it a +2.
15:21:17 <dtantsur> huh, yeah, disable_ramdisk makes sense for servicing
15:22:18 <cid> Alright cool. Because it felt like something that might or not need a fix, I just was not sure
15:22:32 <cid> TheJulia, sign me up for bug deputy for next week.
15:22:41 <TheJulia> cid: okay!
15:22:45 <TheJulia> Onward!
15:22:46 <cardoe> JayF: I think switching the deploy interface dynamically based on the image overall makes sense.
15:22:49 <TheJulia> #topic RFE Review
15:22:58 <TheJulia> so, JayF, you have the floor
15:23:31 <JayF> I mean, I'm following the pattern laid out by stevebaker[m] for the direct->bootc swap
15:24:04 <JayF> I was worried it'd become an "X to Y" deploy interface change problem, but realistically bootc/direct/ramdisk/anaconda is probably the entire list of ones reasonable for this feature
15:24:27 <JayF> so I don't think there's a need to genericize it too much, just follow Steve's pattern
15:24:43 <JayF> I already validated w/Dan that Nova+Glance shouldn't need code changes (only docs)
15:24:44 <JayF> so I
15:24:48 <dtantsur> My only request would be on the code level: please make a reasonable abstraction for it instead of just sticking more untested logic into deploy_utils
15:24:49 <TheJulia> Yeah, the image itself hints/supplies almost every ounce of missing detail
15:24:52 <JayF> **so I'm hoping to get this in for gazpacho
15:24:53 <dtantsur> (maybe teh ship has sailed already)
15:25:01 <JayF> dtantsur: review stevebaker[m]'s change
15:25:07 <JayF> dtantsur: I will follow that pattern :)
15:25:13 <dtantsur> has it merged already?
15:25:15 <JayF> no
15:25:22 <JayF> he owes me a guardrail
15:25:33 <JayF> (so we don't try to enable bootc on conductors without bootc)
15:25:49 <dtantsur> Well, at least it's not deploy_utils :D
15:26:32 <TheJulia> Do we have anything else to discuss regarding this RFE?
15:26:46 <dtantsur> (oh I don't like this code oh oh)
15:27:03 <JayF> dtantsur: yeah I figured you might have that reaction.
15:27:55 <TheJulia> The bottom line is it needs to be driven by the data on hand, not a user requesting it in large part because all of the data and information is present based upon the image source/service, so somehow that needs to be reconcilable.
15:28:09 <dtantsur> I don't hate the feature, just using validate() for that
15:28:29 <TheJulia> err, I'm not a fan on validate()
15:28:42 <TheJulia> I'd much rather see it based upon the flow deeper in, but that leans towards deploy_utils as well
15:28:49 <TheJulia> I've not looked at it in a while though
15:29:06 <JayF> I'm happy my RFE pointed more eyes at this :)
15:29:52 <TheJulia> There are only so many ways to solve the problem though short of making changes invasive.
15:30:01 * TheJulia suspects brains need to ponder
15:30:11 <TheJulia> Do we want to discuss the idea cardoe proposed just before the meeting?
15:30:19 <JayF> If you care, please prioritize the review as I really, really want to get it in for G
15:30:36 <dtantsur> Will you hate me for suggesting a new "dynamic" deploy interface?
15:30:55 <JayF> no, I actually think that's probably a solid idea
15:30:55 <cardoe> Will you hate me if I say yes? :D
15:31:07 <JayF> Only real downside is my use case is "try ramdisk driver with less risk"
15:31:14 <cardoe> I actually think dynamic makes sense and it can change and the others won't change.
15:31:15 <JayF> and pushing down a "change all your interfaces" is not going to make people happy
15:31:27 <JayF> but that's an operational problem not an architectural one
15:31:41 <TheJulia> ... There is a point where that is a reasonable thing to do
15:31:42 <cardoe> We can make "direct" be an alias for "dynamic".
15:31:56 <cardoe> And the existing direct becomes "agent"
15:32:10 <JayF> I dislike that
15:32:14 <cardoe> And then no change required of folks to get the functionality enabled.
15:32:35 <TheJulia> I *suspect*, if we act quickly, it won't be a big deal
15:33:06 <TheJulia> And by that meaning, the interfacing and patterning... as long as it lands around the same time, its not a big deal and folks can begin to adopt it
15:33:17 * dtantsur https://review.opendev.org/c/openstack/ironic/+/966761/comment/1cbc9c11_d65ed2bf/
15:36:27 <TheJulia> sgtm
15:36:42 <TheJulia> Are we good with RFE review?
15:36:59 * TheJulia hears the crickets
15:37:42 <TheJulia> #topic Open Discussion
15:37:42 * dtantsur enjoys the cricket sound
15:38:06 <dtantsur> Just as a heads-up: I'll have a bit of an odd availability in January because of a move
15:38:22 <dtantsur> Don't get surprised if I take unusually long to respond or review something. Please bear with me for now.
15:38:22 <janders> dtantsur good luck, hope it all goes smooth!
15:38:35 <dtantsur> Thx! It's, as usual, quite a show :D
15:38:41 <JayF> I will be out (up to) the last two weeks in Feburary for a medical thing, similarly will be unavailable.
15:39:05 <TheJulia> dtantsur: I hope it all goes well!
15:39:16 <janders> I have a couple topics. First - I had a brief chat to DMTF folks about multi-system-systems.
15:39:37 <TheJulia> I have nothing really coming up so I should be around albeit likely very heads down on vxlan for the next month or two
15:39:52 <TheJulia> janders: seems like the floor is yours
15:40:01 <janders> Thank you TheJulia
15:40:10 <janders> regarding DMTF discussion: short version: "Anything that isn't bootable isn't a system. A chassis can be used to group together components."
15:40:40 <janders> so it would seem to me that as far as they are concerned, if a System doesn't have enough components to boot up a workable OS, that's not right
15:41:22 <janders> so it seems we're not the only ones of an impression that the hardware that JayF mentioned is a bit weird - it's not just us Ironic'ers
15:41:46 <dtantsur> We cannot do much about the already existing hardware but I wonder if they can spread this message somehow
15:41:53 <dtantsur> to prevent more instances of this
15:41:55 <JayF> janders: is that published somewhere?
15:42:01 <JayF> janders: or hallway conversations?
15:42:11 <TheJulia> Hmm, Interesting
15:42:12 <JayF> I have to have something in writing I can toss at the vendor architects/presales
15:42:14 <janders> JayF inconveniently, in DMTF-member-only repo
15:42:27 <janders> but we can see what we can do (I can ask folks)
15:42:34 <janders> but there is more
15:42:35 <JayF> if you can email me details about it even if I don't have access, it may help
15:42:53 <janders> long version: they shared some docs to look at composability, etc which we can look at together if you're interested JayF
15:43:08 <JayF> I'm academically interested; I
15:43:11 <TheJulia> I'd ask them for some way to close the loop since JayF can't access that repo without membership in the DMTF
15:43:11 <janders> they further reinforce the "it needs to have enough kit to boot OS" line
15:43:18 <JayF> **I'm not convinced it will wrap into value for my downstream
15:43:45 <janders> I can certainly help gathering documentation to potentially share with the $vendor
15:43:46 <dtantsur> If we can at least prevent this from becoming a new norm...
15:43:52 <TheJulia> dtantsur: yeah
15:43:56 <janders> agreed
15:44:02 <janders> I can follow up in the thread
15:44:27 <janders> everyone is welcome to participate in the discussion but unfortunately DMTF membership is required to see the issue I raised
15:44:37 <TheJulia> So, one thing I'm wondering, as a devil's advocate... what if the device *is* booting it's own OS but its not user managable? I realize that is a bit blurring of the exact case JayF and some others have observed with some of the hardware out there
15:45:01 <JayF> Yep.
15:45:08 <TheJulia> And then... what if vendors view it that way and believe they are in compliance.
15:45:13 <JayF> I think that's likely true for the hardware I'm talking about here
15:45:22 <JayF> wow way to read between the lines TheJulia
15:45:27 <JayF> I hadn't even put that all together
15:45:48 <TheJulia> JayF: this is what working for lawyers for like... a third of my career has done to me.
15:45:52 <dtantsur> "Everything with firmware is booting an OS" is quite a take..
15:45:57 <dtantsur> but yeah, I can see it being appealing
15:46:01 <JayF> dtantsur: in some of this hardware, it's a real OS
15:46:12 <JayF> dtantsur: think a DPU or a BMC which has an optionally operator-accessible OS
15:46:24 <JayF> dtantsur: I know on this gear you can put the DPU into a operator-accessible OS mode
15:46:41 <JayF> it's computers all the way down /o\
15:46:49 <JayF> and... shit
15:46:50 <janders> LOL
15:46:53 <dtantsur> I guess where the line could be drown is the question of self-sufficiency as a system
15:46:55 <JayF> putting the computer in a mode where the DPU is NIC only
15:47:00 <JayF> reduces the number of systems to 2
15:47:04 <JayF> this is EXACTLY what is happenin
15:47:05 <TheJulia> yup, now without I2C for inter-device communications!
15:47:12 * TheJulia hides
15:47:21 * dtantsur sighs
15:47:25 * JayF nominates TheJulia to chair the DMTF, too
15:47:26 <janders> I think there are two action items here: 1) I will share the info I have with JayF and 2) update the thread with our concerns/questions
15:47:40 <TheJulia> dtantsur: I think that is the most "ironic" response ever :)
15:47:54 <dtantsur> lol
15:48:18 <TheJulia> JayF: ouch! But if that is what the members want, who am I to stand in the way ?!? ;)
15:48:50 <JayF> you can not only read lawyerspeak, you can use it!?!?!
15:48:59 <JayF> AGREED this is dangerous ;)
15:49:08 <janders> I see some opportunities here
15:49:29 <dtantsur> If DMTF was chaired by people like TheJulia rather than just vendors.. okay, I shut up here
15:49:40 <janders> dtantsur++
15:50:04 <TheJulia> lol
15:50:16 <TheJulia> Y'all have made my day, thank you!
15:50:32 <TheJulia> do we have anything else to discuss? Pending chaos, or crazy ideas?
15:50:39 <janders> TheJulia in seriousness are you a DMTF member?
15:50:49 <janders> if not, would you consider joining?
15:51:05 <TheJulia> I am not, I guess I could, send me the link or page to the process
15:51:12 <janders> will do
15:51:15 <TheJulia> Thanks
15:51:26 <JayF> These organizations need a hook-point for stakeholders like Ironic
15:51:28 * TheJulia might have looked at it ages ago but I really don't remember at this point
15:51:36 <JayF> one that doesn't require handing over of money or becoming members or whatnot
15:51:37 <janders> OK: if nothing more on multi-system I would like to jump on the monitoring patch
15:51:42 <JayF> It's unfortunate it's structured this way.
15:51:55 <TheJulia> JayF: We pointed that out to them in the past and the answer was bascially "join the forum"
15:52:21 <JayF> Most collaborations locked behind a user login is hostile to OSS
15:52:28 <TheJulia> janders: have you made a parallel patch for the client and yet another by sdk ?
15:52:40 <janders> I have a pair - API side and client side
15:52:49 <TheJulia> JayF: I agree, and even getting issues really resolved, ala this exact issue
15:52:51 <janders> https://review.opendev.org/c/openstack/ironic/+/966946
15:52:51 <janders> https://review.opendev.org/c/openstack/python-ironicclient/+/967055
15:53:01 <TheJulia> janders: openstacksdk as well
15:53:20 <janders> TheJulia noted. What do I need to break out to or add to SDK?
15:53:47 <janders> (my first change requiring client side work, hence asking)
15:55:06 <TheJulia> janders: the api version and the field itself, AIUI
15:55:22 <janders> TheJulia ACK
15:55:28 <janders> will do
15:55:41 <TheJulia> Anything else today?
15:55:51 <janders> will I need to update the API/client patches again once that's done, or is SDK chenge self contained?
15:56:08 <TheJulia> Somehow we managed to use virtually the whole hour. I'm sure people need to refill their coffee or switch to tea... or something stronger.
15:56:19 <TheJulia> janders: it is elf contained
15:56:21 <TheJulia> self
15:56:25 <TheJulia> not, elf
15:56:26 <janders> noted, thank you
15:56:31 <TheJulia> no elfs are located in the sdk, as far as I'm aware.
15:56:41 <janders> if cardoe and JayF have time I would appreciate re-reviews
15:56:47 <janders> all comments should be addressed
15:56:58 <janders> local tests pass, just waiting for CI
15:57:02 <cardoe> will do
15:57:06 <janders> client change has one +2
15:57:09 <janders> thank you!
15:57:20 <janders> I appreciate your time folks
15:57:29 <janders> that's all from me
15:57:30 <dtantsur> Meanwhile, I think I like the idea of a "dynamic" RAID interface as the next step after the deploy one. Both of these will make Metal3's code somewhat less annoying.
16:00:18 <TheJulia> Could be super useful
16:00:33 <TheJulia> and I think this is generally the next/logical progression for easing the user experience
16:00:49 <TheJulia> by removing, as JayF puts it, part of a decoder ring being necessary
16:01:12 <JayF> we've been big on being explicit
16:01:30 <JayF> but need to go back and add hooks -- like here -- where we can use metadata to store explicit decisions
16:01:54 <JayF> like "use this image with bootc/ramdisk/anaconda" or "pick the fibrechanel interface if the network is turquoise"
16:02:02 <TheJulia> or make the decisions to ease the use case/patterning
16:02:08 <TheJulia> heh
16:02:13 <TheJulia> Okay folks, we're moving to colors
16:02:28 <TheJulia> There will be no green and purple bins in this channel ;)
16:02:34 <TheJulia> Thanks everyone! Have a great week!
16:02:40 <dtantsur> My favourite colors :(
16:02:42 <TheJulia> #endmeeting