15:00:08 <iurygregory> #startmeeting ironic
15:00:08 <opendevmeet> Meeting started Mon Feb  2 15:00:08 2026 UTC and is due to finish in 60 minutes.  The chair is iurygregory. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <opendevmeet> The meeting name has been set to 'ironic'
15:00:15 <alegacy> o/
15:00:16 <dtantsur> o/
15:00:20 <iurygregory> o/
15:00:31 <iurygregory> lets see if we have quorum =)
15:00:45 <TheJulia> o/
15:01:13 <TheJulia> We clearly need a fancy coffee machine for the IRC channel
15:01:26 <iurygregory> fair enough =D
15:03:36 <iurygregory> lets wait till 12:05 to see if more people will join
15:03:37 * TheJulia hears crickets this morning
15:03:45 * fungi is lurking as well
15:03:54 * TheJulia lurks to the coffee machine
15:04:02 <cid> o/
15:04:19 <iurygregory> ok, we have about 6 ppl since we have fungi :D hehe
15:04:45 <iurygregory> Welcome to our first meeting of Feb \o/ (January is over, finally)!
15:05:00 <iurygregory> #topic Announcements / Reminders
15:05:15 <iurygregory> #info Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash
15:05:19 <opendevreview> Jad Haj Yahya proposed openstack/ironic master: Update heartbeat on receiving inspection data  https://review.opendev.org/c/openstack/ironic/+/975397
15:06:29 <iurygregory> #info we are at the R-8 of Gazpacho Release Schedule in case you have something for oslo or openstackclient their FF is next week
15:07:39 <opendevreview> Jad Haj Yahya proposed openstack/ironic master: Update heartbeat on receiving inspection data  https://review.opendev.org/c/openstack/ironic/+/975397
15:07:47 <iurygregory> #info Ironic will be participating in the next PTG, we just created the etherpad https://etherpad.opendev.org/p/ironic-ptg-2026.2 and filled the form
15:08:07 <iurygregory> Anyone has something to add to announcements/reminders?
15:08:53 <dtantsur> A small FYI: I'll be out the next 2 weeks
15:08:57 <TheJulia> I will be out of country next week, so don't expect me to attend the weekly meeting next week or be available for reviews
15:09:30 <iurygregory> ack, tks!
15:09:44 <iurygregory> moving on
15:09:46 <iurygregory> #topic Working Group Updates
15:10:03 <iurygregory> #info Standalone networking
15:10:11 <iurygregory> #link https://etherpad.opendev.org/p/ironic-standalone-networking
15:10:13 <alegacy> Had a flurry of comments on my patches last week.
15:10:23 <alegacy> I've updated them accordingly
15:10:35 <alegacy> waiting for approvals to move them forward!
15:10:56 <TheJulia> I'll try to review them in the next couple of days, effectively my week is over around wednesday due to travel
15:11:19 <alegacy> k, thanks
15:11:47 <cid> I've been lacking a little in terms of reviews. I expect to do more this week, with particular focus on TBN and standalone networking.
15:12:00 <iurygregory> awesome, tks everyone!
15:12:16 <iurygregory> next one
15:12:28 <iurygregory> #info Async IO
15:12:31 <iurygregory> #link https://etherpad.opendev.org/p/ironic-asyncio
15:12:46 <TheJulia> I didn't have time to review that last week, been heads down on vxlan
15:12:51 <iurygregory> Anything you would like to share dtantsur ?
15:13:14 <iurygregory> We have a spec up for review for it
15:13:17 <iurygregory> #link https://review.opendev.org/c/openstack/ironic-specs/+/972754
15:15:22 * TheJulia is guessing unstable connection
15:15:27 <opendevreview> Julia Kreger proposed openstack/networking-baremetal master: l2vni baremetal mech driver  https://review.opendev.org/c/openstack/networking-baremetal/+/973889
15:15:27 <opendevreview> Julia Kreger proposed openstack/networking-baremetal master: Trunk port reconciliation for L2VNI attachments  https://review.opendev.org/c/openstack/networking-baremetal/+/974619
15:15:42 <iurygregory> please review if you have interest in the spec :D
15:15:44 <iurygregory> moving on
15:15:57 <iurygregory> #info VXLAN Networking
15:15:59 <iurygregory> #link https://etherpad.opendev.org/p/ironic-vxlan
15:16:16 <iurygregory> any updates for this wg?
15:16:36 <dtantsur> yeah, sorry, the status for async/await is like Iury said: please review the spec
15:17:16 <TheJulia> I was heads down on this last week. The tl;dr is given where we are at in the cycle, my hope is to begin landing some of the patches since we're approaching a "good" state. It might not be perfect, but that is the enemy of good. Reviews for networking-baremetal would be appreciated. I'll be revisiting networking-generic-switch patches this week, if folks who care about cisco hardware and networks could chime in, that
15:17:16 <TheJulia> would also be helpful.
15:18:14 <TheJulia> Once we have building blocks merged, I'll propose some docs against ironic to try and bring clarity to the topic from the operator point of view
15:18:35 <TheJulia> Any vxlan-ey questions?
15:19:53 * TheJulia takes silence as a no and lets iurygregory resume
15:19:59 <iurygregory> ack
15:20:17 <iurygregory> we don't have discussion topics so I will skip
15:20:29 <iurygregory> #topic Bug Deputy Updates
15:20:38 <iurygregory> #info we got 4 new bugs
15:20:48 <iurygregory> #link https://bugs.launchpad.net/sushy-tools/+bug/2137387
15:20:59 <cid> A little quiet. There were 3 newly filed bugs
15:21:20 <cid> And the dnsmaq one got new activity
15:21:26 <cid> https://bugs.launchpad.net/ironic/+bug/2026757
15:22:33 <iurygregory> tks cid !
15:22:57 <kubajj> o/
15:22:58 <iurygregory> https://bugs.launchpad.net/ironic/+bug/2139557 is triaged
15:23:31 <iurygregory> but doesn't have a person assigned, so in case someone is interested feel free to pick it up
15:23:59 <iurygregory> it's related to PySNMP, which I recall we had some problems with the newer version for sure
15:24:13 <cid> Yeah. It looks sane to me.
15:24:24 <iurygregory> not sure if ppl using SNMP will try to fix or not...
15:24:29 <cid> Nobody is assigned because the fix is not in progress yet. At least to my knowledge
15:24:44 <iurygregory> yeah
15:24:52 <iurygregory> Who is the next bug deputy?
15:25:14 <cid> I would.
15:25:55 <iurygregory> I can take next week
15:26:08 <cid> okay. tks!
15:26:19 <iurygregory> #info cid to be the bug deputy this week and iurygregory next week
15:26:36 <iurygregory> we don't have RFE to review, skipping
15:26:42 <iurygregory> #topic Open discussion
15:26:54 <iurygregory> we have one topic on it, not sure who added
15:27:02 <fungi> following up on last week's "Bridging the Gap Flamingo Cycle Retrospective" topic...
15:27:11 <fungi> this effort started with representatives from member organizations sharing frustrations with, primarily, their employees' experiences trying to contribute patches in various openstack projects
15:27:18 <fungi> investigating these reports on a case-by-case basis, foundation staff concluded most misunderstandings were due to mismatched expectations arising from incomplete communication or silence (and not necessarily on the part of the maintainers)
15:27:27 <fungi> what we've observed from successful exchanges in some projects is that increasing communication effectiveness ultimately leads to improved efficiency and time savings for all parties involved; some examples include:
15:27:33 <fungi> documenting review priorities and the prioritization process, as well as publicizing it more (e.g. with pointers in review comments), so that change owners know the priority for their own work and how to get involved in that decision
15:27:39 <fungi> proactively communicating reviewer availability, changes in availability, and explicit handoff to other reviewers, so that change owners know how long they might be waiting (and encouraging them to communicate their own availability)
15:27:48 <fungi> overall clearer communications with change owners, for example avoiding heavy reliance on acronyms and team-specific jargon, since english is not the primary language for a majority of our community and their familiarity with it varies
15:27:55 <fungi> to this end, i and other community managers on the foundation staff are working on putting together some materials that we hope teams will find useful, and will collaborate with us to help improve and expand further
15:28:02 <fungi> one thing we want to try is cut-and-paste review response templates for common situations; the vulnerability management team has used similar techniques for bug triage and assembling advisories, and they've found it saves a lot of time
15:28:10 <fungi> another is assembling contributor and reviewer checklists to help avoid common pitfalls and anti-patterns, based on all of the earlier focus group feedback and brainstorming sessions we held with the community in 2024
15:28:17 <fungi> something else we want to try is collaborating to produce case studies with companies who have been investing in project maintenance work and whose employees have a track record of successful contribution patterns
15:28:24 <fungi> we also plan to continue identifying additional tactics and strategies that teams have positive experiences with, to see if there's a way they can be generalized for adoption by other teams facing similar challenges
15:28:32 <fungi> if anybody has follow-up thoughts or questions on any of the above, as well as for the survey and metrics analysis from last week now that you've had time to mull it over, i'm happy to answer questions and entertain feedback here
15:28:41 <fungi> (or here in irc after the meeting, or on the openstack-discuss mailing list, or even directly/in private for that matter)
15:29:24 * iurygregory reading...
15:31:04 <dtantsur> I have a nagging suspicious that overloaded reviewers are a big part of the problem, but we cannot really solve that (esp. in a contributor-friendly way)
15:32:20 <fungi> it is, but the underlying satisfaction problem is less the lack of reviewer availability and more that casual contributors don't know there's a shortage, so in a lot of projects (not necessarily ironic) they never get a response on their uploads
15:33:17 <fungi> in last cycle's brainstorming discussions, the nova team committed to scaling back their spec approvals, for example, and being clearer about how much they'd realistically be able to review in the cycle
15:33:39 <TheJulia> I mean, we see that with other projects where we also know to nag them and we know the disconnect. I suspect its much more a "there is too many things" and not enough reviewers problem (mix in burnout of course)
15:33:54 <fungi> acknowledging that approving specs that they don't have time to review the changes implementing is setting incorrect expectations for the spec proposers
15:35:38 <dtantsur> I have mixed feelings about throttling contributions through specs, to be honest
15:35:42 <TheJulia> I think setting/adjusting expectations is critical
15:35:45 <TheJulia> I think its bonkers
15:36:04 <fungi> yeah, communicating what changes are unlikely to get reviewed and why sets clearer expectations
15:36:06 <TheJulia> Specs were intended to slow the process to a crawl
15:36:24 <TheJulia> cycle time/engagement are going to always vary though
15:37:36 <TheJulia> Bottom line, its a dialog, teams need to not just blindly promise to review/engage and not follow-up. Overloading wise, its easy, we're all well intending
15:37:38 <fungi> in a lot of the cases we investigated, contributors assumed things that weren't correct, in the absence of communication from maintainers, and this is what ultimately led to dissatisfaction with the process
15:38:15 <fungi> also things like not knowing who to reach out to and how to find out whether their chjange was likely to get reviewed
15:38:32 <dtantsur> We need a queueing system with numbers :D pick a number for your PR, wait for it to show up on the screen :D
15:38:43 <TheJulia> heh
15:39:18 <dtantsur> Seriously though, it's very good food for thought, thank you fungi!
15:39:35 <fungi> one classic case was someone trying to get a change reviewed for nova, had some questions, finally figured out to ask in irc, but the one time they did so on december 26 when there was basically nobody around
15:39:53 <iurygregory> ohhhh
15:39:55 <iurygregory> =(
15:40:07 <fungi> (maybe that should have been obvious to them, but they were from part of the world where that's not holiday season)
15:40:12 <dtantsur> I wonder if office hours could help
15:40:25 <dtantsur> with a schedule published somewhere, obviously, including any major shutdowns
15:40:38 <iurygregory> and mentioning in the review could help also
15:40:41 <TheJulia> But would it be findable?
15:40:48 <TheJulia> Would it be easy to discover/become aware of
15:40:51 <iurygregory> sometimes ppl are shy
15:41:04 <dtantsur> I recall at some point any new contributors would get a special message on their first patch?
15:41:17 <iurygregory> on the first they do
15:41:35 <TheJulia> Which is *often* against the test project
15:41:41 <iurygregory> but maybe the problem happened on the second etc
15:41:44 <dtantsur> Well, if we can customize these per project, or even if we cannot, that's where to mention the office hours and IRC
15:41:48 <iurygregory> yeah, normally is the sandbox
15:42:16 <dtantsur> I guess it could be technically possible to show the message both on the 1st sandbox commit and on the 1st real one
15:42:23 <TheJulia> I mean, I kind of pushed the idea of a ai driven initial response, but maybe a "hey, you are not a regular, weekly meeting is at this time" comment might not be a bad idea
15:42:28 <iurygregory> maybe Zuul could add a message to the patch? in case CI failed (hey, in case you are unsure about the failure, reach out to the tem on this channel on irc)
15:42:51 <iurygregory> not sure if would help, just a random idea =)
15:43:03 <dtantsur> that is separately a good idea
15:43:44 <fungi> worth noting, this isn't so much "new" contributors we were hearing from, but (mostly operator) contributors at openinfra foundation member companies who had limited time per week to devote to their patches
15:43:50 <opendevreview> Merged openstack/ironic master: Allow node lookup for in-band servicing  https://review.opendev.org/c/openstack/ironic/+/971459
15:44:18 <TheJulia> So its a class of folks who may only have an hour or two a month ?
15:44:30 <TheJulia> which may not even align with anything the team has available?
15:44:37 <fungi> or maybe more, but don't know how to use that time effectively/efficiently to engage with the maintainers
15:45:36 <fungi> basically in lots of these cases, upstreaming patches is not their primary job, it's just something they get tasked with in hopes of not having to carry patches for bug fixes or small features forever
15:46:12 <TheJulia> its a convenience thing for them, they will carry that debt not recognizing it becomes a crushing debt
15:46:52 <fungi> and some of them might be untapped candidates for spending more time upstream and helping with maintenance, but the experience they have struggling to get changes in front of the right people leaves a sour taste in their mouths
15:47:45 <TheJulia> Has anyone done an analysis of these sorts of changes? Are they fundimentally missing key required aspects?
15:48:16 <TheJulia> or is it just entirely silence and they become frustrated and don't bother to respond/revisit ?
15:48:32 <fungi> yes, the foundation staff dug into a bunch of the ones that member company representatives forwarded to us, and tried to categorize them and find common themes
15:48:48 <opendevreview> Dmitry Tantsur proposed openstack/ironic master: Allow aborting deployments in "wait call-back" state  https://review.opendev.org/c/openstack/ironic/+/973279
15:49:17 <fungi> in basically all cases, as i said, it was ultimately a communication breakdown, and i would say in most cases on the part of the people trying to contribute the change
15:50:09 <fungi> reviewers would leave questions or ask for revisions, the contirbutors would disappear for too long and then not be able to figure out how to address those comments or not be able to get reviewer attention again once they did
15:50:35 <fungi> they would ask for help with their changes in the wrong places, at the wrong times, in the wrong ways
15:50:57 <iurygregory> =(
15:51:17 <fungi> but terse communication or missing follow-up from maintainers helped stoke their misunderstandings
15:52:12 <iurygregory> not sure if a bot could help? (no updates in 2 week, bot adds a comment with some custom message?)
15:52:13 <TheJulia> That likely goes right back to overloaded reviewers
15:52:17 <fungi> that was the initial research which led to us putting together this whole effort, essentially trying to find ways to fix the communicaiton gap between these operators and other employees at companies in our ecosystem and the upstream maintainers
15:53:16 <TheJulia> iurygregory: I would be good with that, as long as we don't do anything bonkers like auto-abandon after some number of weeks of no response
15:53:17 <dtantsur> If the foundation of the infra team wants to invest into something, a review dashboard could be helpful
15:53:27 <TheJulia> We see bug fixes from operators die on the vine like that elsewhere :\
15:53:28 <dtantsur> We tried maintaining our own, but it's always a bit of a striggle
15:53:31 <fungi> and yheah, i agree, we concluded that one of the best things that could be done to help is to find ways to relieve some of the maintainer/reviewer burden. we can't magically find more people, but maybe we can help the ones we have find ways to make their tasks easier
15:53:53 <dtantsur> Such a dashboard could, for instance, highlight patches without feedback for 2 weeks or whatever
15:54:06 <dtantsur> prioritizing those without any -1
15:54:17 <iurygregory> TheJulia, agree
15:54:50 <fungi> i was talking with the manila team last week about maybe putting together a review intake bot that can leave comments with initial pointers to team-specific contributor docs and review priorities
15:55:17 <fungi> basically help to set expectations at the time the change's first revision is uploaded
15:55:31 <fungi> and make sure these casual contributors know where to find the right resources and information
15:56:44 <janders> before we wrap, can I bring up a quick topic?
15:56:53 <janders> (sorry for missing most of the meeting)
15:57:00 <fungi> yeah, sorry, i didn't want to eat up the remainder of the meeting
15:57:08 <janders> no worries, this is important!
15:57:16 <iurygregory> fungi, totally fine, don't worry
15:57:24 <TheJulia> janders: whats up?
15:57:24 <janders> I am trying towards being a reviewer, those ideas sound very helpful
15:57:32 <janders> TheJulia monitoring
15:57:40 <janders> 1) https://review.opendev.org/c/openstack/ironic/+/974985 - I would appreciate reviews on doco
15:57:40 <iurygregory> I think we have things we can try to improve ++
15:57:43 <janders> when you folks have time
15:57:46 * TheJulia makes beep boop whirling sounds
15:58:06 <janders> and 2) I wanted to ask around to see if anyone in the community would be keen to test the monitoring feature on mid-scale real-hardware
15:58:15 <janders> so in other words - calling for testers!
15:58:27 <janders> would be good to see how this code handles real failures at a bit more scale
15:59:01 <janders> I think kubajj may be looking at this but if anyone else is interested in trying too, please let me know
15:59:18 <janders> would be great to get some real world feedback before advertising this feature a bit more
15:59:24 <janders> thanks! :)
15:59:28 <TheJulia> Given how risk adverse operators with existing infra tend to be, we might not see that until after the end of cycle, which is fine, it happens.
15:59:45 <TheJulia> That whole, their primary thing is not testing, its operating the metal
15:59:49 <kubajj> janders: I will have a look into it once I get rid of inspector 😉
15:59:58 <janders> thank you!
16:00:03 <janders> that's all from me
16:00:55 <TheJulia> So one of the things with the vxlan work is that I had to kind of realize "we're not going to have perfect testing of it this cycle", so on some level we just need to be prepared to accept reports and backport fixes
16:01:26 <iurygregory> #chair TheJulia
16:01:26 <opendevmeet> Current chairs: TheJulia iurygregory
16:01:31 <TheJulia> Is there anything else? Or can we close the meeting up?
16:03:16 * TheJulia hears crickets
16:03:20 <TheJulia> Thanks everyone!
16:03:25 <janders> o/
16:03:32 <TheJulia> #endmeeting