| opendevreview | Merged openstack/ironic master: Start Xvfb and pass running display to x11vnc https://review.opendev.org/c/openstack/ironic/+/1001274 | 04:28 |
|---|---|---|
| opendevreview | Merged openstack/ironic master: Don't wrap a console container error twice https://review.opendev.org/c/openstack/ironic/+/1001703 | 04:31 |
| opendevreview | Takashi Kajinami proposed openstack/ironic master: Clean up deprecated send_sensor_data options https://review.opendev.org/c/openstack/ironic/+/1002012 | 06:11 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic bugfix/38.0: Redfish: retry transient 409 conflict on power-on https://review.opendev.org/c/openstack/ironic/+/1002045 | 10:49 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic bugfix/37.0: Redfish: retry transient 409 conflict on power-on https://review.opendev.org/c/openstack/ironic/+/1002046 | 10:50 |
| opendevreview | Merged openstack/ironic master: Add image_server_auth_hosts to restrict credential scope https://review.opendev.org/c/openstack/ironic/+/999744 | 10:51 |
| opendevreview | Merged openstack/ironic bugfix/38.0: Fix periodic task processing a node via the wrong interface https://review.opendev.org/c/openstack/ironic/+/1001328 | 10:51 |
| opendevreview | Merged openstack/ironic bugfix/37.0: Fix periodic task processing a node via the wrong interface https://review.opendev.org/c/openstack/ironic/+/1001329 | 10:51 |
| opendevreview | Merged openstack/ironic stable/2026.1: Fix periodic task processing a node via the wrong interface https://review.opendev.org/c/openstack/ironic/+/1001327 | 10:58 |
| opendevreview | Merged openstack/ironic-specs master: Add spec for sonic and nvue driver replacements. https://review.opendev.org/c/openstack/ironic-specs/+/998363 | 11:07 |
| iurygregory | good morning ironic, I'm back o/ | 11:08 |
| opendevreview | Merged openstack/virtualbmc master: Drop unused test dependencies https://review.opendev.org/c/openstack/virtualbmc/+/997856 | 11:37 |
| opendevreview | Merged openstack/ironic master: devstack: Fix multinode CI failures with unreachable API endpoint https://review.opendev.org/c/openstack/ironic/+/1001575 | 11:51 |
| opendevreview | Merged openstack/ironic stable/2026.1: Redfish: retry transient 409 conflict on power-on https://review.opendev.org/c/openstack/ironic/+/1000767 | 11:51 |
| opendevreview | Merged openstack/sushy-tools master: Remove note about old pip's behavior https://review.opendev.org/c/openstack/sushy-tools/+/998187 | 12:15 |
| opendevreview | Merged openstack/sushy-tools master: Add openstack-python3-next-jobs https://review.opendev.org/c/openstack/sushy-tools/+/998186 | 12:16 |
| stephenfin | o/ We've seen an uptick in failures in the ironic functional job for SDK recently. I don't believe anything has changed in SDK, so I think the issue may lie with Ironic | 12:17 |
| stephenfin | The failures all look like this one https://zuul.opendev.org/t/openstack/build/22caafe9284545f4a34279d9a1c7c264 | 12:18 |
| dtantsur | stephenfin: could put it on LP so that it's not lost in IRC? | 12:20 |
| dtantsur | looks like something became racy.. | 12:20 |
| stephenfin | While waiting for an allocation to be created, we get an error `no available nodes match the resource class baremetal-XXX` | 12:20 |
| stephenfin | sure thing | 12:20 |
| dtantsur | it looks like a race between two allocation tests, hmm | 12:23 |
| dtantsur | stephenfin: are SDK tests running sequentially or in parallel? has it changed? | 12:23 |
| stephenfin | Nothing has changed in either the SDK implement or test nor in the test tooling (stestr, testools etc.) that I'm aware of | 12:24 |
| stephenfin | iirc, we execute test classes in parallel and the order of those is random, but individual test methods in a test class are sequential | 12:25 |
| stephenfin | https://bugs.launchpad.net/ironic/+bug/2164899 bug report here. I've included info as much as I could without digging into ironic itself | 12:35 |
| stephenfin | *as much info | 12:35 |
| dtantsur | Thanks! I'm a bit worried about seeing two references to resource class baremetal-426 | 12:35 |
| dtantsur | I wonder if we unironically (!) have a random number clash | 12:35 |
| dtantsur | stephenfin: dunno how reproducible the problem is, https://review.opendev.org/c/openstack/openstacksdk/+/1002079 may help highlighting it at least | 12:43 |
| opendevreview | Merged openstack/ironic master: Switch ironic-standalone-redfish to autodetect deploy https://review.opendev.org/c/openstack/ironic/+/997910 | 12:46 |
| stephenfin | It's no harm, though I will emphasise that none of this code has changed in SDK in some time and the CI was consistently green for months before this started last month'ish | 12:46 |
| opendevreview | Esther Domfeh proposed openstack/bifrost master: Document enhanced node history CLI usage https://review.opendev.org/c/openstack/bifrost/+/1002083 | 12:50 |
| opendevreview | Merged openstack/networking-baremetal master: ruff: Fix outdated target-version https://review.opendev.org/c/openstack/networking-baremetal/+/1001464 | 13:14 |
| opendevreview | Esther Domfeh proposed openstack/bifrost master: Document enhanced node history CLI usage https://review.opendev.org/c/openstack/bifrost/+/1002083 | 13:29 |
| TheJulia | o/ I'm going to be out again today. would be good to remind folks about the ptg etherpad. | 13:31 |
| JayF | dtantsur: I wonder if any of clif's nova-compute speedup patches landed | 14:18 |
| JayF | dtantsur: if it's about when resources become available .... timing of that may have recently changed (for the better) | 14:18 |
| dtantsur | JayF: I don't think these particular tests rely on nova | 14:24 |
| JayF | ack, good to know | 14:24 |
| clif | JayF: not yet, got a -1 this morning I need to address | 14:55 |
| Mahnoor | no meeting today? | 15:04 |
| * clif shrugs | 15:07 | |
| dtantsur | Judging by the logs, JayF volunteered to run it | 15:07 |
| clif | yep | 15:07 |
| dtantsur | using half of his brain, mind you | 15:08 |
| JayF | oh, hey | 15:08 |
| JayF | #startmeeting ironic | 15:08 |
| opendevmeet | Meeting started Mon Aug 24 15:08:11 2026 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:08 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:08 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:08 |
| dtantsur | hey, half of JayF! | 15:08 |
| JayF | I don't recall volunteering to do this | 15:08 |
| JayF | but I am always happy to do it lol | 15:08 |
| clif | the logs recall ;) | 15:08 |
| clif | o/ | 15:08 |
| JayF | how dare you bring my previous statements into this ;) | 15:08 |
| Mahnoor | the other half of the brain volunteered :) | 15:08 |
| JayF | As always, we're operating under the OpenInfra Code of Conduct, be nice ;) | 15:09 |
| JayF | #topic Announcements/Reminders | 15:09 |
| iurygregory | o/ | 15:09 |
| JayF | #note Please review patches hashtagged ironic-week-prio at https://tinyurl.com/ironic-weekly-prio-dash | 15:09 |
| JayF | Also tag any patches you need landed | 15:09 |
| JayF | It's Aug 24 -- do you know where your release is? :D | 15:10 |
| JayF | #note It's R-5 (5 weeks until release); the hibiscus-3 milestone. Feature freeze, client library final freeze, requirement freeze, elections start | 15:11 |
| cid | o/ | 15:11 |
| JayF | Get those patches reviewed and if needed into the priority queue if you want it in 2026.2 | 15:11 |
| JayF | #topic Working Group Updates | 15:11 |
| JayF | Anything from the AsyncIO folks? | 15:11 |
| iurygregory | I was out last two weeks, medical leave, no updates | 15:12 |
| JayF | make sure to give your get_better coroutine the ability to preempt as needed :) | 15:12 |
| JayF | Security Coresec team update | 15:12 |
| JayF | OSSA-2026-008 was errata'd | 15:13 |
| JayF | We also have some public security bugs which are open with patches for review | 15:14 |
| JayF | they should be hashtagged as ironic-week-prio; please review them | 15:14 |
| iurygregory | ack | 15:14 |
| JayF | #note There are no Discussion Topics in the agenda; moving on | 15:14 |
| JayF | Bug Deputy updates | 15:14 |
| JayF | #topic Bug Deputy updates | 15:14 |
| JayF | clif: or cid, depending on what "current" and "next" mean in the agenda | 15:15 |
| JayF | one of you should talk :) | 15:15 |
| clif | that's me | 15:15 |
| cid | :D | 15:16 |
| clif | There's one new ironic bug filed this morning: https://bugs.launchpad.net/ironic/+bug/2164899 functional tests in openstack sdk sporadically fail possibly due to Ironic race condition | 15:16 |
| clif | http://bugs.launchpad.net/ironic-python-agent/+bug/2163748 there's also this IPA bug filed, which seems to need more discussion | 15:16 |
| JayF | that race is likely a good one to target resolving before 2026.2 | 15:16 |
| clif | Something about using verified discard to erase SATA SSDs? | 15:16 |
| JayF | Yeah; that is an RFE that should be discussed during RFE section | 15:16 |
| clif | those are the only new bugs I know of | 15:17 |
| dtantsur | I've just filed another one based on a downstream report: https://bugs.launchpad.net/ironic/+bug/2164916 | 15:17 |
| clif | no fair filing during my update ;) | 15:17 |
| clif | that's all I've got for bug deputy updates | 15:17 |
| JayF | #topic RFE Review | 15:17 |
| JayF | #link http://bugs.launchpad.net/ironic-python-agent/+bug/2163748 | 15:17 |
| JayF | I have concerns about inlining this as a new, potential default implementation for erase_devices. | 15:18 |
| JayF | As an optional method that has to be opted into by changing steps or setting config, +2 | 15:18 |
| JayF | Which means I'm -1 to the RFE as proposed in the bug | 15:18 |
| dtantsur | I seriously think that we need something like allowed_erase_methods with an *ordered* list of methods that can be tried | 15:19 |
| TheJulia | I think its a decent solution to the issue, and does have decent guarding and even verification, but I can see the need as dmitry has pointed out, to allow there can be an ordered list | 15:19 |
| TheJulia | unfortunately that will require a bit of a rewrite of the existing logic | 15:20 |
| TheJulia | (of what is in IPA today) | 15:20 |
| JayF | I agree, I am not thrilled with gating support for a new hardware erase method behind a mechanism RFE. | 15:20 |
| JayF | but I think it's expectation-violating to wipe security locked devices without an opt-in | 15:20 |
| TheJulia | I think the issue is more so, the hardware vendor is doing the locking and we can't unlock/override via the controller | 15:21 |
| TheJulia | so its really a bug | 15:21 |
| TheJulia | but, nuanced | 15:21 |
| TheJulia | we should consider "shred" an absolute last resort action on modern storage devices | 15:21 |
| JayF | I would suggest finding a way to get this code in to "unbreak" people ASAP, without flipping the model upside down, and add a topic for PTG about making "how much erase to erase" a setting in IPA | 15:21 |
| opendevreview | Merged openstack/ironic bugfix/38.0: Redfish: retry transient 409 conflict on power-on https://review.opendev.org/c/openstack/ironic/+/1002045 | 15:21 |
| JayF | even if it means in the meantime we're adding a clunky/temporary "use_discard_erase_method" or something | 15:22 |
| TheJulia | ++ I think that makes sense | 15:22 |
| JayF | So to confirm (please speak up if you disagree); consensus is: reject RFE in it's current form. Require it to be config-gated (default: off). Add an item to PTG (and maybe comment about this on the RFE) about making a global "how should we erase disks" option. | 15:24 |
| TheJulia | SGTM, https://etherpad.opendev.org/p/ironic-ptg-2027.1 will have some text shortly | 15:24 |
| opendevreview | Takashi Kajinami proposed openstack/ironic master: doc: Replace remaiming reference to legacy sensor_data options https://review.opendev.org/c/openstack/ironic/+/1002144 | 15:25 |
| TheJulia | okay, words added to the etherpad | 15:27 |
| JayF | #link https://bugs.launchpad.net/ironic-python-agent/+bug/2163748/comments/2 | 15:27 |
| JayF | #topic Open Discussion | 15:28 |
| JayF | Any items for general discussion among the team? | 15:28 |
| dtantsur | so https://bugs.launchpad.net/ironic/+bug/2164916 | 15:28 |
| JayF | OH, we also forgot to get a new bug deputy down. Someone volunteer please :) | 15:28 |
| dtantsur | I think it's caused by one of our security fixes | 15:28 |
| TheJulia | As a broad reminder, we need to begin surfacing the ptg discussion | 15:28 |
| dtantsur | whatever introduced is_source_a_path, TheJulia, you may have context | 15:28 |
| JayF | isap came with anaconda driver iirc | 15:29 |
| Mahnoor | I will be out fri and mon, dont want to volunteer this week for bug deputy | 15:29 |
| TheJulia | yeah, "a folder has all the contents" | 15:29 |
| TheJulia | since there is no singular item, its the composite | 15:29 |
| TheJulia | should be easy to put extra guards in, I thought we had all our request stuffs guarded, but I'm wondering if they are somehow hitting request pooling as well. | 15:30 |
| JayF | So it seems like this is only a security issue if we don't have good connect timeouts on that HEAD, yeah? | 15:30 |
| dtantsur | Hmm. It's not great that it allows DoS | 15:30 |
| JayF | This isn't that different of a mechanism to setting deploy_ramdisk or image_source to a non-existent HTTP url and hammering it | 15:31 |
| dtantsur | We do, but 60 seconds is quite a lot, and the reporter claims that eventlet doesn't really comply with them (on old versions) | 15:31 |
| TheJulia | I've got a family medical issue going on, so I can't dig into it today, but yeah, we should likely tune/wind it to something tighter in some cases as well. | 15:31 |
| opendevreview | Merged openstack/ironic bugfix/37.0: Redfish: retry transient 409 conflict on power-on https://review.opendev.org/c/openstack/ironic/+/1002046 | 15:31 |
| opendevreview | Merged openstack/ironic bugfix/37.0: Power off before ejecting redfish virtual media on ramdisk cleanup https://review.opendev.org/c/openstack/ironic/+/999259 | 15:31 |
| opendevreview | Merged openstack/ironic bugfix/37.0: Another attempt to fix fast-track after inspection https://review.opendev.org/c/openstack/ironic/+/999258 | 15:31 |
| JayF | I don't disagree it can be improved, I just think it's a big, big stretch to say it's a security issue | 15:32 |
| TheJulia | I'd say "mild security" | 15:32 |
| TheJulia | but also, what rights are required to trigger verify? | 15:32 |
| TheJulia | under our normal rbac model | 15:33 |
| JayF | the same rights one needs to trigger deploy/cleaning/servicing | 15:33 |
| JayF | which is why I'm kinda "eh" on if it's actually a security issue | 15:33 |
| TheJulia | yeah, in our normal model, its elevated | 15:33 |
| TheJulia | the issue is noauth and basic is functionally rbacless and that is the base problem | 15:33 |
| dtantsur | I thought that deploy is pretty low privileges | 15:33 |
| dtantsur | (And it affects higher level orchestrators like metal3) | 15:34 |
| TheJulia | that sort of opens that door, but we can't treat everything as "urgent security", because if everything is, nothing is. | 15:34 |
| JayF | being able to trigger a http call via an api call, is basically the crux of the security bit | 15:34 |
| JayF | and you can do "N" http calls with an actual-deploy, or a cleaning if configured in certain ways | 15:34 |
| TheJulia | so, So that is where where I'm hitting at "mild" | 15:34 |
| TheJulia | yup | 15:34 |
| JayF | it's sorta the price you pay for being an API to deploy things, people can tell you to deploy BS and you listen :) | 15:35 |
| JayF | if we wanna harden, just gotta get a connect timeout that's wired thru so the operator can choose what fits them | 15:35 |
| JayF | going lower than 60s in the common case will break people I suspect | 15:35 |
| TheJulia | or, we just have a tighter timeout for some operations | 15:35 |
| TheJulia | realistically, "automatic" things, need a tighter timeout | 15:35 |
| TheJulia | 60 seconds is "I'm deploying stuff on the moon" | 15:36 |
| TheJulia | and space dust got in the way for a moment | 15:36 |
| JayF | do not make that assumption | 15:36 |
| JayF | 60 seconds might be | 15:36 |
| JayF | I am deploying this instance through a tiny VPN on a not-fully-provisioned new DC | 15:36 |
| TheJulia | Okay, I'm deplying stuff over directway 2x dishes | 15:36 |
| * TheJulia twitches | 15:36 | |
| TheJulia | (128k down, ?8?k up | 15:36 |
| TheJulia | ) | 15:37 |
| JayF | yeah, it's unfortunate that people try stuff so far outta whack, but we gotta make sure we're flexible enough for it | 15:37 |
| JayF | defaults lower ++, but we gotta plumb thru a minimum setting | 15:37 |
| TheJulia | yup | 15:39 |
| JayF | Anything else for open discussion? I'll close the meeting at/around :45 if not | 15:39 |
| TheJulia | nope | 15:41 |
| cid | So, I had a question that came up during one of the reviews of the maintenance feature | 15:41 |
| * cid tries to get a link | 15:41 | |
| cid | #link https://review.opendev.org/c/openstack/ironic/+/1000752/1/ironic/common/exception.py#942 | 15:42 |
| JayF | I would tl;dr the concern as the new maintenance API, as proposed, would not allow idempotent "re-setting" of maintenance on already-maintenanced machines | 15:44 |
| cid | The change I have up changes what happens when a node is removed from maintenance state | 15:44 |
| JayF | IME with the kinda scripts that might set maintenance on somehting... I was wondering if we wanted to revisit the decision | 15:44 |
| JayF | existing behavior is if you set maintenance when it's already set, it accepts the request and changes the reason to whatever you sent | 15:44 |
| TheJulia | re-setting on the old setting interface? | 15:44 |
| JayF | (this is also the behavior retained for old microversions) | 15:44 |
| JayF | re-setting via the new interface | 15:45 |
| TheJulia | oh | 15:45 |
| TheJulia | hmm | 15:45 |
| JayF | has this new limiting behavior | 15:45 |
| TheJulia | I thought we were going to allow that | 15:45 |
| * TheJulia is dazed and confused, and likely needs to get going anyway | 15:45 | |
| JayF | yeah, this is behavior where I think either way is probably okay | 15:45 |
| JayF | and if nobody is attached to the "no duplicate maintenances", I'd be tempted to retain existing behavior | 15:45 |
| JayF | if the pair of (type,scope) match, don't conflict, just update reason | 15:46 |
| JayF | and teh node history SHOULD (as a requirement) retain the history of reasons | 15:46 |
| JayF | what we CANNOT do is add a row for each of those calls, or else something in a cron script like, once an hour or something, might insert 100+ node maintenance rows in a week if misconfigured | 15:46 |
| JayF | dtantsur: ^ do you have any thoughts on this? | 15:47 |
| * dtantsur is trying to remember how metal3 uses maintenance.. | 15:47 | |
| kubajj | o/ | 15:47 |
| cid | \o | 15:48 |
| dtantsur | From API purist perspective, having a separate maintenance API does give us some wiggle room that a proper PUT/PATCH approach won't | 15:48 |
| cid | Basically, The code as-is, will not allow same type and scope by the same | 15:48 |
| cid | *project | 15:48 |
| dtantsur | We may seriously consider to microversion this | 15:48 |
| JayF | dtantsur: yeah, I think as written it's a better/cleaner API, but I also think that cleanliness will be annoying to operators | 15:48 |
| JayF | dtantsur: it 100000% will be | 15:49 |
| dtantsur | (that being said, proper PATCH based API won't trigger the duplicate logic at all) | 15:49 |
| JayF | dtantsur: we're just talking about the behavior if someone does the similar behavior (sets an identical maintenance type twice in a row) on the new microversion | 15:49 |
| dtantsur | Yeah, it's not terrible to reject that | 15:50 |
| dtantsur | (proper PATCH with E-Tags... okay, I'll stop dreaming) | 15:50 |
| JayF | yeah I think rejection is the nice pretty answer | 15:50 |
| JayF | but I think it means a bash script that goes "should I maint this node?" needs 2x as much code aorund openstackclient | 15:50 |
| JayF | since it'll have to check or handle the conflict | 15:51 |
| dtantsur | which may mean that our CLI needs --ignore-conflict / --retry-on-conflict=N | 15:51 |
| dtantsur | (although we use conflict for way too many things..) | 15:51 |
| JayF | I mean, the idea is sound | 15:52 |
| dtantsur | Then again, blindly overwriting existing maintenance is a sketchy thing to do, I agree with that | 15:52 |
| TheJulia | Add that to the ptg etherpad! | 15:52 |
| TheJulia | (meaning, the conflict stuffs) | 15:52 |
| JayF | yeah please don't punt the whole question to PTG | 15:52 |
| JayF | or esle I gotta find somethign else to keep cid busy for a while lol | 15:52 |
| cid | :D | 15:53 |
| TheJulia | oh, yeah, no | 15:53 |
| Mahnoor | my 2 cents: I would expect a failure only if it actually failed to set maintenance, if it was the same, should be okay imo | 15:53 |
| JayF | I like the idea about handling the UI shenanigans in the UI | 15:53 |
| Mahnoor | but no strong feelings | 15:53 |
| TheJulia | I'm meaning, the conflict stuff in general needs to be on the etherpad because that is "annoying" | 15:53 |
| JayF | Mahnoor: ooh, that's an interesting third option | 15:53 |
| JayF | Mahnoor: 1) type/scope but not reason match: fail. 2) type/scope/reason match: succeed as a noop 3) type/scope are unique: succeed as an op | 15:53 |
| dtantsur | yeah, we can just ignore completely identical requests | 15:53 |
| JayF | that is the likely correct behavior | 15:54 |
| JayF | as it handles the script case | 15:54 |
| JayF | and keeps the API cleanly shaped | 15:54 |
| JayF | with the only downside being that created_at won't get touched, but that means we'll still accurately report the first time a maint of (type, scope, reason) was created | 15:54 |
| JayF | so maybe not even a downside | 15:54 |
| JayF | hell yeah | 15:54 |
| JayF | and we can provide guidance to operators to make the reasons generic in documentation (e.g. don't add your own timestamp) | 15:55 |
| JayF | dtantsur: Mahnoor: cid: ^ agreed? | 15:56 |
| dtantsur | ++ | 15:56 |
| Mahnoor | sounds alright to but, can one not update the reason? type/scope but not reason match: fail | 15:56 |
| JayF | the existing behavior would clobber the old reason with the new one | 15:57 |
| dtantsur | I don't remember if we actually allow PATCH on reason | 15:57 |
| Mahnoor | sorry I meant the quote your point no. 2 | 15:57 |
| JayF | the new API would not permit it, as you're only allowed one maintenance per type/scope combo | 15:57 |
| Mahnoor | ah okay | 15:57 |
| JayF | each maintenance in the new system is a DB row | 15:57 |
| Mahnoor | okay | 15:57 |
| JayF | comment put into gerrit | 15:58 |
| JayF | we are at time, basically, going to clsoe things out | 15:58 |
| cid | Does that mean "reason" will have to be stricter or a string is still okay? | 15:58 |
| cid | Anyways, I think I got it. | 15:59 |
| cid | Any further updates can always be added to the change | 15:59 |
| cid | #link https://review.opendev.org/c/openstack/ironic/+/1000752/comment/80877bb0_0eafb097/ | 15:59 |
| JayF | cid: lets work out the details in gerrit/code review or outside the meeting | 15:59 |
| JayF | #endmeeting | 15:59 |
| opendevmeet | Meeting ended Mon Aug 24 15:59:18 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-08-24-15.08.html | 15:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-08-24-15.08.txt | 15:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-08-24-15.08.log.html | 15:59 |
| JayF | I think I've sussed out the functional test bug with claude cc: stephenfin | 16:58 |
| JayF | looks like a bug in the openstacksdk testing code directly: we set the node to power off without a wait=true, and the times the tests fail are when the sdk gets the next step run *before* the power off hits the db | 16:59 |
| JayF | stephenfin: I wish I knew you were working on it; I duped all your work. https://review.opendev.org/c/openstack/openstacksdk/+/1002174 is a more complete change though, and I think should win? plus you can +2 that one :D | 17:17 |
| stephenfin | Oh, apologies: I had assumed it would link against the bug. I associated openstacksdk with it and all 😕 | 17:18 |
| stephenfin | but yes, yours is definitely the more complete of the two | 17:19 |
| JayF | I tend to work over longer periods of time, I had a thread running (AI and mental) since the meeting lol | 17:19 |
| JayF | I am more of a complete 10 things in 10 time than 1 thing in 1 time :D | 17:20 |
| JayF | lol | 17:20 |
| *** Uggla is now known as Guest16245 | 21:34 | |
| *** Uggla7 is now known as Uggla | 21:34 | |
| opendevreview | Merged openstack/ironic unmaintained/2024.1: Pin sushy-tools so we don't get into a python conflict https://review.opendev.org/c/openstack/ironic/+/1001385 | 21:53 |
| iurygregory | JayF, you mentioned the security patches are in the ironic-week-prio, I only see 15 patches most related to ngs and specs... I will check patches without the hashtag o/ | 22:04 |
| JayF | iurygregory: look for the one adding the basic auth hostname list | 22:04 |
| JayF | iurygregory: and the autodetect cleaning fix | 22:04 |
| JayF | those are the two at top of mind; if they are not ironic-week-prio please add it | 22:05 |
| iurygregory | ack! | 22:05 |
| iurygregory | I've found one from cid https://review.opendev.org/c/openstack/ironic/+/1000989/ | 22:05 |
| JayF | those are just backports that need some love, the advisory was already errata'd | 22:06 |
| iurygregory | seems like dtantsur has some thoughts on https://review.opendev.org/c/openstack/ironic/+/999907 , going to check the other | 22:07 |
| JayF | that's a great review comment by dtantsur++ | 22:08 |
| JayF | nice nice catch | 22:08 |
| iurygregory | will look at the autodetect o/ | 22:08 |
| opendevreview | Merged openstack/ironic stable/2025.2: Fix socat console broken by shell-quoting https://review.opendev.org/c/openstack/ironic/+/1000985 | 23:06 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!