Monday, 2026-01-26

TheJuliastevebaker[m]: super temping we just set it as a job default, or at least make it a default eventually00:15
stevebaker[m]TheJulia: yeah, I figured starting with one job for a start is appropriate though01:07
TheJuliastevebaker[m]: definitely03:01
rpittaugood morning ironic! o/07:57
rpittauthanks kubajj :)07:57
kubajjgood morning rpittau, and ironic! o/07:58
jandersgood morning Ironic o/08:16
abongalegood morning ironic o/08:42
opendevreviewJakub Jelinek proposed openstack/ironic master: Populate the conductor group field from config  https://review.opendev.org/c/openstack/ironic/+/97469410:30
kubajj^ since this was a TODO, does it need a release note?10:30
rpittaukubajj: that's subtle, IMHO since the feature has been released already, we need a release note10:49
kubajjrpittau: will do then10:54
opendevreviewJakub Jelinek proposed openstack/ironic master: Populate the conductor group field from config  https://review.opendev.org/c/openstack/ironic/+/97469410:57
clifgood morning o/14:04
opendevreviewRiccardo Pittau proposed openstack/ironic master: Migrate database charset from UTF8MB3 to UTF8MB4  https://review.opendev.org/c/openstack/ironic/+/97443014:12
cardoemorning ironic... if some folks have some time to go through https://review.opendev.org/q/hashtag:ironic-week-prio+status:open that list should be in a good state to get feedback from folks14:40
TheJuliaGood morning everyone14:49
TheJuliaHopefully everyone is brewinc foffee14:49
fungiit's already in my belly14:49
TheJuliaerr, brewing14:51
TheJuliaso, then, more?!14:51
* TheJulia updates the agenda and the vxlan networking etherpad14:52
mumesan[m]I just had lunch so uh no tea till the evening 14:52
mumesan[m]Also, hello ironic o/14:54
JayFI'll have an item for open discussion. JFYI14:57
* dtantsur is lurking from the mobile internet15:00
TheJuliaclif: i'm uncertian about https://review.opendev.org/c/openstack/ironic/+/972495, please see my comment, we can discuss after the meeting15:00
TheJulia#startmeeting ironic15:00
opendevmeetMeeting started Mon Jan 26 15:00:55 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'ironic'15:00
janderso/15:00
alegacyo/15:00
kubajjo/15:01
TheJuliaGreetings ladies, gentlemen, IRC bots!15:01
clifo/15:01
fungialoha15:01
TheJuliaWelcome to this week's Ironic Meeting! Where we plot to take over the world^W^Wall baremetal provisioning!15:01
TheJuliaThis week's agenda can be found on the wiki!15:01
dtantsuro/15:01
TheJulia#link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_January_26.2C_202515:02
JayFo/15:02
TheJuliaEveryone have coffee?15:02
cid'o/15:03
TheJuliacat wrangling too at the moment15:04
TheJulia#topic Announcements / Reminders15:04
TheJuliaA standing reminder to review our ironic-week-prio dashboard, we presently have 26 items, lets get it down to 20!15:05
TheJulia#link https://tinyurl.com/ironic-weekly-prio-dash15:05
dtantsurOnce I'm on unlimited internet, will catch up with reviews15:05
TheJuliaWe are also at week R-9 in the 2026.1 Gazpacho Release Schedule15:05
TheJuliaDoes anyone have anything else to announce or remind us of?15:05
TheJuliaI guess not, and now that cat wrangling has been completed, we can proceed!15:07
TheJuliaTime for working group updates!15:08
TheJulia#topic Working Group Updates15:08
TheJuliaFirst up, standalone netwokring15:08
TheJulianetworking15:08
TheJulia#link https://etherpad.opendev.org/p/ironic-standalone-networking15:08
TheJuliaalegacy: Any update for the group?15:08
alegacystill in a holding pattern waiting for reviews.  This one is the next one up:  https://review.opendev.org/c/openstack/ironic/+/96647015:08
alegacydtantsur: had left some comments... so I pushed up a new version15:09
alegacyhoping to close it off soon.15:09
TheJuliaJayF: sounds like you feel a review jam would help move these items forth?15:09
TheJuliaIf that is the case, is there a day which would work well to have a 1 hour call to walk through the changes?15:10
JayFI'm mostly clear meetings today and tomorrow15:10
TheJuliaI'm unfrotunately not clear tomorrow, I won't be around tomorrow15:11
TheJuliaWould in a couple of hours work?15:11
dtantsurMe neither, nor today15:11
TheJuliahmm15:11
TheJuliawell, I can make time today15:12
alegacyI'm open today after 1pm EST15:12
JayFYeah, I mean I don't have so many meetings that I can't get something figured out quickly. If we need to. Today works. Tomorrow works. Later this week works but just a little more spotty15:12
alegacysame tomorrow, but could maybe move some things tomorrow morning.15:12
TheJuliaI have 10-11:30 pacific open today before I start sprint planning15:13
alegacysounds like dtantsur is unavailable both days though15:13
TheJuliayeah15:13
JayFI can do 10 Pacific15:13
TheJulia2 is better than none15:14
dtantsurI'll take a look at my own pace, videos will eat too much traffic15:14
JayFI suspect Dimitry and I will be reviewing for different sort of stuff15:14
TheJuliadtantsur: fair enough15:14
TheJuliaYeah, we always do in a sense15:14
TheJuliaNext up, async IO15:15
TheJuliadtantsur, anything for us15:15
TheJulia#link https://etherpad.opendev.org/p/ironic-asyncio15:15
opendevreviewDmitry Tantsur proposed openstack/ironic-specs master: Asynchronous sensor data collection  https://review.opendev.org/c/openstack/ironic-specs/+/97275415:15
dtantsurHere it goes ^^^ :)15:15
TheJuliaOh my15:15
dtantsur(yes, I timed uploading the spec with the section of the meeting)15:15
TheJuliaheh15:15
TheJuliaOkay, are we good to proceed then?15:16
mumesan[m]lol15:16
dtantsurThat's all I have at least15:16
dtantsurFurther work will need at least a rough agreement15:16
opendevreviewOpenStack Release Bot proposed openstack/ironic-python-agent bugfix/11.4: Update .gitreview for bugfix/11.4  https://review.opendev.org/c/openstack/ironic-python-agent/+/97473915:16
TheJuliaOkay then!15:16
TheJuliaLast but not least for the working groups is vlxan networking!15:16
TheJulia#link https://etherpad.opendev.org/p/ironic-vxlan15:16
TheJuliaSo the tl;dr is we have a working mech driver in networking-baremetal to facilitate the localnet binding in OVN and the creation of segments for consumption.15:17
TheJuliaThe spec also has 2x+2 as of the last time I looked, so consider this the last call to review before the approval button gets pushed15:18
TheJuliaThere are a few other patches needed, and mechanics, but things are looking pretty good.15:19
TheJuliaAny questions?15:19
TheJuliaSince we have no discussion topics (unless someone just put one in after the meeitng started), we can proceed to Bug Deputy Updates15:20
* TheJulia takes silence as a no15:21
TheJulia#topic Bug Deputy Updates15:21
fungiah, i guess i put mine in open discussion, not realizing i should have used the discussion topics section, sorry15:22
* fungi will wait15:22
TheJuliaNo worries15:22
TheJuliaSo, we had no new bugs last week, and one RFE filed regarding typing all of the code. This has come up before and some discussion might be needed. I'm not opposed to doing so, I think big giant patches at this point are just the wrong path to take15:23
TheJuliain other words, the responsible and lightweight thing is to just slowly move to the convention and begin to merge smaller changes as time goes on.15:23
TheJuliaThoughts?15:23
JayFThis is what my open discussion items about15:23
TheJuliaack, okay then!15:24
cidSame, same. Totally missed to add something on the discussion topics.15:24
JayFWe have an MLH fellow starting very soon, and we'd like to point them at doing type annotations. CID has written up a document on how to do it using the lessons learned from our failed attempt at IPA15:24
TheJuliaIf there is nothing else regarding bugs, lets determine who will be the next bug deputy!15:24
JayFWith the primary difference being a focus on doing it a single module at a time instead of trying to do some sort of flag Day15:24
JayFAnd hopefully to get core buy into the process so that CID and I can use our core access to ensure that the patches don't get stale and need rebasing every 3 days15:24
TheJuliaJayF: honestly, I'd be cool with "oh, I chanced this class or just this method. at this point15:24
TheJuliaYeah, thats where things go sideways15:25
TheJuliaand always, really have15:25
JayFYeah, the main reason I'm bringing it up for open discussion is more or less saying unless there is loud objection. CID and I will be pretty fast approving these patches to reduce disruption15:25
TheJuliaEveryone who has pushed that in the past have attempted to do giant swaths at a time15:25
JayFYeah, the approach here will be a module at a time and trying to coordinate so that the patches do not remain outstanding very long at all15:25
cardoeWell I've been typing classes as I touch them but I get -1's on that so I've stopped doing that.15:25
TheJuliaAnyhow, lets proceed to Open Discussion then :)15:26
JayFNcid and I will have an awareness of where code is moving around in other patches as to not foist the rebase onto other people15:26
JayF**and cid15:26
opendevreviewOpenStack Release Bot proposed openstack/ironic bugfix/34.0: Update .gitreview for bugfix/34.0  https://review.opendev.org/c/openstack/ironic/+/97474115:26
cardoeIf we could agree to that we could enable some checks with an extremely low threshold... how do ya eat an elephant? 1 bite at a time.15:26
TheJulia#topic Open Discussion15:26
TheJuliaProceed!15:26
JayFcardoe: Have a look at CID's proposed documentation change. That's the guide we're working on to point our mlh fellow at15:26
cidcardoe, feedback very much welcome. https://review.opendev.org/c/openstack/ironic/+/97422415:27
fungii had "Bridging the Gap Flamingo Cycle Retrospective" for discussion, if this is a good time15:27
cidTheJulia, I will be bug deputy for next week. tks!15:27
TheJuliacid: thanks!15:27
JayFFor my item, I will also email the list but I'm taking this as least a mild acceptance of a plan for us to rapidly land the type check PRs once we get a pattern established15:27
TheJuliafungi: isen't it a bit late as flamingo should have really been dsicussed back in october :\15:28
TheJuliawe're practically though the next cycle now :\15:28
TheJuliaso any room for improvement is kind of.. gone.15:28
fungiit takes time to gather survey responses after the release, and analyze them15:28
TheJuliaStill, its a bit late15:28
fungiokay, no worries15:29
TheJuliaBut, what do you have for us?15:29
fungioh, sure i can still cover it if you like15:29
cidSure15:29
fungiildiko posted openstack-wide 2025.2 (flamingo) cycle retrospective contributor/maintainer survey results and metrics to openstack-discuss last month:15:29
fungi#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/XZZYFHMUCB3IZU5AXM366AY7WJXQMTBX/ Bridging the Gap Flamingo Cycle Retrospective Survey Results15:29
fungi#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/FD4JALJN7OB2YNBUVWCPZZ6YNJMIL2JT/ Bridging the Gap Flamingo Cycle Retrospective Metrics Analysis15:29
fungii and the other community managers on the openinfra foundation staff have also been digging into team-specific details and i'm doing a round of outreach similar to last cycle, to go over how things may have changed15:29
fungiironic had more survey responses than most other teams (6 contributors and 1 maintainer), more would still be better of course, but this is great!15:29
fungi4 of the contributors self-identified as established while the other 2 considered themselves new new to ironic, all contributing to 2 or more other open source projects15:29
fungiaverage ratings on the contributor survey questions were positive overall, with helpful contributor documentation coming in highest at 4.33 out of 5, yet discoverability of contributor docs received the lowest at 3.1615:29
fungicontributors noted liking participating in the project overall, and felt that its proximity to the hardware layer presented unique challenges; only a third of respondents noted struggling to get changes reviewed or tests to pass15:30
TheJuliaThe reality is just that if we're going to consider/take/act on feedback, its best to do so when the iron is hot *and* we are able to drive that into current plans/actions15:30
fungithe new survey questions about priorities were insightful: a majority of contributors (4/6) said they follow development and prioritization through launchpad blueprints, surprisingly, since the maintainer did not mention blueprints at all15:30
fungia third of the contributors also said that they're unsure how the ironic team is tracking development and review priorities, which could point to a need for better communication on that front15:30
fungithe rankings on the maintainer survey response were similarly high, with comprehensiveness of contributor docs receiving a perfect 5 out of 5 (though they admitted to having not referred to that documentation at all during the cycle)15:30
fungithe lowest ranking on the maintainer survey response was a 3 for ease of identifying test result failures, and the respondent also indicated trouble getting other maintainers to review their work15:30
fungitheir biggest challenges in performing code review were change owners not addressing feedback in a timely manner or being unreachable for discussion, and incomplete changes (missing tests/documentation) or failing tests15:30
fungiresponses noted that the time spent on mentorship was not as successful as it could have been, due to many mentees disappearing before reaching the point where they could become maintainers or engage in other leadership activities15:30
fungisurvey engagement as i said was great as compared to other teams, particularly from contributors, so i'd love to know a bit more about how we can replicate that, but maybe also find a way to get more maintainers to weigh in next time too15:30
fungias for metrics, the active maintainer count fell by 20% in flamingo as compared to epoxy (from 14 to 11), while the active reviewer count rose by 22%; note that both tiers of the split-core model count as maintainers for this purpose15:30
fungiinterestingly, the speed at which changes were closed or merged got more consistent in flamingo: even though the median time rose from 7.25 to 8.27 days, the average (mean) fell by half from 127.27 to 63.2215:30
fungilike in epoxy, the maintainers did close (slightly) more changes than were created in flamingo, indicating the team is still keeping up with this load; the totals fell slightly by around 9-10%, but still less than the drop in maintainers15:31
* TheJulia wonders how people think we use blueprints15:31
fungithe average (both mean and median) patchsets per review also rose by approximately 1, with the median doubling from 1 to 2, which suggests that it's taking contributors more tries to address feedback or get tests passing15:31
fungithe community managers have been distilling feedback from last year's discussions, and are working on compiling a concise set of techniques/recommendations for improving communication and efficiency, which i can get into more next week15:31
fungiwe're also hoping to get some case studies done in concert with successful contributors and maintainers to highlight how specific practices and behaviors help them achieve better throughput, in hopes of being able to replicate them15:31
fungianyway, that was a quick dump, i know it's a lot to take in but i didn't want to eat up too much of your meeting, so i'll put this on the agenda again for next week to give everyone time to digest and come up with questions or ideas15:31
fungithough i'm happy to answer any immediate feedback now if there's time15:31
JayFGiven you've done these and seen these across multiple projects, do you have any specific concrete suggestions or observations that might be unique to ironic15:31
dtantsurwow, that's a lot of info, thanks fungi!15:32
jandersfungi++15:32
TheJuliaSo crazy question, would it not make sense to create a dashboard with rolling window statistics?15:33
fungiit would be great to have that, yes15:34
fungiat the moment, funding has been pulled for third party custom analytics development (what we were paying bitergia to work on) in favor of relying on the linux foundation's lfx insights developers15:34
TheJuliaso is some sort of item for a rolling statistics from gerrit review on that team's backlog?15:35
fungiinstead, the community managers have been writing scripts and manually performing long-running queries to put reports together15:35
JayFTheJulia: there is something like five or six issues already opened around other day-to-day uses of the metrics that aren't being taken care of. I don't know if you've had a chance to read the ML thread15:36
fungibut yes, lfx insights gerrit statistics should in theory eventually cover the points we've been looking at15:36
fungiwe fed them details of the things we manually query to get them implemented15:36
TheJuliaJayF: I spotted it, but I wanted to ask because there are different metrics and I didn't see if that was on the identified list, or not15:37
fungiso that's been a fairly high priority, among the list of things we've asker them for15:37
fungier, asked15:37
TheJuliaCool cool, thanks15:37
* TheJulia is still curious how people are saying we have blueprints15:37
JayFTheJulia: they can't even currently sort repositories by governance, so there's no way to view all ironic related statistics at all right now15:37
JayFWe do have blueprints... For changes to the ironic Nova driver15:37
TheJuliaThe tiered governance structure is a bit... different15:38
fungiTheJulia: my guess is assumptions based on other teams and/or momentum from ancient history. the same thing came up for the manila team, fwiw (contributor survey respondents said they looked at lp blueprints for prioritization cues, the maintainers didn't use them though)15:38
JayFI wonder if someone did for project in projects; same answer15:38
TheJuliaSure sounds like it, which calls into question the overall survey results15:39
TheJulia(unfortunately)(15:39
fungibut yeah, the entire reason we added these questions around prioritization for the flamingo cycle surveys was because epoxy responses gave the indication that there may be a mismatch between how teams are tracking priorities and where contributors think it's happening15:39
fungiso does point to an opportunity for a lot of teams to more effectively communicate how and where they prioritize development and review work15:40
fungithe answers we got from the flamingo surveys seemed to confirm that suspicion15:40
JayF"more effectively communicate" doesn't always really help though; I'm not sure what venues we have that we aren't using15:41
fungithat's where we hope to dig into recommendations for communication strategies15:41
JayFwe can't make people read the copious notes we put out to ML, IRC, specs/docs repo, release notes, or even youtube videos -- I literally put out a video every PTG talking about our priorities and where to find them15:41
JayFwe are a lot of places already; most people just don't turn to the "OpenStack" section of their local newspaper /s15:41
TheJuliaAnd then if people are claiming to be contributors, how are they actually contributing then?!15:42
fungilike would it help to have cut-and-paste templates or autoresponse comments in reviews that also mentioned where to check the proposed change against the team's priority shortlist15:42
JayFfungi: our priorities don't really work that way though15:42
TheJuliaOr is it just "I cloned it on github and I have my repo and somehow that is contributing"15:42
JayFfungi: we don't generally de-prioritize review for non-priority things15:42
JayFTheJulia: I am curious now if e.g. adamcarthur5 filled one out as an "Ironic contributor" but in external repos (he works on go SDK stuff among others)15:43
fungia lot of the early feedback we got from organizations whose employees were struggling to contribute effectively indicated that they didn't realize their changes weren't a priority for the team they were proposing them in, or how to participate in the prioritization process/discussions15:43
JayFor generally if that pattern was followed by anyone15:43
TheJuliaI think I'm the maintainer, unless others filled out the maintainer questionaire15:43
JayFYeah, I have personally experienced that too, fungi, but in other projects.15:43
dtantsurTheJulia: I might as well..15:44
JayFI would really, really like to think Ironic doesn't get that issue, but to be honest if we do it'd almost definitionally be a blind spot for me-personally given I'm the top project reviewer15:44
JayFTheJulia: dtantsur: I would've filled it out as a maintainer, but I don't trust that I remembered to15:44
fungiright, i can't say for sure it's a problem in ironic because the specific cases we looked into were for other teams, but for example changes just sat for weeks/months with no feedback at all when the change owner would have prefered a one-sentence response of "this isn't a priority for us right now"15:45
TheJuliaI think there needs to be a question "how do you contribute?"15:45
TheJuliaand we need to put the cases which are not actual contribution into that answer list to identify the disconnect15:46
TheJuliafungi:  Yeah, we'd like that from other projects actually.15:46
fungithe survey outreach we do includes an e-mail to everyone who had a change merged to an official openstack project for the cycle, but yes we also want feedback from (perhaps even moreso) people who tried and didn't succeed to get their changes merged, so we can better understand why15:47
TheJuliaspeaking of, cardoe did you abandon that change we moved to networking-baremetal?15:47
cardoeNo not yet.15:47
TheJuliacardoe: might as well, we have something better now :)15:48
cardoeYeah agreed.15:48
cardoeSpeaking of GitHub, I threw together a GitHub Action which if given a Gerrit account will take PRs and open them against the project.15:49
cardoeI do find it hard to find people's contributions in gerrit sometimes to dig them back out.15:49
JayFcardoe: that makes me weirdly nervous 15:49
fungithe contributor experience survey does ask questions about "the changes you propose" and "feedback from reviewers" so there's an implication that we're looking for people attempting to contribute through proposing changes into gerrit, but you're right that we don't actually ask the respondents whether they do that15:49
cardoeI also get lost in old ones that should be ignored or old ones that haven't had feedback. So I've been asking folks about abandoning ones.15:49
JayFcardoe: anything where the security failure case is "soemone posts a thing that looks like you did it" makes me nervous15:49
TheJuliafungi: It sort of feels like there is room to gather more data through delineating questions, it would increase the analysis burden, but maybe if there is a way to really understand where respondants are coming from, then its more possible to understand the gap15:50
TheJuliaand thus how to manage it15:50
cardoeJayF: It takes the GitHub PR and uses the same author as on the GitHub PR and uses the Gerrit user as the uploader. It updates things with a cross-link. I've held off on proposing it because I'd like it to educate the user with some docs.15:50
fungisure, that's great feedback, i'll make a note of it and see how we might integrate that for the 2026.1/gazpacho retrospective round15:51
TheJuliacardoe: is the line author tracking maintained?15:51
cardoeIt also only does so for PRs with a DCO.15:51
cardoeYes cause git has a separate git author from git committer.15:51
cardoeThe committer is the bot and the author is the original.15:51
TheJuliafungi: the other aspect, likely start the poll before the end of cycle and try to wrap it and analysis sooner into the new cycle. If somehow feedback can be available for PTG discussions, that helps close the loop and drive it into actual planning15:52
TheJuliacardoe: that... might... work15:52
TheJuliaWow, github shows 366 forks15:53
fungiTheJulia: yeah, we start just before the end of the cycle usually, during the rc period when most development activity has slowed, with a goal of having survey responses in around or just after the ptg (taking advantage of ptg sessions as opportunities to promote the survey more)15:53
fungibut we could start after feature freeze even? maybe?15:54
TheJuliaThat would likely be advisable and try to have something in advance of the PTGs so its top of mind while the teams are retrospecting15:54
fungithis time we delayed the analysis outreach because lots of teams skiipped their meetings through december and into early january15:54
TheJuliaGranted, it won't be as detailed, but any data is better than no data15:54
fungithe analysis itself was complete in late november, just by then we were concerned there wouldn't be many people around to hear it15:55
JayF++ to the idea of having this as part of PTG retrospective15:55
JayFeven if it means we split cycles we're talking about instead of talking about it along release boundaries15:55
fungiall very good ideas, thanks, we'll definitely look at what options we might have15:56
TheJuliaGoing back to what JayF sort of said, there seems to be an opportunity, but we don't know what else we can really be doing. I mean, I don't think we're outright ignoring changes and having that pattern of behavior we even see in other projects. :\15:56
JayFThe real piece we'd need to make improvement on the one thing ID'd15:57
JayFis knowing *where* to communicate to these folks15:57
TheJuliaAnd, I'm not even sure that is truly a thing we have identified15:57
cardoeHow to communicate and how to identify patches the team is reviewing?15:57
fungiyeah, in this case it seems like the main items raised in analysis were contributor experience survey respondents not understanding how the ironic team prioritizes things, and the drop in number of active maintainers seemed a little odd15:57
TheJuliaGranted, we could likely go back and scrub/check for stuff just sitting ignored15:58
JayFagreed; just making sure it's not left at 'communicate harder' which isn't really useful :D 15:58
cardoefungi: the prioritization thing a feedback against other projects?15:58
TheJuliaJayF: actualy, that is anti-useful15:58
* JayF notes he has a review dash he uses to see things not marked prio across any ironic repo which occassionally unearths things15:58
cardoeJayF: all maintainers are issued bullhorns and make announcements using bullhorns.15:58
fungicardoe: yes, it seemed we had indication it was a common issue due to secondary symptoms highlighted in epoxy responses so we added direct questions about it for flamingo15:58
cardoeJayF: yeah that's what I've been using as well. I'd honestly like us to abandon stuff that should be abandoned so that I stop coming back to it.15:59
TheJulia"communicate harder" when you don't know where the disconnect is, is practically gaslighting. We need to to constructive data. :(15:59
JayFcardoe: I've been alive 43 years and some change. Not a single time, ever, has anyone offered me any kind of voice amplification device ;) 15:59
JayFcardoe: you are a core. Use the abandon button. Just give the person an action if they want to re-open it15:59
fungiright, i don't think asking anyone to "try harder" is going to help, that's definitely not the goal. it's to try and find what's working and see if we can replicate those patterns, or come up with additional time-saving solutions for maintainers16:00
TheJuliaPlease don't give JayF a loud speaker ;)16:00
JayFI *am* a loud speaker16:00
TheJuliaexactly!16:00
fungii can hear JayF on conference calls even when he's muted ;)16:00
TheJulialol16:01
dtantsurhehehe16:01
TheJuliaAnyway, was there anything else?16:01
TheJuliaLike, who is going to run next week's meeting?16:01
jandersI've got one small thing16:02
jandershealth monitoring Q16:02
JayFit's :00 so it needs to be extra small :) 16:02
JayFTheJulia: I'll be around, I'll make a note16:02
janders2/3 patches merged, https://review.opendev.org/c/openstack/python-ironicclient/+/967055 almost16:02
jandersshould I raise a doco change showing how to use health monitoring?16:02
TheJuliaA final note, the week of 2/9 I will be in Ireland so unable to run a meeting that week. I'll likely be a zombie the following week since the earliest I'll get to a bed is sunday morning.16:02
TheJuliajanders: always!16:02
TheJulia:)16:02
jandersOK, will do16:03
TheJuliacool cool16:03
TheJuliaThank you for pushing that this cycle!16:03
jandersthanks! further qs I can ask after the meeting16:03
jandersthank you to all who helped review patches16:03
JayFjanders: yes16:03
TheJuliaThanks everyone! Now, onward and back to regularly scheduled non-meeting chaos!16:03
TheJulia#endmeeting16:03
opendevmeetMeeting ended Mon Jan 26 16:03:54 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:03
opendevmeetMinutes:        https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-26-15.00.html16:03
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-26-15.00.txt16:03
opendevmeetLog:            https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-26-15.00.log.html16:03
JayFRelated: I'm going to be out Feb 13 through as long as two weeks recovering from a medical thing.16:03
TheJuliaJayF: ack ack16:04
dtantsuroh, good luck!16:04
janders++16:04
cardoeI'll be out Feb 5th to 16th myself.16:04
TheJuliaJayF: related to last weeks' redfish discussion, janders may have another update, but the tl;dr is there is some discussion of revising the ComputerSystem details which can be used to close the loop with vendors who do weird things.16:05
janders++16:05
jandersneed to follow up further16:05
jandersit dropped off agenda last week16:05
TheJuliajanders: I likely won't be able to join tomorrow, my wife has a medical appointment and I'm expecting the whole day to be a wash16:05
jandersTheJulia no worries, I'll try sort this out16:06
TheJuliaThanks!16:06
jandersnp16:06
jandersTheJulia kubajj would you like me to respin https://review.opendev.org/c/openstack/python-ironicclient/+/967055 removing the unnecessary test, or do we just merge it? It has 2x+2s, just needs workflow, was wondering if that's intended16:06
cardoewhat are we doing about bifrost and centos9? If we're not fixing centos9 then we need to close the backports to 2025.1 and 2024.2 cause they won't pass16:07
TheJuliajanders: I didn't go hunt down that test, but it makes me wonder overall16:07
kubajjjanders: merge16:07
TheJuliaI could be good with just merging it though for one test with mixed vlaue16:07
TheJuliavalue16:07
TheJuliacardoe: That is good overlap, becuase I think I actually start my trek to ireland on the 6th....16:08
jandersthanks! I will try sort out the doco change soon, will drop latest master code on my lab once the client change passes gate16:09
TheJuliacool cool16:10
TheJuliacardoe: if you can take some time to skim https://review.opendev.org/c/openstack/networking-baremetal/+/974619/ today, it would be good. I'm sort of hoping to try and get it sorted before going to ireland, and then try and focus on NGS stuff afterwards16:11
cardoeWill do16:11
cardoeSo https://review.opendev.org/c/openstack/python-ironicclient/+/860688 is an example patch.... should that be abandoned or not? How does it work with stevebaker[m]'s work?16:12
TheJuliaThanks16:12
JayFYeah and while I'm out (it's carpal tunnel arthroscopy), I won't be completely unavailable, if something emergent happens I can left-hand my keyboard for a bit :D 16:13
TheJuliaI suspect, just seeing the title that it was the "we're never going to reach consensus on this" path16:13
TheJuliaHmm, cardoe, we could definitely spend some time abandoning ironicclient patches16:20
JayFmaybe turn our 10am group networking review into group networking review then group review jam?16:21
JayFit'd be a good chance to land/abandon things16:21
TheJulia++16:25
TheJuliaI've been checking out some of the items in python-ironicclient and abandoning them16:25
TheJuliamostly stuff form 201716:25
cardoerpittau: since you got the release done i think https://review.opendev.org/c/openstack/python-ironicclient/+/970562 can be unblocked16:28
opendevreviewMerged openstack/python-ironicclient master: Add support for node health status field  https://review.opendev.org/c/openstack/python-ironicclient/+/96705516:28
rpittaucardoe: done16:28
rpittauneed a rebase though16:29
cardoeyeah cause the node health bumped the max_version variable.16:29
cardoe:/16:29
cardoeJayF: you wanna rebase and I'll approve it again?16:29
cardoehttps://review.opendev.org/q/project:openstack/python-ironicclient+status:open that's pretty cleaned up.16:30
opendevreviewJay Faulkner proposed openstack/python-ironicclient master: Filter portgroups by shard  https://review.opendev.org/c/openstack/python-ironicclient/+/97056216:31
cardoeWould anyone complain if I mass abandon patches labeled as [DNM] that are all 6+ months old?16:32
JayFone thing to keep in mind16:33
JayFI think if a core abandons a patch16:33
JayFI'm unsure if the non-core can unabandon it16:33
TheJuliaonly the author can16:33
TheJuliaerr16:33
JayFauthor or core has to unabandon, got it16:33
TheJuliacommitter16:33
JayFthen it's not so bad16:33
cardoeI think it's author or core not committer.16:33
TheJuliaYeah, I mean, its doable, but sometimes the DNMs also contain the small quick fixes that got forgotten16:33
cardoeCause that's what bit me on the nova spec changes. I was the committer and not the author cause I was updating someone else's spec.16:34
cardoeTheJulia: I'm happy to look at them. There's a lot that just change a line of white space that say "testing ci"16:34
TheJuliaoh yeah, abandon CI tests with ruthlessness16:34
cardoee.g. https://review.opendev.org/c/openstack/python-ironicclient/+/85510916:34
cardoehttps://review.opendev.org/c/openstack/ironic/+/89593816:35
cardoeThere's a lot of those that just touch setup.py16:35
TheJulia++16:35
cardoeAs far as python-ironicclient goes I believe there's 2 patches we should land for 2026.1. We've already landed 100% API compatible-ness (that's what I was pushing on last week).16:36
cardoehttps://review.opendev.org/c/openstack/python-ironicclient/+/970562 and https://review.opendev.org/c/openstack/python-ironicclient/+/97394816:36
cardoeThe 2nd was good until the node health caused a conflict.16:37
cardoeI'd like to ping stephenfin and frickler again about https://review.opendev.org/c/openstack/openstacksdk/+/973287 so we can finish off the NGS changes.16:37
cardoeTheJulia: I'm likely to map my physical fabrics separation to conductor groups. So I'll utilize the conductor sharding for the behavior of network node groups and other operations.16:38
cardoehttps://review.opendev.org/c/openstack/ironic/+/958505 was one of our Ironic 2026.1 priorities so landing that will complete that priority.16:39
TheJuliacardoe: I was wondering about that when I was going back and forth with claude16:39
TheJuliaI do think its reasonable, but we do really need it landed in the sdk first16:39
opendevreviewMerged openstack/ironic bugfix/34.0: Update .gitreview for bugfix/34.0  https://review.opendev.org/c/openstack/ironic/+/97474116:39
cardoeMy first goal is to land all this in a functional state. And then think about the sharding parts.16:39
TheJuliaBut I also wanted to see if you had thoughts or opinions there first16:39
TheJuliaRegardless, in the current model it should just cover it, but conductor grouping allows for operational domain constraining to what you otherwise expect16:40
JayFcardoe: TheJulia: Wait, are you suggesting we're tying network scaling to conductor groups?16:44
JayFIt is a bad assumption that conductor groups always map to physical environment differences (or vice versa)16:44
TheJuliaThey don’t, but on the ironic api query side16:46
TheJuliaSay you have one ironic, two neutrons16:46
JayFso you could point each conductor group to different neutrons?16:47
JayFor vice versa, if that makes sense16:47
TheJuliawell, we can't do that in ironic today, but if you have multiple fairly distinct neutron setups, you may need a filtered view to be presented16:52
TheJuliaso you appropriate isolate flows or traffic16:52
TheJuliaImagine physnet-x and physnet-y maps to conductor_group zpm, where as physnet-a,b,c are map to EarthForce. You don't wnat jobs in the Earthforce environment trying to manage the ZPM environment, so each side you filter down the views16:53
TheJuliaThe chassis grouping in ovn should sort itself out based upon physnet mappings, fwiw16:54
TheJuliaSorry for fixing Stargate atlantis and B5 in my examples, Green/Purple didn't come to mind in time.16:55
JayFOK; so it's not a scaling problem just a deliniation one16:55
TheJuliaKind of, the physnet delineation is where the scaling is actually at16:56
TheJuliaThat is because the physnet mappings get held in the OVS metadata for each individual node taking part in OVN16:57
TheJuliaClaude, what are you doing today17:42
cardoeTheJulia, JayF: What I'm saying is I dunno what the answer is. But once we get this working all together and landed that's the next area I'm gonna try and look at.17:51
cardoefwiw...17:51
cardoeopenstack baremetal node console show Dell-3R9PC14 -f json -c console_info | jq -r '.console_info.url' works17:51
cardoeIt'd be nice if the CLI gave a nicer output of that URL17:52
TheJuliaa quick "give me a human url if available" command seems like an easy win17:52
cardoeSo :golf clap: stevebaker[m] on the feature.17:52
cardoeWe did backport the kubernetes patch to our stable/2025.217:52
cardoeopenstack baremetal node console url <node> ?17:53
JayF-f value -c console_info # I'm assuming this gives an ugly response17:54
JayFI'll drop a zoom link in here shortly so we don't have a 1 hour timer17:56
JayFjust getting to the end of my current thread17:56
TheJuliaI can drop a gmeet link which has no timeout as well17:57
TheJuliaeither works17:57
TheJuliathe hour limit is only when I don't use my work machine17:58
cardoeThe only confusing thing we hit was ironic-console-pod.yaml.template vs ironic-console.container.template... one is for systemd and one is for kubernetes17:59
cardoeYou know which is which?17:59
TheJulianot off the top of my head18:00
TheJuliahttps://meet.google.com/ivk-hvkp-xwt ?18:00
JayFjoining18:01
JayFbeat me to it by seconds :D18:01
cardoegimme just a little bit18:04
cardoeand I'll join18:04
JayFalegacy: https://docs.openstack.org/oslo.log/latest/user/guidelines.html18:56
TheJuliaLast call for reviews on https://review.opendev.org/c/openstack/ironic/+/96647019:26
opendevreviewMerged openstack/ironic-specs master: VXLAN networking  https://review.opendev.org/c/openstack/ironic-specs/+/95940119:38
JayFI have also passed down the question to my downstream w/r/t how much info is too much info to log re: ironic-networking19:40
stevebaker[m]Hey I wonder if I could get some reviews on this ironic-tempest-plugin patch which validates the nova graphical console change? https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/96364319:46
cardoeSorry I missed. My wife dragged me out the door to renew drivers licenses.20:02
cardoeI’ll follow up on any I need to.20:02
opendevreviewJulia Kreger proposed openstack/ironic-tempest-plugin master: Add project badge  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/97235720:08
TheJuliastevebaker[m]: slight issue with https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/96315220:22
TheJuliaThe tl'dr is I would just increment the minimum version to beyond the field, but when the field is usable with the value20:56
TheJuliain case someone doesn't do something entirely unexpected like run that plugin against a Zed cloud.20:56
opendevreviewVerification of a change to openstack/ironic-tempest-plugin master failed: Add graphical console validate to basic ops scenario  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/96364321:01
opendevreviewSteve Baker proposed openstack/ironic-tempest-plugin master: Add graphical console validate to basic ops scenario  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/96364321:10
cardoeJayF: so what do you think about us making a directory of schemas?21:10
cardoeI don't hate it.21:10
TheJuliaI think it makes a ton of sense to do21:11
TheJuliaI wouldn't tack that on as a requirement for any chnage21:11
cardoeWell unfortunately the version he has is wrong21:12
cardoeIt'll only work with packages installed editable.21:12
cardoeIf you build a wheel, a deb, or a rpm it'll fail21:13
TheJuliahuh, I'm not sure what is wrong then21:13
cardoeLemme check something in the newer versions of pbr21:14
opendevreviewClif Houck proposed openstack/ironic master: Add ConfigLoader class to TBN and use it in TaskManager  https://review.opendev.org/c/openstack/ironic/+/97249521:17
opendevreviewClif Houck proposed openstack/ironic master: Integrate TBN with vif_attach  https://review.opendev.org/c/openstack/ironic/+/97369021:17
opendevreviewClif Houck proposed openstack/ironic master: Prevent multiple attach actions being generated for the same port  https://review.opendev.org/c/openstack/ironic/+/97452021:17
opendevreviewClif Houck proposed openstack/ironic master: Filter out NoMatch actions in _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97456921:17
opendevreviewClif Houck proposed openstack/ironic master: Add an ordering method for TBN traits  https://review.opendev.org/c/openstack/ironic/+/97451921:17
opendevreviewClif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning  https://review.opendev.org/c/openstack/ironic/+/97369121:17
opendevreviewClif Houck proposed openstack/ironic master: Update TBN config file to improve trait structure  https://review.opendev.org/c/openstack/ironic/+/97477621:17
cardoeokay cause we are using newer pbr it should work-ish21:17
cardoehttps://docs.python.org/3/library/importlib.resources.html is what you need to use.21:18
cardoeRelying on the installed package layout is wrong21:18
stevebaker[m]Hey can I propose that ironic-tempest-plugin changes run ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa in the check pipeline? This is the job which nova changes run so adding test coverage for new ironic nova features requires extra steps to validate that the feature and the tests actually work together 21:19
TheJuliaSure, I guess, I'd honestly prefer to see the job name be changed since we haven't had an agent_ipmitool-tinyipa combo in a very very very long time21:21
TheJuliaI *beieve* its a job alias21:21
TheJuliaerr, believe21:21
TheJuliacardoe: hh, that last sentence puts it together21:23
cardoeCause data files don't always end up next to source code.21:23
stevebaker[m]TheJulia: Ah it looks like it is just ironic-tempest-bios-ipmi-direct21:23
TheJuliacardoe: yeah, now I understand what you were expressing concern over21:24
cardoeTheJulia: I do want your opinion on things like... https://review.opendev.org/c/openstack/ironic/+/97355721:37
TheJuliaBroadly thinking, I guess it is okay. JayF you might have some deja vu if you look at ^^^21:43
JayFI mean, I abandoned my attempt at doing that because native python enums suck21:44
JayFand that's more or less the feedback I got from some folks on that change21:45
JayFit's hard to argue with lol21:45
JayFI like the idea in theory, but the objects are just very weird to work with21:45
JayFcardoe: re: dir of schemas ... I honestly just wish the ironic-networking change would look like everything else and not cause a knock-on of a bunch of wheel-spinning work to make things consistent again21:46
JayFWe consistently use constants until that unmerged change, where everyone decided it's OK that we didn't use constants except me.21:47
cardoeJayF: I agree with you. I was just trying to understand your opinion of that change outside of the other changes.21:47
cardoeThe enum bits would get enforced by the type proposal that cid's got.21:48
JayFI mean, I think if we start relying on "I hope the json file gets installed alongside the python files" we're going to cause pain for people, even if we don't hear about it21:48
JayFcardoe: there are ways, outside of a python enum object, to ensure that types are enforced21:48
JayFcardoe: like simply using an object or dataclass would have a similar effect, with better ergonomics I believe21:49
cardoeWell there are ways to ensure the json gets installed is a thing... but that's now how the change is done21:50
JayFYeah, more complexity for us to manage to avoid creating a python constant21:51
JayFjust because something is possible doesn't mean we should be OK with adding on that complexity21:51
JayFI'm just frustrated because I suspect this was a claude decision that is getting defended for "I just want this to merge" reasons 21:51
JayFand after the fact folks are thinking it's better21:51
opendevreviewSteve Baker proposed openstack/ironic-tempest-plugin master: Add graphical console validate to basic ops scenario  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/96364321:54
opendevreviewSteve Baker proposed openstack/ironic-tempest-plugin master: Enable ironic-tempest-bios-ipmi-direct in check/gate  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/97478021:54
cardoeWell what I'm saying is if ya like the json schema as separate files. I'll make a patch to refactor the code base and use importlib correctly to load them.21:56
cardoeIt would certainly be easier to edit them as files cause right now I copy and paste them out to a file. Edit them and then paste them back in as a constant.21:57
JayFI like consistency, which we have until the ironic-networking change merges. I also prefer simplicity, which a python constant gives. 21:58
JayFHonestly, I didn't have a strong preference until I realized we'd be dealing with importlib.resources crap to get the json files installed21:58
JayFwait, cardoe -- if what you're saying is right, https://review.opendev.org/c/openstack/ironic/+/966470 needs a -1 as it doesn't add the needed things to ensure the json schemas get installed22:01
JayFcardoe: ^ is that a correct understanding?22:01
cardoeYes22:01
JayFack, I see your vote on it and have flipped mine too22:02
cardoeThey're not called out in pyproject.toml so they won't be installed22:02
cardoeSo it'll fail.22:02
JayFWell, it doesn't fail22:03
JayFCI is happy22:03
cardoebecause we install with pip install -e in CI22:03
JayFeven more reason to dodge importlib.metadata installed crap22:03
cardoeI'd rather we use it explicitly22:03
cardoeRight now pbr does some magic under the hood.22:04
JayFAfter having joined the gentoo python project; I rarely trust python pacakging tooling to work sanely in all circumstances22:04
JayFwhich leads me in a direction to use as little of the API surface of python packaging as I can get away with22:04
cardoeI'd just rather be explicit when its used.22:07
opendevreviewSteve Baker proposed openstack/ironic master: Remove old -ipmitool job definitions  https://review.opendev.org/c/openstack/ironic/+/97478922:28
opendevreviewJulia Kreger proposed openstack/networking-baremetal master: WIP: Trunk port reconciliation for L2VNI attachments  https://review.opendev.org/c/openstack/networking-baremetal/+/97461922:40
cardoeJayF: so if I can poke my toe on your lawn again... what's your complaint about the enum exactly? Cause it seemed like it made the case I proposed safer and consistently transformed the data.23:03
cardoeI'd also encourage ya to take a peek at hatch. It's honestly everything pbr wants to be but jettisons the depend on wrapping setuptools. It does everything declaratively without any magic. Since venv's are what the world uses they're first class citizens. So you get tox style support baked in and don't need to re-declare depends. 23:16
opendevreviewJulia Kreger proposed openstack/networking-baremetal master: WIP: Trunk port reconciliation for L2VNI attachments  https://review.opendev.org/c/openstack/networking-baremetal/+/97461923:36
JayFcardoe: just me-personally has a distaste for enum-the-python-builtin, I believe someone here also expressed that to me when I wrote a similarly shaped change for another part of the codebase (maybe dmitry? but I don't remember so don't wanna throw him under a make-believe bus)23:48
JayFcardoe: note that you only got that feedback when you asked it from me :)23:49
JayFcardoe: I like a lot of external python-setuptools-replacement-y things, but we are in openstack, we use pbr and I don't wanna be inconsistent23:49
cardoeI'm not talking about OpenStack stuff. You mentioned when working on Python packages and Gentoo. So I was just throwing a recommendation out there. I compared it to pbr/tox since I figured that'd seem familiar.23:50
JayFoh, with the gentoo python project hat on, the proliferation of tools is part of the problem :) every new tool is a new thing we have to be able to account for and build with23:56
JayFI spent an hour-ish this afternoon on this: https://github.com/gentoo/gentoo/pull/45538 23:56
JayFclaude-code is so effecient at coding itself they don't have to worry about things like consistent, easy installation methods because they can yolo yolo yolo it all23:57

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