15:00:54 <TheJulia> #startmeeting ironic
15:00:54 <opendevmeet> Meeting started Mon Jun  1 15:00:54 2026 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:54 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:54 <opendevmeet> The meeting name has been set to 'ironic'
15:01:13 <JayF> o/
15:01:13 <TheJulia> We can always start the meeting, do we feel we have sufficient attendance to have quorum to make decisions is the question
15:02:31 <iurygregory> o/
15:02:43 <kubajj> o/
15:02:43 <TheJulia> Do we feel we have enough folks to consider quorum?
15:02:59 <TheJulia> I count 4 hopefully caffinated individuals
15:03:12 <JayF> full disclosure; I'm only a half-cup in
15:03:22 <iurygregory> 3.5 in this case lol
15:03:29 <opendevreview> Merged openstack/ironic master: Improve vmedia insertion error messages  https://review.opendev.org/c/openstack/ironic/+/982626
15:03:32 <clif> o/
15:03:41 <TheJulia> I'm only 1 cup in
15:03:49 <TheJulia> okay, another victi^Wattendee ;)
15:04:08 <TheJulia> I guess we have enough quorum to go through the motions
15:04:20 <TheJulia> Welcome to this week's Ironic meeting of Irony where we shall discuss all things Ironic!
15:04:29 <TheJulia> Our agenda can be found on the wiki!
15:04:44 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic
15:04:55 <TheJulia> #topic Announcements / Reminders
15:05:25 <rpittau> o/
15:05:30 <TheJulia> Our standing reminder to review outstanding items tagged with ironic-week-prio. I realize folks are also starting to take summer time vacations as well, but lets just try to keep momentum up!
15:05:35 <cid> o/
15:06:11 <TheJulia> In terms of the release schedule, this is week is R-17.
15:06:17 <TheJulia> #link https://releases.openstack.org/hibiscus/schedule.html
15:06:18 <dtantsur> o/
15:06:29 <rpittau> related to that, I'm planning to cut bugfix branches for ironic and IPA tomorrow
15:06:29 <rpittau> I think we're in good shape, but just in case please review the outstanding ironic patches
15:06:45 <TheJulia> rpittau: can I ask you to do that wednesday?
15:06:54 <rpittau> sure! :)
15:06:57 <TheJulia> Thanks!
15:07:04 <TheJulia> Moving on!
15:07:07 <TheJulia> #topic Working Group Updates
15:07:22 <TheJulia> dtantsur: any async io updates?
15:07:32 <iurygregory> I have o/
15:07:37 <TheJulia> go ahead!
15:08:00 <dtantsur> TheJulia: I've passed the lead on this to iurygregory :)
15:08:00 <iurygregory> I took over the spec, and updated to address most of the comments https://review.opendev.org/c/openstack/ironic-specs/+/972754
15:08:25 <iurygregory> so please review and let me know if there is something I should address on it
15:08:34 <TheJulia> dtantsur: ack ack
15:08:38 <TheJulia> iurygregory: Cool, thanks!
15:08:41 <TheJulia> Folks, you know what to do!
15:08:51 <TheJulia> #topic Discussion topics!
15:08:58 <TheJulia> We have one discussion topic today!
15:09:17 * TheJulia places the podium and a microphone in front of the janders stand-in
15:09:23 <iurygregory> ok, I think it`s on me
15:10:17 <TheJulia> Yes!
15:10:31 <iurygregory> so, after the PTG we did some investigation about Firmware Upgrades
15:10:46 <iurygregory> we came up with and etherpad with details
15:10:56 <iurygregory> #link https://etherpad.opendev.org/p/ironic-firmware-updates-v2
15:11:04 <iurygregory> and a bug tracker was created also
15:11:28 <iurygregory> #link https://bugs.launchpad.net/ironic/+bug/2153965
15:11:55 <iurygregory> not sure if folks had a chance to read it and have questions about it
15:12:09 <dtantsur> I wonder if a spec would be a more familiar format..
15:13:18 <iurygregory> janders shared with some questions to help drive the discussion
15:13:22 <TheJulia> Overall, I think I agree with everything I've read on this topic so far, but it feels a bit too verbose and I'd prefer simplification. I also would really wonder if we could get some data points to to help answer the lingering why question in a more concrete form. It almost feels like a "we're heading down this path because we must interate it.
15:13:51 <TheJulia> and I guess without a solid reason or answer to the question of "why?", I'm just a little skeptical
15:14:02 <iurygregory> TheJulia, got it!
15:14:06 <JayF> My only question/request is that we have a good swath of redfish hardware being looked at for this feature
15:14:16 <JayF> as long as we aren't modeling it against just one specific model it all seems OK to me
15:14:34 <TheJulia> That is my other concern, because there is such a variety of behavior, this effort needs to be super careful as a result.
15:14:58 <iurygregory> yeah, we have tested with two Dells and one HPE if I recall
15:15:13 <TheJulia> Any other thoughts/discussions/questions/concerns/cups of coffee to sip, or suddenly appearing wet cat.
15:15:15 <TheJulia> ?
15:15:23 <dtantsur> I think the gist of it is something along the lines "if you submit several components as part of a single step, we're free to merge or rearrange them"
15:15:24 <JayF> Given we already know that lenovos act weird w/r/t booting, that might be a good one to look at as well if we have one availble
15:15:28 <iurygregory> R640, XR8620t, DL380 (I think)
15:15:36 <dtantsur> which does leave the escape hatch of submitting updates separately
15:15:42 <iurygregory> JayF, I wish we had some lenovo to test this =(
15:16:11 <TheJulia> dtantsur: that is kind of my take as well, fwiw.
15:16:36 <TheJulia> I guess the original thought was in operator supplied order
15:16:48 <TheJulia> but, maybe thats not great, dunno
15:17:00 <dtantsur> yeah, the current implementation treats the updates as separate steps
15:17:16 <dtantsur> which is not great if you want to update 3-4 components, and each does a reboot just because
15:17:24 <TheJulia> Yeah
15:17:31 <iurygregory> if we are ok with rearranging the order of the updates it would help a lot based on our investigation, so we can avoid unnecessary reboots (because we could do a single reboot for non-bmc updates)
15:17:33 <TheJulia> But some of them may or might and only the BMC may know for sure
15:17:41 <TheJulia> Which will also govern responses
15:17:48 <TheJulia> "like, configuration job pending reboot"
15:18:15 <dtantsur> It's again the "vendors will only agree to disagree" situation, and we want to give a humam more choice :)
15:18:23 <TheJulia> yeah, agree
15:18:43 <dtantsur> the only potentially issue is that we're changing the behavior of an already working scenario
15:18:51 <TheJulia> the thing which worries me is mostly just a bmc saying "I've got this, I can't do anything else until I reboot and do this with a configuration job because of how I do this firmware update as compared to my own update"
15:20:14 <dtantsur> if that's a concern, just submit several steps, which will work the same way as now
15:20:32 <TheJulia> Well, the operator has no way to know that *until* the are in the middle of it
15:20:37 <TheJulia> so... *shrug*
15:20:48 <TheJulia> Anyway, Are we good to proceed onward?
15:20:52 <dtantsur> Many operators that I deal with have a very-very carefully picked hardware
15:21:02 <dtantsur> yeah, we're digging too deeply into it :)
15:21:08 <TheJulia> yup
15:21:12 <dtantsur> I guess the question is what janders is supposed to do next
15:21:20 <iurygregory> yeah
15:21:22 <TheJulia> dtantsur: keep on keeping on?
15:21:33 <dtantsur> Like, assume the proposal is accepted and work on the code?
15:21:36 <iurygregory> does it needs a spec?
15:21:38 <dtantsur> Or do more to convince us?
15:21:44 <dtantsur> Or address certain specific concerns?
15:21:53 <TheJulia> I'm semi-convinced... however... we need to give a clear answer to the why question
15:21:57 <TheJulia> and if that means a spec, so be it
15:22:07 <dtantsur> Why is essentially a downtime window
15:22:19 <dtantsur> 5 components times 10 minutes reboot is nearly an hour of downtime
15:22:37 <TheJulia> yup, we shouldn't get into that in irc, that needs to be in the recorded artifacts
15:22:44 <TheJulia> i.e. RFE or even spec
15:22:55 <dtantsur> Agreed. I assume janders will read this discussion tomorrow
15:22:55 <TheJulia> because operators are going to have different wants/demands/opinions
15:23:01 <TheJulia> ++
15:23:07 <TheJulia> Onward?
15:23:12 <dtantsur> yep
15:23:15 <TheJulia> #topic Bug Deputy Updates
15:23:22 * TheJulia pushes the podium over to cid
15:23:34 <cid> \o/
15:23:41 <cid> Moderately busy week.
15:23:49 <cid> I entered 5 newly filled bugs to the triaged state.
15:23:55 <cid> One around DMTF Redfish schema is something I left open as needing help to triage
15:23:55 <cid> https://bugs.launchpad.net/ironic/+bug/2154614
15:24:04 <cid> 5 new RFEs but there's really only 3 valid RFEs on the list because of the 5, one is a duplicate of discussion topic and the other I filled as an RFE and is ending up as just a fix.
15:24:14 <cid> That leaves only:
15:24:24 <cid> https://bugs.launchpad.net/networking-generic-switch/+bug/2154349: Refresh ngs_trunk_ports with full VLAN segment list on each network operation
15:24:24 <cid> https://bugs.launchpad.net/ironic/+bug/2154494: Please support Docker for console container provide
15:24:24 <cid> https://bugs.launchpad.net/ironic/+bug/2154610: Permit RBAC decisions based on JSON key update
15:24:54 <JayF> I'll note that docker console container RFE is from our downstream, via StackHPC, for integration into kolla-ansible
15:25:02 * cid list of all newly triaged bugs are visible on the wiki page
15:25:07 <dtantsur> The schema one is interesting. Someone needs to double-check both the DMTF documents and what Ironic actually uses. May end up being a simple typo.
15:25:09 * cid https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_June_1.2C_2026
15:25:12 <JayF> So I know that was a loose end on containers, GR-OSS is getting it tied up
15:25:33 <TheJulia> dtantsur: I think its more dell went in one direction early on and the profile was contributed with that and not updated as things shifted
15:25:45 <TheJulia> dtantsur: but yeah, someone just needs to tak ethat one and roll with it
15:25:52 <TheJulia> JayF: cool
15:26:13 <dtantsur> any volunteers for the schema one? I don't want it to be me, but in the worst case I can occupy claude with it..
15:26:25 <TheJulia> I was about ask something similar to ^
15:26:45 <iurygregory> I can try to take a look in my free time
15:26:48 <TheJulia> .... Could Jacob be a good resource for this?
15:27:06 <TheJulia> It should be relatively straight forward, he has engaged with the DMTF so he is also aware of the profile importance
15:27:22 <iurygregory> I can check with him today
15:27:31 <dtantsur> iurygregory: free.. WHAT?? Oo
15:27:31 <TheJulia> iurygregory to take the action item to sync up with others. cool!
15:27:39 <TheJulia> ... wait, free time?!
15:27:43 <dtantsur> right?
15:27:45 <TheJulia> WUT!?
15:27:47 <iurygregory> hahaha
15:28:11 <dtantsur> iurygregory: thanks! just please make sure we don't drop it to the floor, it's quite bad if we declare all modern hardware as incompatible..
15:28:14 <iurygregory> when I have my priorities under review/or ci is running lol
15:28:24 <TheJulia> Thanks!
15:28:32 <iurygregory> its free time and I need to find something to work on lol
15:28:35 <TheJulia> So who shall be the next bug deputy?
15:28:49 <Mahnoor> I can do it
15:29:09 <TheJulia> Mahnoor, thanks!
15:29:24 <cid> tks
15:29:26 <TheJulia> Onward if there is nothing else for the Bug Deputy Updates?
15:29:39 <cid> Nothing else at this time :-)
15:29:54 <TheJulia> #topic RFE Review
15:30:03 <TheJulia> We have *FIVE* RFEs... eek
15:30:31 <cid> Yup
15:30:59 <TheJulia> I think the NGS one can be approved, it just makes sense and we have some switch vendors where it is basically required to do things properly.
15:32:06 <TheJulia> I don't knwo why there is another firmware RFE ixed in?!
15:32:42 <cid> Duplicate...
15:32:46 <TheJulia> i guess
15:32:54 <TheJulia> To me the rest of the RFE's make sense to me and seem logical
15:33:48 <cid> So we should add the rfe-approved tags.
15:33:57 <TheJulia> If there are no objections, yes
15:34:11 <dtantsur> It pains me that we're still dealing with JSON free-form fields.. but we definitely are, so it makes sense to protect them better
15:35:13 <dtantsur> Re https://bugs.launchpad.net/ironic/+bug/2154382, I'm not sure like relying on add_ports there, although I see the logic there..
15:36:09 <dtantsur> also i see that cid's patch does add a new option, so it's probably fine
15:36:38 <JayF> CID's patch is a upstream-port of a downstream fix GR team is running
15:36:45 <TheJulia> That was sort of what I was thinking as well
15:37:00 <cid> Yeah, we found out the add_ports approach was not necessarily the right one.
15:37:56 <dtantsur> I think I'm good with all of them
15:37:59 <cid> New gating flag, then remove the additonal pre port creation in the redfish interface completely.
15:38:14 <TheJulia> So onward?
15:38:35 <cid> ++
15:38:52 <TheJulia> #topic Open Discussion
15:39:01 <TheJulia> What items do we have to discuss?
15:40:58 <TheJulia> Bueller?
15:41:53 <TheJulia> Clearly no items today!
15:42:01 <TheJulia> #topic Who shall run the next meeting?
15:42:19 <JayF> put me in coach
15:42:33 <TheJulia> The agenda suggested iurygregory, should we let you two debate it out?
15:43:04 <JayF> I think that usually is saying who volunteered *last time*
15:43:06 <JayF> but imbw
15:43:33 <JayF> believe it or not, IDC who runs the meeting as long as it is run ;)
15:43:54 <TheJulia> same!
15:44:01 * TheJulia puts JayF in
15:44:23 <TheJulia> Anything else for this weekly meeting?!
15:45:53 <TheJulia> In that case, thanks everyone for attending!
15:46:14 <TheJulia> #endmeeting