15:00:19 #startmeeting Ironic 15:00:19 Meeting started Mon Mar 2 15:00:19 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:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 The meeting name has been set to 'ironic' 15:00:36 Welcome to the Ironic meeting everyone! I'm going to refresh the coffee and wait for quorum :) 15:00:50 o/ 15:00:58 o/ 15:01:37 o/ 15:01:47 o/ 15:01:51 * TheJulia presses the coffee machine button 15:02:07 o/ 15:02:15 okay caff has begun to flow :) 15:02:24 Riccardo Pittau proposed openstack/ironic-python-agent master: [DNM] TEST CI https://review.opendev.org/c/openstack/ironic-python-agent/+/978486 15:02:25 #topic Announcements/Reminders 15:02:42 Please review patches hashtagged "ironic-week-prio" and hashtag your ready to review patches 15:02:50 #link https://tinyurl.com/ironic-weekly-prio-dash 15:03:15 The release is LOOMING. It's R-4. Cycle highlights are due this week. 15:03:22 #link https://releases.openstack.org/gazpacho/schedule.html 15:03:39 #topic Working Group Updates 15:03:48 Standalone networking is first up. alegacy_? 15:04:14 Only outstanding change is the bifrost patch: https://review.opendev.org/c/openstack/bifrost/+/962394 15:04:21 o/ 15:04:28 other than that, I owe a couple of minor follow-ups which I plan to get to in the next week or so 15:04:37 alegacy_: it's failing CI so I removed ironic-week-prio on it. 15:05:05 ok, i'll check. thanks. 15:05:20 Congrats on a successful project \o/ 15:05:26 What about AsyncIO? Any updates there? 15:05:49 I believe the spec has been pushed and needs some feedback from everyone else. 15:06:06 Yep, collecting more feedback 15:06:10 I think a review jam to review/discuss would be good 15:06:14 Otherwise, I'm really short on time to code anything... :( 15:06:22 https://review.opendev.org/c/openstack/ironic-specs/+/972754 15:06:36 Who wants to own scheduling said jam? 15:06:41 [touches nose[ 15:06:42 Once we cut 2026.1 from master of ironic, I'm gonna try and bring sushy into the ironic code base. 15:06:54 I can own scheduling it 15:07:03 #action TheJulia to coordinate review jam for asyncio spec 15:07:06 folks, when would we like to meet, tomorrow? Wednesday? 15:07:18 Friday? 15:07:22 Last but not least, VXLAN Networking ... is this another story of celebration time? 15:07:51 TheJulia: tomorrow after 11am (or at 10am PST if we wanna roll it into GR-OSS review jam downstream) 15:07:51 Biggest item for VXLAN networking are the docs... https://review.opendev.org/c/openstack/ironic/+/977102 Jay and I have +2'd it but he's got valid concerns in comments. 15:08:09 I suspect we'll shake out those items as follow on changes however but I wanted to let TheJulia weigh in. 15:08:10 TheJulia: or thursday with a couple of 30 minute chunks in the way, or friday after noon 15:08:14 The whole kit and caboodle of vxlan stuffs, except for a docs patch or two has landed. Direction is likely to shift to testing/sharp edge removal next. 15:08:26 I'll call it mostly done \o/ 15:08:33 TheJulia, alegacy_: I'm holding the bifrost release until end of this week for OCI registry support and standalone networking 15:08:36 Is there anyone specifically doing cycle highlights yet? 15:08:40 If not; I'll take the action 15:08:53 I have not, I'm trying to prepare a blog post for ironicbaremetal.org 15:09:03 sounds like a good segmentation of work 15:09:05 I think we'll want to do *several* posts 15:09:06 we can each see if we miss something 15:09:13 #action JayF to draft cycle highlights 15:09:23 Moving on to 15:09:27 #topic Discussion Topics 15:09:32 two are listed here; first is PTG 15:09:39 #link https://etherpad.opendev.org/p/ironic-ptg-2026.2 15:09:55 I-personally haven't taken the time I should on this yet; I'll dig into it some today 15:10:28 We're still in early idea phase, that is sure based upon the state of the etherpad 15:10:56 I suggest the team make a special effort to populate PTG etherpad further this week so maybe we can have a bigger chat about it next week-ish? 15:11:09 I agree 15:11:32 Second item for discussion is https://review.opendev.org/c/openstack/ironic/+/973279/4/ironic/conductor/deployments.py 15:11:40 some weird behavior came to light in this change: 15:11:52 if we ABORT a state that's on the last step, that last step can't be aborted ... we just let it finish 15:12:07 this is existing behavior in CLEANING/SERVICING and was proposed for DEPLOYING there when I got confused and raised a flag 15:12:33 my preference, after talking with dtantsur is that we land his change with consistent behavior, then make the behavior abort in all cases (or at least configurable) 15:12:54 it seems very operator-expectation-breaking that ABORT on a DEPLOYWAIT node could end in ACTIVE 15:13:09 yeah, it may be a nightmare to program the state machine for a consumer 15:13:14 I'm onboard with that plan. It feels like a bit of a hyper-optimizaiton, but also likley best if we take the most recently requested action 15:13:23 as it obviously superceeds the original request 15:13:39 I'm thinking when this matters, it really matters -- like abuse preventation trying to block builds in flight 15:13:42 But, we don't have to iterate to get it right on that patch, it can be a follow-up since it really is a bug fix 15:13:52 exactly, it's actually better if we make it consistently gross 15:13:54 then fix it 15:14:00 than if we make it inconsistent and leave a loose thread 15:14:10 Allain Legacy proposed openstack/bifrost master: Add support for standalone ironic networking https://review.opendev.org/c/openstack/bifrost/+/962394 15:14:15 at least then it's a full consistent story 15:14:15 Or, even if we document it and then fix it later 15:14:22 I'm just wanting to make sure we don't forget it 15:14:33 yeah, my comment on the review was to JFDI fix it or bug it 15:14:36 I think a bug is the right route 15:15:03 Any other thoughts/input on this before moving on? 15:15:07 a bug gives us a basis for fixing in backport as well which we can weigh once we have a patch 15:16:34 moving on 15:16:37 I can file a bug or do you want to JayF? 15:16:45 * dtantsur would appreciate a W+1 now 15:16:48 if you wanna do it r/n I won't complain 15:16:52 and if you link it I can approve 15:16:55 ack 15:16:56 #topic Bug Deputy Updates 15:17:01 Who was bug deputy? 15:17:16 I was bug deputy 15:17:33 I found two newly reported bugs and two possible RFEs 15:17:39 Link on the wiki page 15:18:00 First RFE is already somewhat discussed 15:18:01 https://bugs.launchpad.net/networking-generic-switch/+bug/2142771 - Cache and reuse ssh connections 15:18:35 seems a little like an obvious one, but I'd warn the implementor about sessino limits 15:18:37 I'm good with the idea, I've not sat down and thought through the fine details there 15:18:46 there are some switches which those peristent connections might choke out other connections to the switch 15:18:53 e.g. if you can only have one or two incoming ssh sesh at a time 15:18:59 JayF: they are already aware and have set it for a per-switch knob 15:19:37 I am +1 to approving 2142271 15:19:45 Same 15:19:56 I think the value benefit makes a nice and strong case 15:19:57 Cool, cool. 15:20:00 The second is only an RFE if we determine it to be 15:20:09 https://bugs.launchpad.net/networking-generic-switch/+bug/2142786 15:20:21 The question is if we should honor `ngs_max_connections` limit with a file locks fallback when `backend_url` is not provided. 15:20:31 So this is almost similar to the NGS agent idea. 15:22:08 Yeah, I'm honestly kind of split on that one. I think its the right move to do it (i.e. as proposed in the lp item), but the basic challenge is we're talking older style OSes versus more modern multi-user switch OSes 15:22:19 Its a super weird line for us to walk as well 15:22:45 because if we artificially force all OSes into the oldest OS pattern, we actually force sub-optimal behavior 15:22:56 so... its a weird one I guess. 15:23:07 sounds like as much a docs bug as a bug-bug 15:23:18 since fixing it would maybe add a decoder ring for folks to figure out to "fix" performance 15:23:26 Yeah, kind of is. Requires some context and "know thy network gear" 15:23:46 Yeah! 15:23:47 FWIW, I already pushed a patch over the weekend to just log a warning, now merged (thanks to TheJulia, cardoe) which I believe is a good enough immediate addressing of the original report. 15:24:33 That's all the updates I have. Also happy to take up the role for next week unless someone else volunteers 15:24:47 Yeah, I concur, I think doing anything more than just adding clarifying documentation does become a bit problematic. But shermanm did say most of the switches are dell OS9 and OS10, OS9 being the more problematic ones. 15:25:31 Does anyone want to ensure there's not a cid-shaped rut in our Bug Deputy station? 15:25:35 :D 15:25:49 I'll take it on this week 15:25:58 #action TheJulia as bug deputy 15:26:06 Next topic is RFE review, which we did inline. Skipping it. 15:26:10 #topic Open Discussion 15:26:17 Speaking of bugs, https://bugs.launchpad.net/ironic/+bug/2143060 is the requested bug about aborting actions 15:26:23 No premade agenda items here; anyone have anything for open discussion? 15:26:42 I was assuming open discussion would be a giant party? 15:26:49 party \o/ 15:27:11 Seriously everyone, we've made some huge strives this cycle. Three major networking pushes all at once 15:27:11 Spring is here \o/ (except for those on the bottom half of the Earth - sorry folks!) 15:27:42 spring++ 15:27:42 Who wants to chair the next meeting on March 9? 15:28:00 I'll do it again. I probably owe a few :D 15:28:06 #action JayF to chair March 9 meeting 15:28:12 heh 15:28:20 That's going to bring the meeting to a close. Please stay for an afterparty, apparently. 15:28:21 #endmeeting