| opendevreview | cid proposed openstack/ironic master: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973015 | 00:04 |
|---|---|---|
| opendevreview | cid proposed openstack/ironic master: Support `disable_ramdisk` during servicing https://review.opendev.org/c/openstack/ironic/+/973016 | 00:04 |
| opendevreview | cid proposed openstack/ironic master: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973015 | 01:52 |
| opendevreview | cid proposed openstack/ironic master: Support `disable_ramdisk` during servicing https://review.opendev.org/c/openstack/ironic/+/973016 | 01:52 |
| rpittau | good morning ironic! o/ | 07:58 |
| *** srelf_ is now known as ContinuitySR | 09:25 | |
| *** ContinuitySR is now known as Continuity | 09:25 | |
| abongale | good morning o/ | 09:40 |
| Continuity | Morning Ironic | 10:48 |
| *** dmellado4 is now known as dmellado | 11:41 | |
| opendevreview | Merged openstack/ironic master: Add two phase driver factor initialization https://review.opendev.org/c/openstack/ironic/+/971182 | 13:49 |
| opendevreview | Merged openstack/ironic master: Introduce switch driver base class https://review.opendev.org/c/openstack/ironic/+/971183 | 13:50 |
| opendevreview | Merged openstack/ironic master: Add generic switch driver support https://review.opendev.org/c/openstack/ironic/+/966469 | 13:50 |
| opendevreview | Merged openstack/ironic master: Fix async periodic on redfish for servicewait https://review.opendev.org/c/openstack/ironic/+/971581 | 14:11 |
| TheJulia | good morning | 14:33 |
| cardoe | should we alias direct deploy interface to agent? | 14:45 |
| TheJulia | It wouldn't be a bad idea at this point | 14:45 |
| cardoe | Maybe we make a bug about all the things that are inconsistently named so we can track it for a big update and WAAAAAAAY future deprecation. | 14:55 |
| dtantsur | I don't mind it either. The distinction is irrelevant nowadays. | 14:55 |
| TheJulia | 3 step: add an alias, migrate test initalizaitons and add a migration, likely next cycle. And then finally remove the old alias at some point down the road after it has been communicated | 14:56 |
| TheJulia | its a light lift, but we do need to let it roll for a while | 14:56 |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: VXLAN networking https://review.opendev.org/c/openstack/ironic-specs/+/959401 | 14:59 |
| opendevreview | Jacob Anders proposed openstack/ironic master: Add hardware health monitoring via management interface https://review.opendev.org/c/openstack/ironic/+/966946 | 14:59 |
| JayF | I can chair the meeting in like 5 minutes if no one else wants to | 15:01 |
| TheJulia | #startmeeting ironic | 15:01 |
| opendevmeet | Meeting started Mon Jan 12 15:01:26 2026 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:01 |
| alegacy | o/ | 15:01 |
| TheJulia | Good morning Ironic! | 15:01 |
| dtantsur | o/ | 15:01 |
| clif | o/ | 15:01 |
| JayF | o/ | 15:01 |
| janders | o/ | 15:01 |
| TheJulia | This will be our first meeting of 2026! | 15:02 |
| clif | \o/ | 15:02 |
| TheJulia | Consider it a slightly slow meeting, because it looks like we need to update the agenda | 15:02 |
| TheJulia | Our agenda, as always can be found on the wiki. | 15:03 |
| TheJulia | #link https://wiki.openstack.org/wiki/Meetings/Ironic | 15:03 |
| TheJulia | Everyone have coffee? | 15:04 |
| TheJulia | #topic Announcements / Reminders | 15:04 |
| JayF | That's what the 5 minutes was for 😂 | 15:04 |
| TheJulia | lol, true! | 15:04 |
| kubajj | o/ | 15:04 |
| TheJulia | Our first item is a general reminder for folks to review the patches tagged ironic-week-prio. | 15:04 |
| TheJulia | #link https://tinyurl.com/ironic-weekly-prio-dash | 15:04 |
| TheJulia | There are 31 patches, lets try to get that below 25 again | 15:04 |
| TheJulia | Furthermore, in terms of general reminder of where we are in the release cycle for 2026.1 | 15:05 |
| TheJulia | #link https://releases.openstack.org/gazpacho/schedule.html | 15:05 |
| dtantsur | There is no such thing as enough coffee this January | 15:05 |
| TheJulia | This week is week R-11. A few reminders will follow on. | 15:05 |
| janders | coffee++ | 15:05 |
| TheJulia | R-6 is final release for non-client libraries. R-5 is final release for client libraries. If your working on API surface changes, or have one which will impact the API surface, please highlight your work and remember to use the hashtag ironic-week-prio. | 15:06 |
| TheJulia | Moving on! | 15:06 |
| TheJulia | #topic Working Group Updates | 15:07 |
| TheJulia | First update, alegacy are you around regarding standalone networking? | 15:07 |
| alegacy | yep, i'm here | 15:07 |
| alegacy | Looks like a few patches merged this morning. thank you! | 15:07 |
| alegacy | hoping to be able to continue that momentum in the coming weeks and wrap this up. | 15:07 |
| alegacy | only 1 big patch left in the ironic repo... the other 3 small ones are cleanup/doc. | 15:08 |
| TheJulia | cool cool | 15:08 |
| alegacy | and then the 1 other patch over in bifrost. | 15:08 |
| cid | o/ | 15:08 |
| TheJulia | Very cool, anything else? | 15:08 |
| alegacy | nope, i'll keep an eye on incoming review comments. | 15:09 |
| TheJulia | Awesome! | 15:09 |
| TheJulia | Onward! Async IO. cid/dtantsur, any update? I'll apologize now I didn't look at the outstanding WIP patches yet. | 15:09 |
| dtantsur | I have some, yes | 15:09 |
| dtantsur | First, we have a proof-of-concept for asynchronous sensor collection: https://review.opendev.org/c/openstack/ironic/+/970450 and https://review.opendev.org/c/openstack/ironic/+/970842 | 15:10 |
| dtantsur | The latter is just for testing without refactoring the conductor | 15:10 |
| dtantsur | The former can be treated as a preview of how the asynchronous API may look like (don't worry too much about implementation details so far). | 15:10 |
| TheJulia | Good details, thanks! | 15:10 |
| dtantsur | I made two very opinionated decisions there | 15:10 |
| dtantsur | 1) The new client is inside Ironic not Sushy. Given the discussion around moving Sushy in, I think it's a valid thing to do. | 15:11 |
| dtantsur | 2) The new client is also low-level, it does not come with ready-to-use structures. | 15:11 |
| dtantsur | Here is where we may end up arguing quite a bit. I'm honestly quite tired of keeping sushy's structures up-to-date, especially since we use a tiny share of them. | 15:11 |
| rpittau | o/ | 15:12 |
| dtantsur | Check the script in the 2nd patch for how the API is *used* in practice. It's not as crazy as it may initially sound. | 15:12 |
| dtantsur | Finally, I'm working on the spec for all this: | 15:12 |
| TheJulia | I think #2 makes a ton of sense given some of the object instantiation overhead which exists, but it really just depends more so on the end result of "what" | 15:12 |
| dtantsur | #link https://review.opendev.org/c/openstack/ironic-specs/+/972754 WIP spec for async sensor collection | 15:12 |
| dtantsur | It has the motivational section and the high-level implementation proposal, so ready for early feedback. | 15:12 |
| TheJulia | cool cool | 15:12 |
| TheJulia | Anything else? | 15:12 |
| opendevreview | Jacob Anders proposed openstack/ironic master: Add hardware health monitoring via management interface https://review.opendev.org/c/openstack/ironic/+/966946 | 15:13 |
| dtantsur | I've also tried a purely threaded approach, and our futurist pool is not suitable for 3500 threads | 15:13 |
| cid | tks, dtantsur. I took a quick look at what you have going on in those patches. No updates on my side regarding Async | 15:13 |
| dtantsur | While the async script finishes in 30 seconds on 3500 fake nodes from sushy-tools (not VM based). | 15:13 |
| dtantsur | That's all from me. A bit verbose, but it summarizes a month worth of work :) | 15:13 |
| cid | ++ | 15:13 |
| TheJulia | Cool cool | 15:14 |
| TheJulia | Okay, onward! | 15:14 |
| TheJulia | VXLAN Networking. That is my area mostly, although cardoe feel free to chime in. | 15:14 |
| cardoe | bleep blorp | 15:15 |
| TheJulia | The spec is in a ready to review state over at https://review.opendev.org/c/openstack/ironic-specs/+/959401 and provides the overview of attachments and required steps. | 15:15 |
| TheJulia | The implementation is basically 3 parts, two of which are needed as well for Neutron EVPN to be used later on if an operator chooses to do so, but the model is more a physcial bridge/connection model to the fabric allowing for operators to make decisions based on their traffic *and* loads, i.e. leaning more towards ASICs doing things than CPUs and network card acceleration features. | 15:16 |
| TheJulia | We're starting to see some initial implementation patches at this point in time. | 15:17 |
| TheJulia | cardoe: do you have anything else to add? | 15:17 |
| cardoe | No I think that's spot on. | 15:17 |
| * TheJulia reloads the agenda to see if anyone snuck a discussion topic in | 15:17 | |
| cardoe | If I could get the little time trinket from Happy Potter that Dumbledore gives Hermoine, I'd make a lot more progress. | 15:18 |
| TheJulia | Okay, Given we have no discussion topics, we can proceed to Bug Deputy updates! | 15:18 |
| TheJulia | #topic Bug Deputy Updates | 15:18 |
| cid | That's me | 15:19 |
| cid | I triaged two bugs and a new RFE enabling direct deploy interface to switch to ramdisk https://bugs.launchpad.net/ironic/+bug/2137729. | 15:19 |
| JayF | that's my RFE if anyone has questions when we get there | 15:19 |
| cid | Also, I would love to get feedback on this change: https://review.opendev.org/c/openstack/ironic/+/973016 | 15:20 |
| TheJulia | Okay, so who would like to serve as the deputy for next week? | 15:20 |
| TheJulia | (for the next week) | 15:21 |
| cardoe | cid: yeah I'm a +1 on that change. I've got it opened to fully review it so that I can give it a +2. | 15:21 |
| dtantsur | huh, yeah, disable_ramdisk makes sense for servicing | 15:21 |
| cid | Alright cool. Because it felt like something that might or not need a fix, I just was not sure | 15:22 |
| cid | TheJulia, sign me up for bug deputy for next week. | 15:22 |
| TheJulia | cid: okay! | 15:22 |
| TheJulia | Onward! | 15:22 |
| cardoe | JayF: I think switching the deploy interface dynamically based on the image overall makes sense. | 15:22 |
| TheJulia | #topic RFE Review | 15:22 |
| TheJulia | so, JayF, you have the floor | 15:22 |
| JayF | I mean, I'm following the pattern laid out by stevebaker[m] for the direct->bootc swap | 15:23 |
| JayF | I was worried it'd become an "X to Y" deploy interface change problem, but realistically bootc/direct/ramdisk/anaconda is probably the entire list of ones reasonable for this feature | 15:24 |
| JayF | so I don't think there's a need to genericize it too much, just follow Steve's pattern | 15:24 |
| JayF | I already validated w/Dan that Nova+Glance shouldn't need code changes (only docs) | 15:24 |
| JayF | so I | 15:24 |
| dtantsur | My only request would be on the code level: please make a reasonable abstraction for it instead of just sticking more untested logic into deploy_utils | 15:24 |
| TheJulia | Yeah, the image itself hints/supplies almost every ounce of missing detail | 15:24 |
| JayF | **so I'm hoping to get this in for gazpacho | 15:24 |
| dtantsur | (maybe teh ship has sailed already) | 15:24 |
| JayF | dtantsur: review stevebaker[m]'s change | 15:25 |
| JayF | dtantsur: I will follow that pattern :) | 15:25 |
| dtantsur | has it merged already? | 15:25 |
| JayF | no | 15:25 |
| JayF | he owes me a guardrail | 15:25 |
| JayF | (so we don't try to enable bootc on conductors without bootc) | 15:25 |
| dtantsur | Well, at least it's not deploy_utils :D | 15:25 |
| TheJulia | Do we have anything else to discuss regarding this RFE? | 15:26 |
| dtantsur | (oh I don't like this code oh oh) | 15:26 |
| JayF | dtantsur: yeah I figured you might have that reaction. | 15:27 |
| TheJulia | The bottom line is it needs to be driven by the data on hand, not a user requesting it in large part because all of the data and information is present based upon the image source/service, so somehow that needs to be reconcilable. | 15:27 |
| dtantsur | I don't hate the feature, just using validate() for that | 15:28 |
| TheJulia | err, I'm not a fan on validate() | 15:28 |
| TheJulia | I'd much rather see it based upon the flow deeper in, but that leans towards deploy_utils as well | 15:28 |
| TheJulia | I've not looked at it in a while though | 15:28 |
| JayF | I'm happy my RFE pointed more eyes at this :) | 15:29 |
| TheJulia | There are only so many ways to solve the problem though short of making changes invasive. | 15:29 |
| * TheJulia suspects brains need to ponder | 15:30 | |
| TheJulia | Do we want to discuss the idea cardoe proposed just before the meeting? | 15:30 |
| JayF | If you care, please prioritize the review as I really, really want to get it in for G | 15:30 |
| dtantsur | Will you hate me for suggesting a new "dynamic" deploy interface? | 15:30 |
| JayF | no, I actually think that's probably a solid idea | 15:30 |
| cardoe | Will you hate me if I say yes? :D | 15:30 |
| JayF | Only real downside is my use case is "try ramdisk driver with less risk" | 15:31 |
| cardoe | I actually think dynamic makes sense and it can change and the others won't change. | 15:31 |
| JayF | and pushing down a "change all your interfaces" is not going to make people happy | 15:31 |
| JayF | but that's an operational problem not an architectural one | 15:31 |
| TheJulia | ... There is a point where that is a reasonable thing to do | 15:31 |
| cardoe | We can make "direct" be an alias for "dynamic". | 15:31 |
| cardoe | And the existing direct becomes "agent" | 15:31 |
| JayF | I dislike that | 15:32 |
| cardoe | And then no change required of folks to get the functionality enabled. | 15:32 |
| TheJulia | I *suspect*, if we act quickly, it won't be a big deal | 15:32 |
| TheJulia | And by that meaning, the interfacing and patterning... as long as it lands around the same time, its not a big deal and folks can begin to adopt it | 15:33 |
| * dtantsur https://review.opendev.org/c/openstack/ironic/+/966761/comment/1cbc9c11_d65ed2bf/ | 15:33 | |
| TheJulia | sgtm | 15:36 |
| TheJulia | Are we good with RFE review? | 15:36 |
| * TheJulia hears the crickets | 15:36 | |
| TheJulia | #topic Open Discussion | 15:37 |
| * dtantsur enjoys the cricket sound | 15:37 | |
| dtantsur | Just as a heads-up: I'll have a bit of an odd availability in January because of a move | 15:38 |
| dtantsur | Don't get surprised if I take unusually long to respond or review something. Please bear with me for now. | 15:38 |
| janders | dtantsur good luck, hope it all goes smooth! | 15:38 |
| dtantsur | Thx! It's, as usual, quite a show :D | 15:38 |
| JayF | I will be out (up to) the last two weeks in Feburary for a medical thing, similarly will be unavailable. | 15:38 |
| TheJulia | dtantsur: I hope it all goes well! | 15:39 |
| janders | I have a couple topics. First - I had a brief chat to DMTF folks about multi-system-systems. | 15:39 |
| TheJulia | I have nothing really coming up so I should be around albeit likely very heads down on vxlan for the next month or two | 15:39 |
| TheJulia | janders: seems like the floor is yours | 15:39 |
| janders | Thank you TheJulia | 15:40 |
| janders | regarding DMTF discussion: short version: "Anything that isn't bootable isn't a system. A chassis can be used to group together components." | 15:40 |
| janders | so it would seem to me that as far as they are concerned, if a System doesn't have enough components to boot up a workable OS, that's not right | 15:40 |
| janders | so it seems we're not the only ones of an impression that the hardware that JayF mentioned is a bit weird - it's not just us Ironic'ers | 15:41 |
| dtantsur | We cannot do much about the already existing hardware but I wonder if they can spread this message somehow | 15:41 |
| dtantsur | to prevent more instances of this | 15:41 |
| JayF | janders: is that published somewhere? | 15:41 |
| JayF | janders: or hallway conversations? | 15:42 |
| TheJulia | Hmm, Interesting | 15:42 |
| JayF | I have to have something in writing I can toss at the vendor architects/presales | 15:42 |
| janders | JayF inconveniently, in DMTF-member-only repo | 15:42 |
| janders | but we can see what we can do (I can ask folks) | 15:42 |
| janders | but there is more | 15:42 |
| JayF | if you can email me details about it even if I don't have access, it may help | 15:42 |
| janders | long version: they shared some docs to look at composability, etc which we can look at together if you're interested JayF | 15:42 |
| JayF | I'm academically interested; I | 15:43 |
| TheJulia | I'd ask them for some way to close the loop since JayF can't access that repo without membership in the DMTF | 15:43 |
| janders | they further reinforce the "it needs to have enough kit to boot OS" line | 15:43 |
| JayF | **I'm not convinced it will wrap into value for my downstream | 15:43 |
| janders | I can certainly help gathering documentation to potentially share with the $vendor | 15:43 |
| dtantsur | If we can at least prevent this from becoming a new norm... | 15:43 |
| TheJulia | dtantsur: yeah | 15:43 |
| janders | agreed | 15:43 |
| janders | I can follow up in the thread | 15:44 |
| janders | everyone is welcome to participate in the discussion but unfortunately DMTF membership is required to see the issue I raised | 15:44 |
| TheJulia | So, one thing I'm wondering, as a devil's advocate... what if the device *is* booting it's own OS but its not user managable? I realize that is a bit blurring of the exact case JayF and some others have observed with some of the hardware out there | 15:44 |
| JayF | Yep. | 15:45 |
| TheJulia | And then... what if vendors view it that way and believe they are in compliance. | 15:45 |
| JayF | I think that's likely true for the hardware I'm talking about here | 15:45 |
| JayF | wow way to read between the lines TheJulia | 15:45 |
| JayF | I hadn't even put that all together | 15:45 |
| TheJulia | JayF: this is what working for lawyers for like... a third of my career has done to me. | 15:45 |
| dtantsur | "Everything with firmware is booting an OS" is quite a take.. | 15:45 |
| dtantsur | but yeah, I can see it being appealing | 15:45 |
| JayF | dtantsur: in some of this hardware, it's a real OS | 15:46 |
| JayF | dtantsur: think a DPU or a BMC which has an optionally operator-accessible OS | 15:46 |
| JayF | dtantsur: I know on this gear you can put the DPU into a operator-accessible OS mode | 15:46 |
| JayF | it's computers all the way down /o\ | 15:46 |
| JayF | and... shit | 15:46 |
| janders | LOL | 15:46 |
| dtantsur | I guess where the line could be drown is the question of self-sufficiency as a system | 15:46 |
| JayF | putting the computer in a mode where the DPU is NIC only | 15:46 |
| JayF | reduces the number of systems to 2 | 15:47 |
| JayF | this is EXACTLY what is happenin | 15:47 |
| TheJulia | yup, now without I2C for inter-device communications! | 15:47 |
| * TheJulia hides | 15:47 | |
| * dtantsur sighs | 15:47 | |
| * JayF nominates TheJulia to chair the DMTF, too | 15:47 | |
| janders | I think there are two action items here: 1) I will share the info I have with JayF and 2) update the thread with our concerns/questions | 15:47 |
| TheJulia | dtantsur: I think that is the most "ironic" response ever :) | 15:47 |
| dtantsur | lol | 15:47 |
| TheJulia | JayF: ouch! But if that is what the members want, who am I to stand in the way ?!? ;) | 15:48 |
| JayF | you can not only read lawyerspeak, you can use it!?!?! | 15:48 |
| JayF | AGREED this is dangerous ;) | 15:48 |
| janders | I see some opportunities here | 15:49 |
| dtantsur | If DMTF was chaired by people like TheJulia rather than just vendors.. okay, I shut up here | 15:49 |
| janders | dtantsur++ | 15:49 |
| TheJulia | lol | 15:50 |
| TheJulia | Y'all have made my day, thank you! | 15:50 |
| TheJulia | do we have anything else to discuss? Pending chaos, or crazy ideas? | 15:50 |
| janders | TheJulia in seriousness are you a DMTF member? | 15:50 |
| janders | if not, would you consider joining? | 15:50 |
| TheJulia | I am not, I guess I could, send me the link or page to the process | 15:51 |
| janders | will do | 15:51 |
| TheJulia | Thanks | 15:51 |
| JayF | These organizations need a hook-point for stakeholders like Ironic | 15:51 |
| * TheJulia might have looked at it ages ago but I really don't remember at this point | 15:51 | |
| JayF | one that doesn't require handing over of money or becoming members or whatnot | 15:51 |
| janders | OK: if nothing more on multi-system I would like to jump on the monitoring patch | 15:51 |
| JayF | It's unfortunate it's structured this way. | 15:51 |
| TheJulia | JayF: We pointed that out to them in the past and the answer was bascially "join the forum" | 15:51 |
| JayF | Most collaborations locked behind a user login is hostile to OSS | 15:52 |
| TheJulia | janders: have you made a parallel patch for the client and yet another by sdk ? | 15:52 |
| janders | I have a pair - API side and client side | 15:52 |
| TheJulia | JayF: I agree, and even getting issues really resolved, ala this exact issue | 15:52 |
| janders | https://review.opendev.org/c/openstack/ironic/+/966946 | 15:52 |
| janders | https://review.opendev.org/c/openstack/python-ironicclient/+/967055 | 15:52 |
| TheJulia | janders: openstacksdk as well | 15:53 |
| janders | TheJulia noted. What do I need to break out to or add to SDK? | 15:53 |
| janders | (my first change requiring client side work, hence asking) | 15:53 |
| TheJulia | janders: the api version and the field itself, AIUI | 15:55 |
| janders | TheJulia ACK | 15:55 |
| janders | will do | 15:55 |
| TheJulia | Anything else today? | 15:55 |
| janders | will I need to update the API/client patches again once that's done, or is SDK chenge self contained? | 15:55 |
| TheJulia | Somehow we managed to use virtually the whole hour. I'm sure people need to refill their coffee or switch to tea... or something stronger. | 15:56 |
| TheJulia | janders: it is elf contained | 15:56 |
| TheJulia | self | 15:56 |
| TheJulia | not, elf | 15:56 |
| janders | noted, thank you | 15:56 |
| TheJulia | no elfs are located in the sdk, as far as I'm aware. | 15:56 |
| janders | if cardoe and JayF have time I would appreciate re-reviews | 15:56 |
| janders | all comments should be addressed | 15:56 |
| janders | local tests pass, just waiting for CI | 15:56 |
| cardoe | will do | 15:57 |
| janders | client change has one +2 | 15:57 |
| janders | thank you! | 15:57 |
| janders | I appreciate your time folks | 15:57 |
| janders | that's all from me | 15:57 |
| dtantsur | Meanwhile, I think I like the idea of a "dynamic" RAID interface as the next step after the deploy one. Both of these will make Metal3's code somewhat less annoying. | 15:57 |
| TheJulia | Could be super useful | 16:00 |
| TheJulia | and I think this is generally the next/logical progression for easing the user experience | 16:00 |
| TheJulia | by removing, as JayF puts it, part of a decoder ring being necessary | 16:00 |
| JayF | we've been big on being explicit | 16:01 |
| JayF | but need to go back and add hooks -- like here -- where we can use metadata to store explicit decisions | 16:01 |
| JayF | like "use this image with bootc/ramdisk/anaconda" or "pick the fibrechanel interface if the network is turquoise" | 16:01 |
| TheJulia | or make the decisions to ease the use case/patterning | 16:02 |
| TheJulia | heh | 16:02 |
| TheJulia | Okay folks, we're moving to colors | 16:02 |
| TheJulia | There will be no green and purple bins in this channel ;) | 16:02 |
| TheJulia | Thanks everyone! Have a great week! | 16:02 |
| dtantsur | My favourite colors :( | 16:02 |
| TheJulia | #endmeeting | 16:02 |
| opendevmeet | Meeting ended Mon Jan 12 16:02:42 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-12-15.01.html | 16:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-12-15.01.txt | 16:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-01-12-15.01.log.html | 16:02 |
| janders | o/ | 16:02 |
| janders | thanks folks, great discussion, feels like we well made up for the skipped weeks | 16:02 |
| TheJulia | dtantsur: but, we can't emulate the Drazi from Babylon 5 | 16:03 |
| JayF | purple image, get purple deploy | 16:03 |
| JayF | green image, get green deploy | 16:03 |
| TheJulia | See: https://babylon5.fandom.com/wiki/The_Geometry_of_Shadows | 16:03 |
| JayF | now there are two deploy images | 16:03 |
| TheJulia | I guess that is fair... | 16:05 |
| *** darmach2 is now known as darmach | 17:09 | |
| JayF | \ | 18:04 |
| TheJulia | ???? | 18:08 |
| JayF | mistake | 18:09 |
| TheJulia | beep boop... whirrrrrl. | 18:25 |
| opendevreview | cid proposed openstack/ironic master: Support `disable_ramdisk` during servicing https://review.opendev.org/c/openstack/ironic/+/973016 | 21:33 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: DNM: Autodetect deploy interface (unedited from claude, seriously dont review) https://review.opendev.org/c/openstack/ironic/+/973187 | 21:48 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: DNM: Autodetect deploy interface (unedited from claude, seriously dont review) https://review.opendev.org/c/openstack/ironic/+/973187 | 23:22 |
| JayF | dtantsur: stevebaker[m]: TheJulia: There are a couple things I don't likke baout how https://review.opendev.org/c/openstack/ironic/+/973187 is shaped, but that's a rough PoC for a autodetect deploy_interface | 23:25 |
| JayF | I need to test it and to see if I can find a less-common path for the try;catch code | 23:25 |
| stevebaker[m] | JayF: I'm good with a dedicated autodetect deploy_interface if that is the consensus. Do we know enough now to move forward on the first review in that series? https://review.opendev.org/c/openstack/ironic/+/966760. I'd also be fine if JayF wants to do the dev work for autodetect. Likewise I can adapt my change in that direction, as long as we're not both working on it | 23:48 |
| JayF | stevebaker[m]: I just have been kiting along a claude session all day to help surface ideas; this isn't a strong investment from me other than just trying to present something to ensure the conversation continues. I'd really like us to get this behavior landed in G :) | 23:49 |
| JayF | I wouldn't have done this without getting a mutex with you if it wasn't a trivial time investment :D | 23:49 |
| JayF | stevebaker[m]: also if you haven't; you may want to read the associated discussion from the meeting this (pst)morning | 23:50 |
| stevebaker[m] | JayF: OK, I can spend some time on this from now and evolve my change towards some kind of autodetect. | 23:56 |
| JayF | feel free to use any or none of what I tossed together there | 23:57 |
| JayF | sometimes Claude thinks of things I wouldn't have (although the "just pass the instance_info modification method as a sidecar to the exceptoin" is all me) | 23:57 |
| JayF | that's one thing my case has that's a bit more pathological than yours: I'm going to have to modify instance_info to fit what ramdisk driver expects | 23:57 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!