Wednesday, 2026-01-28

opendevreviewVerification of a change to openstack/ironic master failed: Remove old -ipmitool job definitions  https://review.opendev.org/c/openstack/ironic/+/97478900:32
opendevreviewMerged openstack/ironic master: Change default value of some redfish firmware update config  https://review.opendev.org/c/openstack/ironic/+/97480000:43
ContinuityTheJulia: not sure I understand, ill catch up with you tomorrow 00:52
TheJuliaContinuity: it’s always easier to embrace the thing in motion if you align with it, harder if you try to move against it.01:22
TheJuliaMomentum and all ;)01:23
opendevreviewMerged openstack/networking-generic-switch master: Migrate setup configuration to pyproject.toml format  https://review.opendev.org/c/openstack/networking-generic-switch/+/97352602:47
opendevreviewJacob Anders proposed openstack/python-ironicclient master: Remove health from default node list columns  https://review.opendev.org/c/openstack/python-ironicclient/+/97498408:03
janders^^ follow up to health monitoring change, client-side. This is to prevent this: https://paste.openstack.org/show/bwS9KrGw1g9AHzcNIPNU/ CC stevebaker[m] cardoe. Would welcome your thoughts, meanwhile will work on a doco addition to cover health.08:09
jandersCause: we removed health from default API fields in the last round of reviews, but this got missed on the client side. Happens I suppose :) 08:10
rpittaugood morning ironic! o/08:13
opendevreviewPierre Riteau proposed openstack/ironic master: Set columns in bios_settings table to bigint  https://review.opendev.org/c/openstack/ironic/+/96834808:22
jandershey rpittau o/08:25
abongalegood morning o/08:33
opendevreviewJacob Anders proposed openstack/ironic master: Add documentation for node health monitoring feature  https://review.opendev.org/c/openstack/ironic/+/97498508:37
dtantsurcardoe: since we want consistency between redfish and agent inspections, it makes sense to delegate to the hook. A change like that will definitely need a release note though because of upgrade impact.12:40
dtantsurehmmm, folks, can anyone open https://docs.openstack.org/ironic/latest/ ?12:45
cardoejanders: I don’t think we can edit release notes like that.12:57
cardoedtantsur: loads for me12:57
kubajjhello Ironic! o/13:23
kubajjThis might be a stupid question: Is the default_inspect_interface config option not used in Ironic?13:24
kubajjIt is either in docs, api-ref or the config https://www.irccloud.com/pastebin/WMq8MRMk/git%20grep%20default_inspect_interface%20over%20ironic%20repo13:27
dtantsurkubajj: it's supposedto be used13:32
TheJuliagood morning14:01
TheJuliaBRRAAAINS14:01
TheJuliadtantsur: The latest docs worked just fine for me14:10
dtantsuryeah, the open for me now too. got 403 a few times.14:11
TheJuliaInteresting14:14
janderscardoe ACK, will respin it14:16
janders(w/r/t health monitoring client followup)14:16
cardoerpittau: if ya get a sec to respin... https://review.opendev.org/c/openstack/bifrost/+/97485514:27
rpittaucardoe: done14:28
abongaleJayF: stevebaker[m]: thanks for the review on https://review.opendev.org/c/openstack/python-ironicclient/+/973948.14:33
abongaleJayF: raised some questions on the patchset: How much API compatibility do we owe existing users?, is this OK with a major version bump?, and can the SDK team review? 14:35
abongaleidk how to address them, if ironic can chime in, please?14:35
cardoeI'm good with a major bump for it to ship.14:40
cardoeThat change would make scripting the client to me much easier.14:40
cardoeCause right now the field names change inconsistently.14:40
TheJuliaits sort of a bug fix because of that inconsistency, but we should treat it as major because it is breaking. One thing for sure, it will be breaking for folks with scripting looking for existing fields.14:43
opendevreviewAllain Legacy proposed openstack/ironic master: Add ironic-networking network interface  https://review.opendev.org/c/openstack/ironic/+/96647014:44
opendevreviewAllain Legacy proposed openstack/ironic master: Add standalone networking service installation guide  https://review.opendev.org/c/openstack/ironic/+/96647114:44
opendevreviewAllain Legacy proposed openstack/ironic master: Improve exception handling in switch driver factory  https://review.opendev.org/c/openstack/ironic/+/96985214:44
opendevreviewAllain Legacy proposed openstack/ironic master: Address remaining review comments for rpc methods  https://review.opendev.org/c/openstack/ironic/+/97118414:44
opendevreviewMerged openstack/ironic-python-agent bugfix/11.4: Update .gitreview for bugfix/11.4  https://review.opendev.org/c/openstack/ironic-python-agent/+/97473914:50
cardoeTheJulia: yep. break all my scripts please cause the scripts in OpenStack Helm suck cause of this inconsistency.14:52
TheJulia... That is not a response I expected from the hint of challenge ;)14:53
opendevreviewClif Houck proposed openstack/ironic master: Prevent multiple attach actions being generated for the same port  https://review.opendev.org/c/openstack/ironic/+/97452014:54
opendevreviewClif Houck proposed openstack/ironic master: Filter out NoMatch actions in _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97456914:54
opendevreviewClif Houck proposed openstack/ironic master: Update TBN config file to improve trait structure  https://review.opendev.org/c/openstack/ironic/+/97477614:54
opendevreviewClif Houck proposed openstack/ironic master: Add an ordering method for TBN traits  https://review.opendev.org/c/openstack/ironic/+/97451914:54
opendevreviewClif Houck proposed openstack/ironic master: Add default trait behavior to _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97496014:54
opendevreviewClif Houck proposed openstack/ironic master: Filter out already attached portlikes in plan_vif_attach  https://review.opendev.org/c/openstack/ironic/+/97452114:54
opendevreviewClif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning  https://review.opendev.org/c/openstack/ironic/+/97369114:54
JayFI did put a link to that patch in the SDK IRC15:03
TheJuliaMaybe a pending comment?15:04
opendevreviewJacob Anders proposed openstack/python-ironicclient master: Remove health from default node list columns  https://review.opendev.org/c/openstack/python-ironicclient/+/97498415:09
cardoeTheJulia: so OpenStack Helm likes to do their init / bootstrap stuff with bash scripts. And they've optionally got quite a bit that can be done like add some nodes and ports for the nodes via a YAML file.15:10
janderscardoe removed the release note edit and created a new reno instead ^15:10
cardoeI cannot easily parse the data with some helper functions cause the field names change between input and output. It's lead to a number of bugs in the past.15:10
TheJuliawoot, I got my updated ironic-neutron-agent started.... but we won't talk about the exceptions coming out of it15:11
* TheJulia suspects the software is traveling in a light cone past the event horizon15:11
janderskubajj once we have the client follow up sorted, would you be able to / interested in testing hardware health monitoring on a test system? I tested it on real hardware, but only one machine (which implies one model) and I can't easily simulate failures (so can't validate how it reacts to failure). I figured you folks may have a ton of hardware15:12
jandersincluding some moderately broken nodes :) 15:12
cardoejanders: were you talking about setting up an endpoint in the conductor that the redfish could send hardware events back to?15:14
janderscardoe no, this is separate - but I am interested in this also, with extending health monitoring in mind15:15
jandersI think iurygregory and dtantsur were looking into events 15:15
cardoeDo we have a bug for it or a tracker?15:15
cardoeI just want to reference it cause I think I'm going to ask Nidhi to work on that next.15:15
cardoeIt's either that or the storage stuff, TheJulia.15:16
TheJuliawho huh what?15:16
cardoeNidhi on my team that's done a bunch of the redfish inspection changes.15:16
TheJuliaoh, bugs please ? :)15:16
* TheJulia walks the corgi overlord15:17
cardoeSo before I forget... https://review.opendev.org/c/openstack/python-ironicclient/+/974984 once that's in that should make the client 100% compat with the upcoming api release.15:17
dtantsurOne of the worst aspects of IRC: not surviving even a mere reconnect...15:17
dtantsurcardoe: not sure if the link went through: https://docs.openstack.org/ironic/latest/admin/drivers/redfish/passthru.html#create-subscription15:18
dtantsurI'd be very interesting in having something in Ironic that would serve as a sink for events though15:18
dtantsureven if it's as simple as dumping everything with certain severity in the logs15:19
cardoedtantsur: yeah exactly.. building on that15:20
cardoehttps://specs.openstack.org/openstack/ironic-specs/specs/backlog/event-subscription.html we've got that spec which says its a backlog but I've not read it but I know that passthru exists so maybe its done?15:21
jandersonce we have monitoring all the way through the stack with health info sourced in Ironic in BMO, I'd be interested in extending it from a single OK|WARN|CRIT aggregate field to providing more data on what's actually failing15:22
kubajjjanders: oh, we do have broken nodes15:22
janderskubajj awesome! :) 15:22
dtantsurcardoe: it was not done as a generic API15:22
jandersIf I can ask you to re+2 the patch we will have all the code in master shortly15:22
kubajjI could probably chery pick the changes to our qa region15:23
jandersawesome15:23
jandersit would be great to see how the feature works in the wild15:23
jandersmy main focus areas are 1) reacting to actual failures and 2) how it works on heterogeneous hw15:24
kubajjjanders: I need all 3, right?15:24
kubajj(ironic, sdk, client)15:24
jandersyes15:24
janders+ client-followup (to avoid messy outputs)15:24
jandersso 415:24
janderswill you be interested in having health info in metal3/BMO (what I will be working on next w/r/t to this feature)?15:25
jandersor are you thinking Ironic at this stage?15:26
TheJuliadtantsur: ... I thought there wsa some work on event sinking at some point?15:30
dtantsurThere was a desire :)15:31
opendevreviewMerged openstack/ironic-prometheus-exporter master: Use SERVICE_HOST for url  https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/97463115:31
dtantsurIt may even end up on our backlog in 2026 (in the form I mentioned above: just dump them in the conductor logs)15:31
JayFNode history might be an interesting place to toss those kind of alerts too15:47
JayFOr potentially even republishing as notifications?15:47
* TheJulia pokes neutron and wonders why it is seemingly on vacation16:33
TheJulia... wut16:35
TheJuliadoh!16:39
TheJuliamisconfiguration16:39
TheJuliaJayF: it might also be a super bad idea, some gear as I understand it dumps an event for any sensor change16:40
JayFYou shouldn't be able to write things that throw events or alerts until you've been on call lol16:40
TheJulia"oh, temp sensor reading now 29.1c" "oh, temp sensor is now 29.2" *human stands in front of rack* "temp sensor is now 29.4!"16:40
JayFalert fatigue, my friends16:40
JayF:( 16:40
JayFeven my meat thermometer is smart enough to let me configure how many degrees of change before it pushes an update16:41
cardoeWhat about those that throw events for the same temp? because the value changed but due to rounding the displayed value didn't change.16:51
cardoeIt's devices like that which sometimes make me think... ya know... global EMP... let's start over from the ground up.16:52
JayFthe only real way to solve stuff like that in the medium/long term is 1) working with DMTF via folks like janders and 2) convincing your purchasing team that quality of BMC software matters, and having them communicate that to their vendors16:53
JayFultimately, our own employers' willingness to buy hardware with subpar firmware is the primary root cause of the issue we have any power to address16:53
TheJuliayup16:54
JayFIn my experience working with vendor engineers, they've come off as smug caricatures of a "works for me" developer who is tossing crap over the wall :(16:54
TheJuliaand trying to close the loop16:54
JayF"No, our software isn't broken because [specific CURL command] works" 16:54
dtantsur:D17:10
dtantsurFolks, do we have anything for the pattern like: I want networking prepared for deployment but then no actual deployment to happen? Is it essentially the custom-deploy interface without any extra steps?17:11
JayFnoop deploy interface, I assume, doesn't touch networking?17:16
JayFI would expect noop deploy interface to still end up with all the network bits in the right place if configured though17:17
JayFso... is that your answer?17:17
clifTheJulia: Regarding https://review.opendev.org/c/openstack/ironic/+/972495/comment/e8914144_63b34c62/ do you want me to remove the in-class lock and just use the global module-level lock? I don't think there is a risk of cross-locking atm but I could be mistaken.17:23
TheJuliaclif: I guess it depends on how your using the class, if your using it once and there is only one instance, then why have the lock.17:23
TheJuliaclif: then the other question is do you really really need a sub-lock, because each time it is initialized is an instance of it, and cross-threading wise it needs to be defined in advance of a thread launch17:24
TheJuliaThat is where I was kind of coming from, without looking at the actual class instantiation, does that make sense?17:25
clifYes, I suppose that's true. 17:25
clifI'll remove the class-level lock17:25
TheJuliaok, cool, thanks!17:25
opendevreviewClif Houck proposed openstack/ironic master: Add ConfigLoader class to TBN and use it in TaskManager  https://review.opendev.org/c/openstack/ironic/+/97249517:29
opendevreviewClif Houck proposed openstack/ironic master: Integrate TBN with vif_attach  https://review.opendev.org/c/openstack/ironic/+/97369017:29
opendevreviewClif Houck proposed openstack/ironic master: Prevent multiple attach actions being generated for the same port  https://review.opendev.org/c/openstack/ironic/+/97452017:29
opendevreviewClif Houck proposed openstack/ironic master: Filter out NoMatch actions in _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97456917:29
opendevreviewClif Houck proposed openstack/ironic master: Update TBN config file to improve trait structure  https://review.opendev.org/c/openstack/ironic/+/97477617:29
opendevreviewClif Houck proposed openstack/ironic master: Add an ordering method for TBN traits  https://review.opendev.org/c/openstack/ironic/+/97451917:29
opendevreviewClif Houck proposed openstack/ironic master: Add default trait behavior to _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97496017:29
opendevreviewClif Houck proposed openstack/ironic master: Filter out already attached portlikes in plan_vif_attach  https://review.opendev.org/c/openstack/ironic/+/97452117:29
opendevreviewClif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning  https://review.opendev.org/c/openstack/ironic/+/97369117:30
opendevreviewClif Houck proposed openstack/ironic master: Add ConfigLoader class to TBN and use it in TaskManager  https://review.opendev.org/c/openstack/ironic/+/97249517:44
opendevreviewClif Houck proposed openstack/ironic master: Integrate TBN with vif_attach  https://review.opendev.org/c/openstack/ironic/+/97369017:44
opendevreviewClif Houck proposed openstack/ironic master: Prevent multiple attach actions being generated for the same port  https://review.opendev.org/c/openstack/ironic/+/97452017:44
opendevreviewClif Houck proposed openstack/ironic master: Filter out NoMatch actions in _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97456917:44
opendevreviewClif Houck proposed openstack/ironic master: Update TBN config file to improve trait structure  https://review.opendev.org/c/openstack/ironic/+/97477617:44
opendevreviewClif Houck proposed openstack/ironic master: Add an ordering method for TBN traits  https://review.opendev.org/c/openstack/ironic/+/97451917:44
opendevreviewClif Houck proposed openstack/ironic master: Add default trait behavior to _vif_attach_tbn  https://review.opendev.org/c/openstack/ironic/+/97496017:44
opendevreviewClif Houck proposed openstack/ironic master: Filter out already attached portlikes in plan_vif_attach  https://review.opendev.org/c/openstack/ironic/+/97452117:44
opendevreviewClif Houck proposed openstack/ironic master: WIP: Update TBN simulator for vif_attach planning  https://review.opendev.org/c/openstack/ironic/+/97369117:44
JayF^^ We are making major progress on this and more of the patches are landable18:23
TheJuliacool cool18:23
TheJuliaThanks!18:24
JayFI <3 all the ddt tests18:26
JayFI used to hate that big decorator but not so much anymore :D 18:26
janderscardoe JayF happy to help. Dealing with two issues at DMTF at the moment, one should be sorted this week so can raise another one if need be. Happy to talk further.19:01
opendevreviewMerged openstack/python-ironicclient master: Remove health from default node list columns  https://review.opendev.org/c/openstack/python-ironicclient/+/97498419:10
janders^ yeay! last actual health monitoring patch from the initial implementation, thanks JayF clif cid19:16
jandersnow just doco left: https://review.opendev.org/c/openstack/ironic/+/97498519:16
jandersif you have any feedback I will be happy to pass it to Claude19:16
*** dking is now known as Guest70219:22
*** Guest702 is now known as dking19:25
dkingdtantsur (or anybody who knows): For IrSO, where are the deploy_kernel and deploy_ramdisk variable set?19:27
opendevreviewNahian Pathan proposed openstack/ironic master: Reduce API calls when collecting sensor data with redfish  https://review.opendev.org/c/openstack/ironic/+/95548420:20
cardoejanders, JayF: I was just making a joke about bad hardware in the world. Nothing specific.21:40
JayFtoo late, I already signed you up for "fix all problems with hardware ever" workitem for next cycle21:44
TheJuliadude, that is every cycle21:44
JayFwell, we usually spread it across the team21:44
JayFnext cycle? All Doug.21:44
JayFTheJulia: alegacy: https://review.opendev.org/c/openstack/ironic/+/966471/10..11#message-69fe92d772eee613906ea45b10528d3e7e7a24b0 I don't wanna leave a -1 on there, but I am not OK with us pre-determining we're going to break out API at some future point21:47
JayFforcing a migration to get new features? very yes. Planning to fully remove something that someone might have deployed working during Gazpacho? not cool :( 21:48
TheJuliaLets take a step back21:51
TheJuliawhat did we do with vifs ?21:51
JayFI don't know what you're getting at?21:52
JayFif I, as an operator, deploy this, and then 2-3 releases later have to migrate, I'd be upset and for good reason21:53
JayFthat's entirely the mindset I'm in around this21:53
TheJuliayeah, and I think your jumping to an extreme interpretation21:53
TheJuliaIn that, with vifs, which was the same sort of pattern21:53
TheJuliawe KEPT the extra field mappings for ages21:53
JayFI said "I assume we'll keep things working per microversion" and the response was "no, we're planning to break it"21:53
JayFas long as our plan involves something like that, it's fine21:53
TheJuliaoh, no, you don't microversion that away21:54
TheJuliayou always have to check it21:54
JayFI just don't want us to treat shipping a feature labelled "experimental" as carte blanche to break it up21:54
JayFs/it up/the api/21:54
TheJuliathe mechanism later is microversion guarded though21:54
TheJuliaextra, is just a freeform field21:54
JayFtrue-freeform21:54
JayFnot fake-freeform with a schema like local_link_conn21:54
TheJuliaso, when your looking at it, you can't use the microversion because you don't know it21:54
JayFit's have to look something like our instance_name thing21:54
JayFwhere if you API call to update extra[standalone_info] (whatever the key is), we intercept it and put it in the new field21:55
JayF(we proxy instance_info[instance_name] to node.instance_name in API code now)21:55
JayFthe reason this in particular is rough to me21:56
JayFis that it's even worse than an "N" calls for "N" nodes21:56
JayFthis is N calls for N ports which is a multiplier of nodes21:56
JayFso asking operators after the fact to move that metadata around is a big, big ask21:56
JayF(and bluntly, exactly the sort of thing that has caused pain for my downstream, operationally, slowing upgrades -- e.g. the ilo->redfish driver swap)21:57
JayFI'm not just being an API pedant for the hell of it :)21:57
JayFan online_data_migration + API shim could probably allow us to do the progression as we intend without putting operators at risk of a nasty migration22:00
TheJuliaclarifying comment on the post, I do like a migration goal if it is clean enough22:02
TheJuliawe... for some reason... refused to go down that path in large part because of nova22:02
JayFhttps://review.opendev.org/c/openstack/ironic/+/966471/10..11#message-69fe92d772eee613906ea45b10528d3e7e7a24b0 I flipped my vote back22:06
TheJuliaWe couldn't get them to change the interface quickly and we kept getting push back and even cases where people were starting to run dramatically different versions22:07
JayFIt's interesting because with ironic-networking and many new features22:09
TheJuliaoh, absolutely22:09
TheJuliaclaude, how did you break tooze hashring.py22:09
JayFwe're moving more and more from "we control both server/client of API" to "we are an API that is used for god-knows-what"22:09
TheJuliayeah22:11
TheJuliaContinuity: sorry, didn't remember to ping you earlier. Did my last statement make sense?22:22
cardoespeaking of vif mappings and cleaning that up still... https://review.opendev.org/c/openstack/ironic/+/973557 that's fixing the last of that up and making the interface safe from future changes.22:35
cardoeIf ya wanna peek TheJulia 22:35
cardoeIt fixes a couple of outstanding bugs with servicing vs tenant vif selection22:36
cardoeHow those bugs manifest themselves... I dunno yet.22:36
TheJuliaI'll ahve to look with a fresh brain22:42
TheJuliabeen fairly heads down on the agent22:42

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