| opendevreview | Michal Nasiadka proposed openstack/networking-generic-switch master: Switch batching from direct etcd3gw to tooz https://review.opendev.org/c/openstack/networking-generic-switch/+/988050 | 08:29 |
|---|---|---|
| *** zigo_ is now known as zigo | 08:57 | |
| *** dmellado4717259 is now known as dmellado471725 | 09:45 | |
| dtantsur | All jobs failing with "The specified regex doesn't match with anything" | 09:59 |
| opendevreview | Michal Nasiadka proposed openstack/networking-generic-switch master: Switch batching from direct etcd3gw to tooz https://review.opendev.org/c/openstack/networking-generic-switch/+/988050 | 11:27 |
| opendevreview | cid proposed openstack/ironic master: Fix healthcheck intercepting all API routes https://review.opendev.org/c/openstack/ironic/+/988102 | 12:36 |
| TheJulia | oh joy | 12:59 |
| frickler | look like that was only transient while tempest was preparing a new tag, should be green again with https://review.opendev.org/c/openstack/tempest/+/987912 merged | 13:04 |
| opendevreview | Mithun Krishnan Umesan proposed openstack/ironic master: Add TLS configuration to agent lookup response https://review.opendev.org/c/openstack/ironic/+/987887 | 13:37 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: create more specific update method for typing https://review.opendev.org/c/openstack/python-ironicclient/+/988106 | 13:49 |
| cardoe | JayF: is Karan done? | 13:50 |
| dtantsur | I can confirm that rechecking works | 13:55 |
| JayF | cardoe: he said to us in the MLH wrapup that he would finish it up in the next few days. That was weeks ago. | 14:00 |
| JayF | cardoe: sooooo... :| | 14:01 |
| TheJulia | :( | 14:01 |
| cardoe | okay I'll rebase the stuff | 14:01 |
| *** ykarel_ is now known as ykarel | 14:01 | |
| cardoe | I'd like to cut a release with the typing stuff in it and runbook v2 for testing purposes | 14:01 |
| cardoe | and use that as feedback for me creating some work items for some folks to do follow ups for the 2026.2 if that's okay? | 14:02 |
| JayF | cardoe: we underutilize the lever of "file a good issue and smoeone will fix it" :) | 14:06 |
| cardoe | Yeah I would agree with that. | 14:20 |
| * cardoe goes to google if there is a launchpad CLI. | 14:20 | |
| JayF | There is a pretty good LP API | 14:21 |
| JayF | I suggest vibe coding up a client | 14:21 |
| JayF | that has worked for me in the past, atleast for pulling R/O statistics | 14:21 |
| JayF | dunno how much of a pain the auth dance is | 14:21 |
| cardoe | I know their official CLI is some Python-like REPL which I hated. | 14:22 |
| cardoe | But vibe coding something is probably the best answer. | 14:22 |
| cardoe | That'll make it use it more. | 14:22 |
| cardoe | Cause I often write little markdown snippets of issues and what not and I can just pop those in. | 14:22 |
| TheJulia | speaking of launchpad, I randomly glanced at some of the really old items, and we're building up some "fixed committed" but not released items due to mismatch in repositories in the such. I've closed some out, but it would be good for us to overall give the older bugs a scrub. I also closed out some stuff that was just never going to move forward for drivers which have been removed and features since added | 14:22 |
| JayF | I suggest adding that as a task in the bug deputy doc | 14:23 |
| TheJulia | possibly, although we may be at a point where its beyond the scope of a bug deputy doing triage | 14:24 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Default TLS minimum version to 1.3 https://review.opendev.org/c/openstack/ironic/+/987953 | 14:47 |
| * TheJulia awaits delicious CI results | 14:48 | |
| opendevreview | cid proposed openstack/ironic master: Fix anaconda deploy on multitenant networks https://review.opendev.org/c/openstack/ironic/+/988125 | 14:52 |
| * cid Oh my god :D. did I just push a git log :man-facepalming: | 14:56 | |
| opendevreview | cid proposed openstack/ironic master: Fix anaconda deploy on multitenant networks https://review.opendev.org/c/openstack/ironic/+/988125 | 14:56 |
| JayF | cid: the best part is: I didn't even notice there was a bad patchset on that change. You outed yourself! :D | 14:58 |
| dtantsur | same, I could not resist looking :-P | 14:58 |
| cid | :D. I have enough shame to last me the rest of the week :D. God!!!!!! | 14:58 |
| JayF | I kid but honestly it's like a major "green flag" in tech, especially OSS communities and infrastructure stuff, to point at your own screw ups | 14:59 |
| JayF | nothing worse than root causing an issue to someone having screwed up and trying to quickfix/cover it up | 14:59 |
| TheJulia | heh | 15:00 |
| mumesan[m] | lol | 15:00 |
| TheJulia | I believe it is time. | 15:00 |
| JayF | apparently I volunteered | 15:01 |
| JayF | it me | 15:01 |
| JayF | #startmeeting ironic | 15:01 |
| opendevmeet | Meeting started Mon May 11 15:01:08 2026 UTC and is due to finish in 60 minutes. The chair is JayF. 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 |
| TheJulia | o/ | 15:01 |
| rpittau | o/ | 15:01 |
| JayF | It's a meeting! Hooray. As usual we operate under the OpenInfra Code of Conduct and the general attitude of "be kind, dudes" | 15:01 |
| TheJulia | JayF: I was about to go ahead and start the meeting :) | 15:01 |
| JayF | #topic Announcements/Reminders | 15:01 |
| JayF | #link https://tinyurl.com/ironic-weekly-prio-dash please review things hashtagged:ironic-week-prio -- to get your changes reviewed more quickly, hashtag them :) | 15:02 |
| dtantsur | o/ | 15:02 |
| JayF | #link https://releases.openstack.org/hibiscus/schedule.html It's R-20, do you know where your releases are? (It's OK, you don't need to know where they are, there are no deadlines) | 15:02 |
| JayF | I'm going to give until :05 for more folks to trickle in | 15:02 |
| TheJulia | Surely the release is tucked in it's bed for a nap! | 15:03 |
| clif | o/ | 15:03 |
| mumesan[m] | o/ | 15:03 |
| JayF | OK, starting things | 15:04 |
| JayF | #topic Working Group Updates | 15:04 |
| JayF | I pruned this list down in the agenda, it seems like maybe teh Async group is the only one still relevant to the Hibiscus cycle, yeah? | 15:05 |
| dtantsur | I hope it is :) | 15:05 |
| JayF | Anything to say about it? | 15:06 |
| dtantsur | For standalone networking, we're still working on the Metal3 side | 15:06 |
| dtantsur | No updates for asyncio, and I'll probably pass the lead to one of my colleagues | 15:06 |
| cid | o/ | 15:06 |
| JayF | Please feel free to edit the agenda if anyone wants to spin up any further working groups | 15:07 |
| TheJulia | Aside from async, I wonder if we'll want to treat deferred tasks similarly, but we actually need to begin to build momentum there. | 15:07 |
| JayF | we probably should have the nova/ironic group there at some point | 15:07 |
| TheJulia | ++ | 15:07 |
| JayF | but similarly to TheJulia we just need spare time to kickoff | 15:07 |
| TheJulia | yup | 15:07 |
| JayF | #topic Discussion Topics | 15:07 |
| JayF | We have quite a few CI issues comments here. | 15:07 |
| JayF | And a lot of topics in general. | 15:07 |
| TheJulia | So, I think the glance image issue is resolved at this point | 15:07 |
| JayF | I think 99% of the are TheJulia-adjacent? /me hands over the podiuym | 15:07 |
| TheJulia | lol | 15:07 |
| JayF | The AKI/ARI stuff was weird, re: the glance image CI breakage | 15:08 |
| JayF | but is a harsh reminder that it's a steep, steep price to embargo issues and work in quiet | 15:08 |
| TheJulia | So, there is an open question regarding the firefox PPA, I know steve has started work on trying to bring the graphical console testing job back into the running state. I know early last week, the launchpad PPA repo was unresponsive | 15:08 |
| JayF | which can lead to weird miscomms like what happened there | 15:08 |
| TheJulia | yup | 15:08 |
| JayF | TheJulia: I am generally concerned that such a job is, by it's nature, more likely to bitrot than most of our jobs... I wonder if it's reasonable to keep it nonvoting, experimental, periodic ... something to make it so it's not going to break the whole cloud if it breaks | 15:09 |
| TheJulia | Skipping the glance stuff which we discussed/retrospected on last week | 15:09 |
| TheJulia | So, looking at our non-voting jobs, non-voting basically leads directly to bitrot | 15:10 |
| TheJulia | over stupid stuff typically, but there is a point where we likely need to recognize we can't prefectly test everything | 15:10 |
| TheJulia | where that is, I don't know | 15:10 |
| JayF | I don't know how to solve this problem directly, but we have so many jobs, the matrix is so big, even a small % failure chance cascades | 15:10 |
| TheJulia | We likely need to have the human discussion of "what can be reasonably done" disjointed from the job voting level discussion | 15:11 |
| JayF | It makes it feel more sisyphean than usual to work on CI | 15:11 |
| TheJulia | Yeah, agreed | 15:11 |
| TheJulia | I haven't had a chance to look at what steve is doing exactly, cardoe did propose maybe doing a cached container image | 15:11 |
| TheJulia | but we also saw quay.io break last week | 15:11 |
| TheJulia | so... | 15:11 |
| TheJulia | dunno, as long as there is some aware and that we follow-up on the issues, we're likely in a better place | 15:12 |
| TheJulia | but yeah, things like graphical are also a bit of a longer tail. | 15:12 |
| TheJulia | Anyone have anything else to add before we move on ? | 15:12 |
| cardoe | it's just building a container each time and installing A LOT OF packages. Cause it's starting with a minimal ubuntu and installing firefox | 15:13 |
| cardoe | and X11 | 15:13 |
| TheJulia | each download is an opportunity for job failure | 15:13 |
| TheJulia | so, simplifying that would be for the best | 15:13 |
| dtantsur | Can we publish and reuse a base container? | 15:14 |
| JayF | yep, especially ones that don't use CI mirrors (I don't know if our container build does; but PPAs def. don't) | 15:14 |
| TheJulia | fwiw, it looks like the PPA mirror is back up, but it seems like we should just publish a container | 15:15 |
| TheJulia | or a base container | 15:15 |
| TheJulia | stevebaker[m]: fyi the consensus seems to be ^ | 15:15 |
| TheJulia | onward? | 15:15 |
| dtantsur | I'm pondering the same thing for metal3 jobs btw | 15:15 |
| dtantsur | building iPXE from source each time is annoying at best | 15:16 |
| dtantsur | yeah, onward, not going to diverge the conversation :) | 15:16 |
| TheJulia | it really wouldn't be a bad idea, although leveraging quay right now is why we had to take it out of voting at one point last week and then add it right back in | 15:16 |
| * dtantsur nods | 15:16 | |
| dtantsur | Quay is a pain in all parts of our team's bodies | 15:16 |
| TheJulia | Next topic: During the PTG or right after it we discussed software raid and one item which was raised was software raid testing is limited, which has me thinking if we should put an explicit feature flag around sofware raid | 15:17 |
| TheJulia | Specifically: limited testing upstream, limited ability to test it, you need to accept it might not work or you might be trying to do something it can't do | 15:18 |
| JayF | I think any of our features which could: 1) expose additional security surface and 2) already require significant operator setup to work should be treated that way | 15:19 |
| TheJulia | I mean, we could sink resources into testing it, but I think we're also heading into a state where distributions start backing off including modules because distros are more centered around end workstations with single devices and clouds, not servers with multiple devices and even then hardware raid is relatively inexpensive now | 15:19 |
| JayF | if they already have to do a bucketload of manual config, add "turn it on" to the list | 15:19 |
| TheJulia | So, anyone objecting to us adding a knob around software raid in general? | 15:19 |
| * TheJulia waits the customary minute | 15:20 | |
| TheJulia | Okay, I think we've agreed then... | 15:20 |
| TheJulia | Onward! | 15:20 |
| TheJulia | Next topic: A quick one for sure: We're retiring virutalpdu right? | 15:21 |
| * TheJulia hears crickets | 15:21 | |
| TheJulia | cid: I think you have a patch up but the repo still has some testing someplace? | 15:21 |
| cid | I do ! | 15:22 |
| TheJulia | I think it needs to be marked in the releases stuff that its being retired, but I haven't done a retirement in a very long time | 15:22 |
| cid | I think it's currently blocked by reivews, if I remember correctly. | 15:22 |
| TheJulia | oh, is there more than one ? because the one I found on the virtualpdu repo is blocked on tests | 15:22 |
| JayF | maybe worth spinning up an etherpad with the steps and where we're at | 15:22 |
| JayF | so that folks can intervene to get reviews if needed? | 15:23 |
| TheJulia | ++ | 15:23 |
| rpittau | should we announce that in the mailing list ? | 15:23 |
| JayF | just links to the outstanding stuff pending review, and the next steps once they land | 15:23 |
| TheJulia | we should! | 15:23 |
| cid | Following the project retirement guide, I think I am at a point where a liason will have to check off on the patch, then we get the retirement date to put on a follow on commit | 15:23 |
| JayF | !action cid to email list about virtualpdu retirement; create documentation around where things are and what is the next stsp | 15:23 |
| opendevmeet | JayF: Error: "action" is not a valid command. | 15:23 |
| TheJulia | heh, agreed ? | 15:24 |
| JayF | #action cid to email list about virtualpdu retirement; create documentation around where things are and what is the next step | 15:24 |
| TheJulia | heh | 15:24 |
| TheJulia | okay | 15:24 |
| TheJulia | Anything else on this topic? | 15:24 |
| cid | Not really | 15:24 |
| TheJulia | For our last topic on today's topic marathon, TLS versions! As some of you might be aware, I've been working on adding knobs for ciphers and tls versions, and I'm curious if folks have thoughts on just explicitly starting to default ironicy things to utilizing TLS 1.3 by default. Thoughts? | 15:25 |
| JayF | I don't mind that change; I do not want the PQC ciphers used by default. | 15:25 |
| TheJulia | Yeah, I'm not thinking of doing anything beyond asserting a default version at some point to 1.3 | 15:25 |
| cardoe | Is that for IPA or for everything like the BMCs? | 15:26 |
| JayF | There are many folks outside of US jurisdictions worried about the introduction of net-new crypto algorithms as part of the PQC push. | 15:26 |
| dtantsur | What's the scope? | 15:26 |
| cardoe | Cause afaik a lot of BMCs don't do 1.3 | 15:26 |
| dtantsur | Ironic<->IPA traffic - sure. Ironic<->BMC rather no | 15:26 |
| TheJulia | I presently have a change working its way thorugh CI which forces apache to 1.3, the downside in our model is we use apache and uwsgi (another item we should discuss at some point) front-ending it | 15:26 |
| TheJulia | So, I'm thinking for BMC access, we let it fall to system policy unless an operator wishes to configure it explicitly | 15:26 |
| dtantsur | apache - that's devstack-only, right? we cannot change how users configure the API? | 15:27 |
| TheJulia | but frontend API wise, default wise, IPA wise, all 1.3 by default and make operators dial it back | 15:27 |
| TheJulia | well, for those users, but we also have different launch models and controls all over the place | 15:27 |
| TheJulia | Alternatively, my set of changes are starting to lock everything to 1.2, but since 1.3 actually seems to "just work" in devstack (like, jobs have passed when I edited apache config via sed, maybe 1.3 is okay | 15:28 |
| TheJulia | again, bmcs themselves are out of that scope, only getting the knob, not a default | 15:29 |
| dtantsur | bifrost may also be an okay target, although it might share its TLS settings with its vmedia server.. | 15:29 |
| TheJulia | (in that that ecosystem moves way slower than OSes in general) | 15:29 |
| JayF | We need to make sure this is about as loud of an upgrade note as possible, since this may need infra changes on the operator side as well. | 15:29 |
| JayF | Even if we exclude BMCs | 15:29 |
| TheJulia | Yeah, there are already some loud notes in the release notes already in my patch series, I'd do a 1.3 change as a standalone change where I update defaults and unit tests | 15:30 |
| TheJulia | Seems like we're arriving at "reasonable" ? | 15:30 |
| TheJulia | Anyone seeking to object? | 15:30 |
| JayF | maybe email the list if you want more input? | 15:31 |
| JayF | Operators aren't usually at this meeting. | 15:31 |
| TheJulia | dtantsur: the tls enpoint for getting vmedia default artifacts is a super good callout, but also that endpoint is externally managed | 15:31 |
| TheJulia | yeah, I'll take that as an action item | 15:31 |
| TheJulia | Cool, I guess we can proceed onward! | 15:32 |
| * TheJulia returns the podium to the chair | 15:32 | |
| TheJulia | JayF: we can move on to bug deputy updates | 15:34 |
| JayF | #topic Bug Deputy Updates | 15:34 |
| * JayF hands chair to cid :D | 15:34 | |
| TheJulia | lol | 15:34 |
| JayF | There are 7 new public bugs listed. | 15:34 |
| cid | lol | 15:34 |
| cid | Yup | 15:34 |
| JayF | I'll note we had a security bug or two that went public as well that might not be in this list. | 15:34 |
| JayF | Anything worth specific note? The full list is in the agenda. | 15:35 |
| JayF | Looks like the RFEs are things previously discussed at the PTG? | 15:36 |
| cid | 7 new bugs and no new RFES... I went through the list this "morning" so my filter must have missed the security bugs | 15:36 |
| cid | I don't think there's anyting worthy of note. | 15:36 |
| JayF | well it's more that they aren't "new" | 15:36 |
| JayF | they come in private, ironic coresec triages them, and changes to public security if they are eligible | 15:37 |
| JayF | so basically coresec does bug triage part of this | 15:37 |
| cid | I understand there's a new action item to pay a little more attention to ancient bugs. | 15:37 |
| cid | ++ | 15:38 |
| JayF | Yeah, I think we just have bugs that stick in Fix Committed instead of Fix Released | 15:38 |
| JayF | just a task-thing to clean it up | 15:38 |
| cid | acknwoledge. | 15:39 |
| cid | handing the chair over to the chair | 15:39 |
| JayF | who wants to be the deputy next week? | 15:40 |
| JayF | Someone should give CID a break from it lol | 15:40 |
| cardoe | I'd sign up if I knew I wasn't gonna drop the ball. | 15:41 |
| JayF | I mean, make an effort, if you miss you miss | 15:41 |
| clif | I can do it I suppose | 15:41 |
| * JayF locks clif and cardoe in a cage match to see who ends up deputy | 15:42 | |
| cid | lol :D | 15:42 |
| * JayF puts down clif and moves on | 15:42 | |
| JayF | There is nothing for RFE Review. | 15:42 |
| JayF | #topic Open Discussion | 15:43 |
| JayF | Any items for discussion not previously added to the agenda? | 15:43 |
| TheJulia | lol | 15:43 |
| TheJulia | oh my | 15:43 |
| JayF | Also call for volunteers to chair the next meeting. | 15:43 |
| TheJulia | this meeting has brought a smile to my face | 15:43 |
| TheJulia | I can chair next week. | 15:43 |
| cardoe | I'll be out at the end of the month and the beginning of next. | 15:44 |
| TheJulia | glorius vacation? | 15:44 |
| cardoe | just as fyi | 15:44 |
| cardoe | yes | 15:44 |
| TheJulia | Nice! | 15:44 |
| JayF | #note cardoe to be unavailable end of May/early June | 15:45 |
| JayF | Last call for the meeting | 15:46 |
| JayF | Have a good week o/ | 15:47 |
| JayF | #endmeeting | 15:47 |
| opendevmeet | Meeting ended Mon May 11 15:47:39 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:47 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-05-11-15.01.html | 15:47 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-05-11-15.01.txt | 15:47 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-05-11-15.01.log.html | 15:47 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring `assignment` in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985238 | 15:49 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring call-arg in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985240 | 15:49 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring index in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985241 | 15:49 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring dict-item in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985242 | 15:49 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring func-returns-value in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985243 | 15:49 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: Stop ignoring list-item in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985245 | 15:49 |
| cardoe | ^ that rebases the parts of Karan's series that I think will pass and work | 15:49 |
| JayF | dtantsur: https://review.opendev.org/c/openstack/ossa/+/987764 please review, I'm going to announce this today | 15:50 |
| dtantsur | k | 15:56 |
| dtantsur | meanwhile, if anyone wants one fewer red non-voting job: https://review.opendev.org/c/openstack/ironic/+/987673 | 15:57 |
| JayF | thanks for that, wanted to make sure you were onboard before I landed it | 15:57 |
| *** tkajinam_ is now known as tkajinam | 16:03 | |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: switch to new tox constraints syntax https://review.opendev.org/c/openstack/python-ironicclient/+/988139 | 16:08 |
| cardoe | Once all this goes through, I'll dig into the merge conflicted parts. | 16:13 |
| TheJulia | post sent to mailing list regarding tls 1.3 | 16:41 |
| TheJulia | overall, looks like the jobs mostly work, going to attempt the negative test now | 16:41 |
| TheJulia | err, glad I double checked, didn't actually do it | 16:43 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Default TLS minimum version to 1.3 https://review.opendev.org/c/openstack/ironic/+/987953 | 16:45 |
| opendevreview | Mithun Krishnan Umesan proposed openstack/ironic-python-agent master: Apply TLS configuration from Ironic lookup response https://review.opendev.org/c/openstack/ironic-python-agent/+/988149 | 17:11 |
| opendevreview | Mithun Krishnan Umesan proposed openstack/ironic-python-agent master: Apply TLS configuration from Ironic lookup response https://review.opendev.org/c/openstack/ironic-python-agent/+/988150 | 17:14 |
| opendevreview | Merged openstack/ironic master: Repair the ironic-standalone-operator job https://review.opendev.org/c/openstack/ironic/+/987673 | 17:16 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Default TLS minimum version to 1.3 https://review.opendev.org/c/openstack/ironic/+/987953 | 18:09 |
| TheJulia | okay, if my changes are at least "sort of working", then that should explode horribly | 18:10 |
| TheJulia | well, it looks like tls version control knobs work | 18:49 |
| opendevreview | Mithun Krishnan Umesan proposed openstack/ironic-python-agent master: Apply TLS configuration from Ironic lookup response https://review.opendev.org/c/openstack/ironic-python-agent/+/988150 | 19:24 |
| JayF | I am reviewing a lot of patches now, and adding hashtags to a lot of them | 19:44 |
| JayF | might be worth taking a look thru the tagged patches in an hour or two when I get to the bottom, I've already added 2 or 3 | 19:45 |
| cardoe | JayF: so I got the 100 nodes per conductor during the PTG. | 19:50 |
| JayF | cardoe: please pull your -1, it's fixed now https://review.opendev.org/c/openstack/ironic/+/940572 | 19:53 |
| JayF | cardoe: I don't remember that conversation, but I've never ever heard a number that low for conductor scaling in the ~13 years I've been working on Ironic | 19:53 |
| cardoe | I'm happy to use a better value. | 19:54 |
| cardoe | But other than than I appreciate the feedback on the doc. I wanna make it better. | 19:54 |
| JayF | I'm thinking more 500:1 is a safe bet. I've personally seen places where that number was ... thousands:one | 19:54 |
| JayF | actually, a better concrete suggestion: | 19:54 |
| JayF | "Ironic conductor scaling needs can change drastically depending on the how you manage and provision nodes as well as how frequently you manage and provision nodes. Five hundred nodes per conductor, with extra capacity in case of failure, may be a good starting point if you don't have any data at all." | 19:55 |
| cardoe | I'm not trying to say these are the hard rules but just some examples of usage. | 19:55 |
| cardoe | That's good. I like it. | 19:56 |
| JayF | I think we just need to hit the two Ironic-centric modes of op (standalone/bifrost-shaped + openstack-but-no-nova shaped) and the two nova-centric modes of op (Ironic is an admin only api -- Nova is the only thing users us + node.lessee is set on provisioning so users get some visibility and self-service | 19:56 |
| JayF | ) | 19:56 |
| JayF | basically: Ironic, Ironic+OpenStack, Nova+OpenStack (hidden Ironic), Nova+Ironic+OpenStack (automated lessee) | 19:57 |
| TheJulia | wow, https://docs.openstack.org/python-ironicclient/latest/doc-python-ironicclient.pdf is interesting to find in google search | 20:02 |
| TheJulia | "openstack llc" | 20:02 |
| JayF | our docs pages have been very, very badly indexed in google recently | 20:02 |
| JayF | I think the AI stuff hurting our infra + the infra attempts to block AI have hurt us in the search space | 20:03 |
| JayF | and/or just it's a more personal example of how search engines are rapidly becoming useless | 20:03 |
| JayF | cardoe: https://review.opendev.org/c/openstack/python-ironicclient/+/985240/2 that's a real CI failure, sadly :( | 20:15 |
| cardoe | Yeah readying a fix but got squirreled into neutron | 20:15 |
| JayF | I am trying to catch up on review | 20:16 |
| JayF | I've been heads down in other stuff but pushing it all aside to catch up on this today | 20:16 |
| JayF | dtantsur: (IDK who else would care?) bugfix/34.0 appears to have busted CI generally https://review.opendev.org/c/openstack/ironic/+/987920 -- I don't consume this so I'm not worrying about it, but I noticed because I was gonna try and land the security fix | 20:23 |
| opendevreview | Jay Faulkner proposed openstack/ironic-python-agent stable/2026.1: Preserve ESP filesystem label during software RAID relocation https://review.opendev.org/c/openstack/ironic-python-agent/+/988174 | 20:25 |
| opendevreview | Merged openstack/python-ironicclient master: create more specific update method for typing https://review.opendev.org/c/openstack/python-ironicclient/+/988106 | 20:28 |
| opendevreview | Merged openstack/python-ironicclient master: Stop ignoring `assignment` in tests https://review.opendev.org/c/openstack/python-ironicclient/+/985238 | 20:28 |
| opendevreview | Merged openstack/networking-baremetal master: Clean up example local.conf https://review.opendev.org/c/openstack/networking-baremetal/+/988000 | 20:36 |
| opendevreview | Merged openstack/sushy stable/2026.1: filter out drives reporting null size on inspect https://review.opendev.org/c/openstack/sushy/+/987745 | 20:47 |
| opendevreview | Merged openstack/python-ironicclient master: switch to new tox constraints syntax https://review.opendev.org/c/openstack/python-ironicclient/+/988139 | 20:49 |
| opendevreview | Merged openstack/sushy-tools master: Add --storage-pool CLI option https://review.opendev.org/c/openstack/sushy-tools/+/987486 | 21:07 |
| opendevreview | Merged openstack/ironic-python-agent master: Preserve ESP filesystem label during software RAID relocation https://review.opendev.org/c/openstack/ironic-python-agent/+/986707 | 21:21 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: simplify is not None check https://review.opendev.org/c/openstack/python-ironicclient/+/988179 | 21:29 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: fix codespell config https://review.opendev.org/c/openstack/python-ironicclient/+/988180 | 21:29 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: remove unused script which does not pep8 https://review.opendev.org/c/openstack/python-ironicclient/+/988181 | 21:29 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: switch to using pre-commit for lint checks https://review.opendev.org/c/openstack/python-ironicclient/+/988182 | 21:29 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: remove separate codespell job https://review.opendev.org/c/openstack/python-ironicclient/+/988183 | 21:29 |
| opendevreview | Merged openstack/ironic master: Remove deprecated http_basic_* options https://review.opendev.org/c/openstack/ironic/+/986429 | 21:32 |
| opendevreview | Merged openstack/ironic master: Document software RAID image compatibility caveats https://review.opendev.org/c/openstack/ironic/+/986718 | 21:32 |
| opendevreview | Merged openstack/ironic master: Allow removing volume connectors on some states https://review.opendev.org/c/openstack/ironic/+/940572 | 21:32 |
| opendevreview | Merged openstack/ironic-tempest-plugin master: Reuse base tempest code for common config sections https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/987494 | 21:32 |
| cardoe | JayF: I switched us to pre-commit for python-ironicclient | 21:35 |
| opendevreview | Merged openstack/networking-generic-switch stable/2026.1: Add Dell OS10 bond trunk support https://review.opendev.org/c/openstack/networking-generic-switch/+/986063 | 21:40 |
| cardoe | I wonder what else we've got left. | 21:42 |
| opendevreview | Merged openstack/ironic master: fix: drop version from runbook traits v2 https://review.opendev.org/c/openstack/ironic/+/986806 | 21:45 |
| opendevreview | Merged openstack/ironic master: Clean up example local.conf https://review.opendev.org/c/openstack/ironic/+/988001 | 21:45 |
| opendevreview | Merged openstack/ironic master: Trivial: debug_tracebacks_in_api=True for unit tests https://review.opendev.org/c/openstack/ironic/+/987184 | 21:45 |
| opendevreview | Merged openstack/ironic master: Document provisioning a riscv machine https://review.opendev.org/c/openstack/ironic/+/987460 | 21:45 |
| opendevreview | Merged openstack/ironic master: Fix healthcheck intercepting all API routes https://review.opendev.org/c/openstack/ironic/+/988102 | 21:45 |
| opendevreview | Doug Goldstein proposed openstack/ironic stable/2026.1: Fix healthcheck intercepting all API routes https://review.opendev.org/c/openstack/ironic/+/988186 | 21:58 |
| opendevreview | Merged openstack/networking-generic-switch stable/2025.2: Add Dell OS10 bond trunk support https://review.opendev.org/c/openstack/networking-generic-switch/+/986064 | 22:00 |
| TheJulia | For deferred actions, and ultimately what would surface as bulk actions for users to find out the "what" is pending, I feel the need for a quick poll. | 22:02 |
| TheJulia | Option 1: /v1/jobs and /v1/nodes/<uuid>/jobs | 22:04 |
| TheJulia | Option 2: /v1/actions and /v1/nodes/<uuid>/actions | 22:04 |
| TheJulia | Option 3: /v1/todo and /v1/nodes/<uuid>/todo | 22:04 |
| TheJulia | or, deferred tasks | 22:04 |
| TheJulia | (we need to solidify on a name, kthxbai) | 22:04 |
| JayF | Did you see my comment about how it might be two separate things? | 22:09 |
| TheJulia | Also, how long would we want to keep the details for each, specifically do keep in mind that we really need to keep the table pruned down for efficient index operations | 22:09 |
| TheJulia | Sort of, and that was not how I read it on my first pass | 22:09 |
| TheJulia | I just posted my comments, but first I want us to try and get to consistency | 22:09 |
| JayF | I'm saying what's been proposed is like, very tightly coupled to nodes | 22:09 |
| JayF | and that gives it a certain amount of power, but limits it's generic usefulness for e.g. bulk actions | 22:10 |
| TheJulia | yeah, and I get that, and ultimately I think we have to with our model | 22:10 |
| TheJulia | so | 22:10 |
| JayF | so I'd say, just not make this generic. Just make it node actions, and have it be closely affiliated with a node | 22:10 |
| TheJulia | I wrote many words about this, maybe too quickly, but it boils down tot he follwoing in my mind | 22:10 |
| JayF | even if we need a /v1/whatever level endpoint, too, to roll them up for visibility | 22:10 |
| JayF | /v1/actions and "node actions" (/v1/nodes/{id}/actions) are the first implementation? something like that? | 22:10 |
| TheJulia | 1) we really need to try and front load the identification of nodes, and the creation of the records to fully track the state. Otherwise we're then trying to account for state in follow-up and possibly missing/skipping nodes. Or we're building an eventual consistency engine, but then those are long running tasks on each conductor because immedaitely, we have to split requests by conductor. | 22:11 |
| JayF | TheJulia: ^ this is what I was trying to nod to. Keep the limited "one node action" scope, and have it be the first of many things in a category | 22:11 |
| TheJulia | 2) If we look at where we're getting taxed, its single row inserts and and deletes in general | 22:12 |
| TheJulia | The delete problem, we know how to handle | 22:12 |
| JayF | and then [future milestone that doesn't have to be decided here] we maybe have a "Bulk Action" action type, which creates a bunch of node actions (or trickles them in "N" at a time) | 22:12 |
| opendevreview | Merged openstack/ironic master: Update packaging configuration https://review.opendev.org/c/openstack/ironic/+/987105 | 22:12 |
| TheJulia | The insert, if we try to hydrate python objects and all that, then we're inefficient, but if we bulk insert, we're pretty much drawing a direct line for a conductor to pickup and track the work | 22:12 |
| JayF | Yeah, I think we agree that the node-specific object, and thinking "one action at a time" and/or "linked list-style action chaining operating on one node" | 22:12 |
| JayF | is the path for now | 22:13 |
| TheJulia | Oh, okay, yeah | 22:13 |
| JayF | So /v1/actions (proposed) would have a rollup of all actions the caller can see | 22:13 |
| TheJulia | so, I was thinking that very first step could handle most of that | 22:13 |
| JayF | which today is Node Actions | 22:13 |
| JayF | and after Bulk Node Updates, might also be "Bulk Actions" or something else, that's similarly shaped but not exact | 22:13 |
| JayF | like imagine /v1/actions has a type and an id with linking, in the response, to the fully hydrated /v1/nodes/id/actions/id | 22:14 |
| TheJulia | I think the cleanest way to handle it is sort of keep it the exact same under the hood, but to model the breakup of the work to be hyper efficient on a bulk insert | 22:14 |
| JayF | So I have a cluster with 100k nodes. | 22:14 |
| * TheJulia spittakes | 22:14 | |
| TheJulia | okay | 22:14 |
| JayF | You want me to call bulk actions and have us sync insert 100k lines into node actions | 22:14 |
| * TheJulia goes for the booze | 22:14 | |
| JayF | TheJulia: I don't have this today, but a former employer did, and had a use case for this API | 22:15 |
| TheJulia | oh | 22:15 |
| TheJulia | okay | 22:15 |
| TheJulia | yeah, so | 22:15 |
| JayF | that's why I'm saying I am completely unwilling to say "do just in time node action submission one by one" | 22:15 |
| JayF | because it's adding a scaling cap to something that's inherently built for people at the edges of scaling | 22:15 |
| TheJulia | to permit for locking, it would likely need to be chunked under the hood, so the api has to "accept it" and send it off to a conductor to be a long lived item | 22:15 |
| JayF | a call to update all nodes' deploy_interface to autocorrect, for instance | 22:15 |
| JayF | yeah, which means we need a way to track that async task :) | 22:15 |
| TheJulia | its first thing is to "get that list enumerated | 22:15 |
| TheJulia | and from then, conductors could pick it up | 22:16 |
| JayF | "Hey, how many of those 100k nodes in my cluster have been updated?" can't be asked of the current API shape | 22:16 |
| JayF | or even "Hey, did you get any errors trying to submit 100k node actions?" | 22:16 |
| TheJulia | ideally, chunk into 250-500 so we don't entirely flood the cluster, but we keep conductors buys | 22:16 |
| TheJulia | busy | 22:16 |
| JayF | exactly, but we'd need a meta-object to track that | 22:16 |
| JayF | one that I don't think we create today | 22:16 |
| TheJulia | Yeah, so I can only see that as viable as down to the individual node level | 22:17 |
| JayF | but the need for which suggests not all actions will be "single node action" shaped | 22:17 |
| TheJulia | so, okay | 22:17 |
| TheJulia | so basically we've been talking the same thing, just using different words | 22:17 |
| JayF | that's why I'm saying, punt anything/everything not aligned to 1 node/1 action, if we need a root-level rollup api, design it in a way that it can be used for other action types, too | 22:17 |
| TheJulia | Yeah, that is why I wanted the parent request to be identifable/trackable | 22:17 |
| TheJulia | The "done" is more than anything, getting the work enumerated" | 22:18 |
| JayF | yeah, so I'm thinking of this as like | 22:18 |
| TheJulia | "getting he work enumerated" | 22:18 |
| JayF | /v1/nodes/[id]/actions/[id] is primarily there to kill sleep() | 22:18 |
| JayF | handle those cases today which are long running and ugly in threaded ironic | 22:18 |
| TheJulia | so | 22:18 |
| JayF | ideally we would JUST implement that much now, to limit scope | 22:18 |
| JayF | and not try to do a GET list(all pending node actions) | 22:19 |
| TheJulia | I can't think of it as enitrely separate views of the same table structure | 22:19 |
| JayF | there's a reason I keep saying the root level API would be a rollup: do we require a 1:1 mapping of /v1/endpoint to EndpointObject? | 22:19 |
| TheJulia | Granted, if you ask for actions upon a node, you'll always get a very short list | 22:19 |
| TheJulia | and that is different user oriented filtering | 22:19 |
| JayF | so like I'm saying if we can today: implement /v1/nodes[id]/actions (list of all actions FOR THAT NODE), and /v1/nodes/[id]/actions/[id] (detailed action) | 22:19 |
| JayF | COMPLETELY PUNT /v1/actions (or whatever we want to call it) | 22:20 |
| TheJulia | so | 22:20 |
| TheJulia | no | 22:20 |
| JayF | and try to limit scope to sleep()ytime cases | 22:20 |
| TheJulia | okay | 22:20 |
| TheJulia | How long do you expect entries to exist for a node? | 22:20 |
| JayF | $runtime_of_action, once it's done it'd be promoted to a node history item | 22:20 |
| TheJulia | And operationally, if you need to know what is going on will you look at individual nodes and state, or the rollup endpoint? | 22:20 |
| TheJulia | because surely your not going to do 50-100k node gets to find out something today | 22:21 |
| JayF | operationally, we're exposing data about operation we don't expose today | 22:21 |
| JayF | so I don't feel a strong responsibility to give rollup visibility | 22:21 |
| JayF | especially if a failed node task leads to a last_error population and fail out as it does today | 22:21 |
| TheJulia | I feel stuck between many strong asks and arguments | 22:21 |
| JayF | we're taking data currently only in logs and putting it into an API endpoint | 22:21 |
| TheJulia | and truthfully a clean view makes a lot of sense to me | 22:21 |
| JayF | even if we don't have the cross-cutting view of it | 22:21 |
| TheJulia | a distributed view shifts responsibility | 22:22 |
| TheJulia | and burden | 22:22 |
| JayF | be clear: what is a distributed view? | 22:22 |
| JayF | I could see that being used to describe both methods of operation | 22:22 |
| TheJulia | the node level "get pending actions for this node" | 22:22 |
| JayF | I don't have a strong feel for needing that, fwiw | 22:22 |
| JayF | if we just wanted actions-by-id on the node I'd be OK | 22:22 |
| TheJulia | honestly, I even question if that is usable | 22:22 |
| TheJulia | because your doing a point in time quick get, and that entry is likely to be gone by the time you look again | 22:23 |
| TheJulia | and if your doing a bunch of stuff, you'll want to see the aggregate/clean view of everything | 22:23 |
| JayF | yeah, so just do /v1/nodes/[id]/actions/[id] | 22:23 |
| JayF | that is an antipattern IMO | 22:23 |
| JayF | and goes against the idea of scaling up | 22:23 |
| TheJulia | no, because you'll never have the id to even ask it for more info | 22:23 |
| TheJulia | The idea is get rid of sleeps, but also to be able to queue up the needful | 22:23 |
| JayF | because you should be able to trust Ironic to raise the errors if/when they happen | 22:24 |
| JayF | I see providing a dashboard-ready action GET endpoint as basically directing operators to do things that are bad ideas, generally | 22:24 |
| TheJulia | so, if an action takes <30 seconds to trigger and its gotten to, it is on a quick path to disappearing in general | 22:24 |
| TheJulia | so there is no time to go ask for more data | 22:24 |
| JayF | the more I think about this the more I dislike the ability to get an aggregate list of pending actions, on or across nodes | 22:24 |
| JayF | simply because it's information paralysis: it's not useful info to operators | 22:24 |
| JayF | This is essentially what was an INFO log a year or two ago being promoted to /v1/stress-over-me | 22:25 |
| TheJulia | can you elaborate on informational paralysis in this context | 22:25 |
| JayF | This is essentially what was an INFO log a year or two ago being promoted to /v1/stress-over-me <--- this is EXACTLY what I mean | 22:25 |
| TheJulia | specifically, what you see as valuable for operators to know | 22:25 |
| TheJulia | and in the time window they may care | 22:25 |
| JayF | I see it as valuable *to not tell operators what they don't need to konw* almost moreso than telling them what they need to know | 22:26 |
| JayF | I think operators need to know very little about node actions as proposed when they successfully complete | 22:26 |
| JayF | when they error, they need the info they get already today via node history/logs/last_error | 22:27 |
| TheJulia | so, we're going to need to have a way to peer into this data set regardless to troubleshoot | 22:27 |
| TheJulia | but maybe thats like a non-api endpoint thing | 22:27 |
| TheJulia | and maybe its just all aggreated | 22:27 |
| JayF | if there's value in the info, it's only in an aggregate way, e.g. "how busy is conductor (group?) X" | 22:27 |
| JayF | So I flip the question: in the case of a non-failing node action, what info would *you* think an operator needs? | 22:27 |
| TheJulia | So, taking a step back to bulk node actions, how do you tell the user their node was covered, or do we just not provide that level of insight? | 22:27 |
| JayF | This is what resolves to [null set] for me everytime | 22:28 |
| JayF | TheJulia: part of my proposal is saying "don't build the API shape for that yet" | 22:28 |
| TheJulia | Thats a super good point, "I have x queued items at this time, I'm launching y" | 22:28 |
| JayF | When we later do bulk actions, we'd have the freedom to implement some kinda meta-action | 22:29 |
| JayF | which would likely just have stuff like: action to perform, nodes to operate on [list of nodes], nodes completed [list of nodes] or similar, and we'd just batch them in groups of "N" into node actions | 22:29 |
| JayF | ^^ + nodes_that_errored | 22:29 |
| TheJulia | well, I have serious concerns on "meta actions" in general, unless the action itself is the enumeation of the work | 22:30 |
| JayF | that would be the action :) | 22:30 |
| TheJulia | okay | 22:30 |
| JayF | enumerating the work and batching it into the conductor | 22:30 |
| TheJulia | okay, so, if folks agree we don't put an API in, again, since we've gone back and forth on this a few times | 22:30 |
| TheJulia | we can deal with that later | 22:30 |
| JayF | TheJulia: I am too being careful to not accidentally reimplement celery-over-ironic | 22:30 |
| TheJulia | or not at all | 22:30 |
| TheJulia | and just try to keep the under the hood data to metrics/coutners | 22:30 |
| TheJulia | that get logged/surfaced for ops metrics side folks | 22:31 |
| JayF | I like the idea of fetching action by ID for the future case, but I can't think of a use case for it now | 22:31 |
| JayF | assuming -- as I mentioned before -- any failures end up in node history | 22:31 |
| TheJulia | in the model I'm thinking, the historical id will rapidly become worhtless because the data will be gonezo. | 22:31 |
| JayF | and unless we soft deleted, like you said, it'd just be a "flappy" API in terms of things being visible/invisible quickly | 22:31 |
| TheJulia | I'd prefer we don't try to soft delete unless we're actively purging the data | 22:32 |
| JayF | only real time I'd GET /v1/nodes/blah/actions/lol would be to troubleshoot why lol is taking a long time that's not yet timeout-long | 22:32 |
| TheJulia | I've been burned by "soft delete" modeling in the past and it took me 3 months to get out of that nightmare | 22:32 |
| JayF | which is ... not a pattern I want our operators to think about | 22:32 |
| JayF | TheJulia: yep, and our existing node history periodic is a piece of code that makes almost every operator I've seen WTF when they realize it | 22:32 |
| JayF | lol | 22:32 |
| TheJulia | same, I really don't want node level listing of pending work which may be gone in moments | 22:32 |
| TheJulia | JayF: because I got horribly burned once in the past | 22:33 |
| JayF | yeah, I think we agree on no API now, at least for single-node-action based stuff | 22:33 |
| JayF | there's no case for it that's not better suited for node history or logs | 22:34 |
| TheJulia | Like I called a friend of mine who works on some of the largest databases in existence, and discussed the nightmare I had | 22:34 |
| JayF | since to have a node actions API that makes sense, we have to tackle soft deletes, and I don't want that and it hasn't even hurt me in the past lol | 22:34 |
| JayF | It's weird; my operator instincts say I want the API. I want the visibility -- but my developer instincts know I'm just going to be enticing an operator to drill down into red herrings | 22:35 |
| TheJulia | well, we either do soft deletes and still purge it programatically, or we hard delete as we go, or we hard delete after some amount of time has passed | 22:35 |
| TheJulia | yeah, exactly | 22:35 |
| TheJulia | under no circumstances, do I think its right just to soft delete and punt the problem to operators to "clean up your tables" | 22:35 |
| TheJulia | espescially since them doing that will take down ironic. | 22:36 |
| TheJulia | since large delete locks block inserts. | 22:36 |
| TheJulia | which is why history is written the way it is | 22:36 |
| JayF | I was about to say "of course", but I assume if you're saying that it means... | 22:36 |
| TheJulia | ? | 22:36 |
| JayF | > under no circumstances, do I think its right just to soft delete and punt the problem to operators to "clean up your tables" | 22:37 |
| JayF | ^ of course | 22:37 |
| JayF | but you wouldn't have said that if someone thought it was OK, I suspect lol | 22:37 |
| JayF | **unless someone thought it was OK | 22:37 |
| JayF | egad | 22:37 |
| TheJulia | so plus side of this discussion: we're passionate and want it to move forward | 22:37 |
| TheJulia | I'm okay if we soft delete it, but we're going to need a periodic to sit there just like node history and keep that thing pruned | 22:38 |
| TheJulia | and we're likely going to have to keep the batch size down to a smallish limit | 22:38 |
| TheJulia | We'd have to do the math to figure out the right parameters | 22:38 |
| JayF | I'm OK with no API, I'm ok with soft deletes and rollup at the node level and get-by-id (TTL of what, an hour or three after it finishes with a max of "N" actions total?) | 22:39 |
| JayF | I'd strongly prefer we avoid a meta-rollup api (e.g. get all actions vs ^ get all actions for node X) | 22:39 |
| TheJulia | So I was thinkinging the done actions should stick around for no more than like minutes, not hours | 22:40 |
| JayF | just because I'd prefer to figure out the shape of that as we're designing bulk node updates | 22:40 |
| JayF | I was thinking an hour and added the or three to be safe lol | 22:40 |
| JayF | so we're closer to aligned than not | 22:40 |
| TheJulia | okay | 22:41 |
| JayF | I guess in busy clouds, 15 minutes vs 1 hour could be an appreciable amount of data | 22:41 |
| TheJulia | yeah | 22:41 |
| TheJulia | and depends on how much churn as well | 22:41 |
| TheJulia | we'd need to do some math | 22:41 |
| JayF | going back to my "an endpoint to help us be more efficient needs to be very scalable" | 22:41 |
| JayF | I'd almost just say, phase 1: no API | 22:41 |
| JayF | if we wanna add an API later, great | 22:41 |
| JayF | or if people demand it | 22:41 |
| TheJulia | well, the take I got from the PTG was that we absolutely needed a roll-up/aggregate view endpoint | 22:42 |
| TheJulia | but I don't remember "why" exactly | 22:42 |
| JayF | for the bulk node stuff, I think | 22:42 |
| TheJulia | dtantsur: if you happen to remember, ^ | 22:42 |
| JayF | at least that's the use case I was pushing it for | 22:42 |
| TheJulia | eh, if that was the only reason, we could punt on it | 22:42 |
| JayF | but I realized we need more bite-sized chunks | 22:42 |
| JayF | PTG puts me in big-think mode | 22:42 |
| TheJulia | of course | 22:43 |
| TheJulia | :) | 22:43 |
| TheJulia | cardoe: you too, if you have opinions, chime on in ^ | 22:43 |
| JayF | I suggest putting a link to eavesdrop starting at the beginning of this chat in the gerrit lol | 22:43 |
| TheJulia | lol | 22:43 |
| JayF | I don't think we started out agreeing but we got there, the whys were what drove us there | 22:43 |
| JayF | we need to only do the stuff with a good, justifying why | 22:44 |
| TheJulia | oh yeah, and truthfully talking through it, we were already pretty closely aligned | 22:44 |
| TheJulia | just using different words/meanings | 22:44 |
| cardoe | oh dear... here I was making dinner | 22:44 |
| TheJulia | DOOOOooooommmmm of IRC | 22:44 |
| JayF | this is all logged, leave us alone and disable notifications when you're not working | 22:44 |
| TheJulia | yes, go finish dinner | 22:44 |
| JayF | life >>>>>>>>>>>>>>>>> ironic | 22:44 |
| TheJulia | Speaking of, I need to go begin a sauce in a little bit | 22:45 |
| JayF | for instance, touch sand sometime :D https://usercontent.irccloud-cdn.com/file/lXEcAQ7V/life.png | 22:45 |
| TheJulia | I have sand outside... except it is dry and hot | 22:47 |
| TheJulia | I'll trade you sand! | 22:47 |
| TheJulia | with the most dangerous substance known to mankind mixed in | 22:47 |
| JayF | ants? | 22:47 |
| TheJulia | Water! | 22:47 |
| TheJulia | oh, wait, we have ants here | 22:47 |
| TheJulia | do you not have ants? | 22:47 |
| JayF | I didn't see em at Ocean Shores lol | 22:48 |
| JayF | day tripped to the beach yesterday morning, just spent half the day driving and being near the ocean | 22:48 |
| JayF | you don't realize how much you need something like that until you do it | 22:48 |
| TheJulia | ... many years ago I woke up around liek 2:30 AM | 22:48 |
| TheJulia | And decided "I'm going to drive up the mountains and photograph the sunrise" | 22:49 |
| TheJulia | and did it | 22:49 |
| TheJulia | and it was such a refreshing experience | 22:49 |
| JayF | I wake up many mornings, weekend or weekday, like 5am +-30minutes, and I just decided that on Sunday I was gonna wake up and GTFO. Got to roadtrip my truck for the first time (and drive it on the sand! It's apparently allowed and is very normal in WA). | 22:49 |
| JayF | "EV roadtrip" was not scary. The rivian charger worked, and the only hiccup was that mother's day was not the right day to eat at the Denny's across the street (it's okay, I was saved by Wendy and her baconator) | 22:50 |
| TheJulia | heh | 22:50 |
| TheJulia | cool cool | 22:50 |
| JayF | you are old hand at the EV stuff, it's still new to me | 22:51 |
| TheJulia | Okay, I think my brain is reaching "GO MAKE PASTA SAUCE" | 22:51 |
| JayF | I mean, I'm reaching "just tell old man stories" phase, and it's like 9 minutes until my EOD | 22:51 |
| JayF | so same :D | 22:51 |
| cardoe | https://review.opendev.org/c/openstack/python-ironicclient/+/988183 that series switches the client to pre-commit and makes codespell enforcing | 22:51 |
| TheJulia | cardoe: dinner > ironic | 22:52 |
| cardoe | I’ll have to get caught up. You guys talked a lot. | 23:13 |
| TheJulia | passion! | 23:34 |
| opendevreview | Merged openstack/ironic stable/2026.1: Fix pickle error when oslo.service uses spawn mode https://review.opendev.org/c/openstack/ironic/+/987550 | 23:48 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
