15:00:07 <rpittau> #startmeeting ironic
15:00:08 <opendevmeet> Meeting started Mon Nov 27 15:00:07 2023 UTC and is due to finish in 60 minutes.  The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <opendevmeet> The meeting name has been set to 'ironic'
15:00:10 <TheJulia> o/
15:00:35 <rpittau> Welcome to our weekly meeting!
15:00:35 <rpittau> The meeting agenda can be found here:
15:00:35 <rpittau> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:06 <iurygregory> o/
15:01:11 <masghar> o/
15:01:16 <kubajj> o/
15:02:04 <rpittau> #topic Announcements / Reminders
15:02:08 <JayF> o/
15:02:38 <rpittau> we have only the usual reminder to review the patches tagged as priority on our board https://tinyurl.com/ironic-weekly-prio-dash
15:03:21 <rpittau> anyone has other announcements / reminders ?
15:03:49 <dtantsur> Release time soon?
15:04:01 <rpittau> oh yeah, I put that topic later :)
15:04:15 <rpittau> but I guess I can say it here
15:04:25 <rpittau> the new bugfix branches proposals are up
15:04:49 <rpittau> https://review.opendev.org/c/openstack/releases/+/901957
15:04:49 <rpittau> https://review.opendev.org/c/openstack/releases/+/901956
15:04:49 <rpittau> https://review.opendev.org/c/openstack/releases/+/901955
15:06:06 <rpittau> anything else to announce or remind ?
15:06:35 <JayF> There is a call on the list
15:06:42 <JayF> for projects for a UNM class
15:07:04 <rpittau> mm haven't seen it
15:07:05 <JayF> If we have Ironic-related items, it wouldn't hurt for one of us to put up a proposal -- I think last time something like this came up, we proposed ARM CI (basically ARM VM support for sushy-tools)
15:07:21 <JayF> deadline is this week, so if someone wants to action that it has to be nowish
15:07:33 <rpittau> JayF: do you have the permalink to the thread ?
15:08:08 * JayF stalls for time
15:08:18 <rpittau> we can add it later, it's ok :)
15:08:54 <rpittau> thanks for mentioning that!
15:08:54 <dtantsur> We have a lot of work items that could be taken
15:08:56 <dtantsur> e.g. Mahnoor and myself could use some help with the inspector merger
15:09:08 <dtantsur> (we're dragged into other downstream priorities)
15:09:46 <masghar> ++
15:10:40 <rpittau> the deadline is quite close
15:11:05 <dtantsur> yeah, and I probably won't be able to mentor anyone in the near future...
15:11:30 <JayF> I can't find the link; and search on ML archives appears brokenish(?)
15:11:39 <JayF> But I don't have time to mentor either; so it may be a moot point anyway
15:12:44 <rpittau> ok, let's see how the start of the week goes and think about it, if we can make time for some mentoring
15:12:44 <rpittau> it's a shame otherwise but we're all quite busy with downstream stuff in the near future
15:13:24 <JayF> I honestly spent a large portion of my last 2-3 months on softer stuff like governance and mentorship and need to point more time at technical focuses for productivity and personal sanity :)
15:13:28 <dtantsur> Mentorship are no longer popular among companies, at seems..
15:13:38 <dtantsur> except for maybe JayF :D
15:13:49 <JayF> Well, I've run myself past-empty trying to fill in the gaps, I can't do that anymore.
15:13:58 <rpittau> :)
15:13:58 <rpittau> shall we move on?
15:14:02 <JayF> ++
15:14:13 <rpittau> #topic Review action items from previous meeting
15:14:28 <rpittau> I have an action item from last time
15:14:36 <rpittau> change the launchpad ownership for virtualpdu to
15:14:36 <rpittau> us
15:14:42 <rpittau> it was done
15:15:05 <rpittau> iurygregory: how was your week as bug deputy ? :)
15:15:29 <iurygregory> hey o/
15:15:45 <iurygregory> status from the bug deputy week
15:15:50 <iurygregory> Ironic: 169 bugs (-20) + 182 wishlist items (-7). 20 new (-9), 77 in progress (-19), 3 critical , 26 high (+3) and 13 incomplete
15:16:21 <rpittau> any bug that needs immediate action/attention ?
15:16:25 <iurygregory> I was able to triage a few bugs, the unassigned In Progress is empty now \o/
15:16:36 <rpittau> great :)
15:16:43 <iurygregory> and I've clean up some old In Progress Bugs
15:17:13 <iurygregory> we have 3 critical bugs
15:17:37 <iurygregory> 2 were created this year, so we should try to look at them to see what we can do I would say
15:17:50 <iurygregory> #link https://bugs.launchpad.net/ironic/+bug/2026757
15:17:59 <iurygregory> #link https://bugs.launchpad.net/ironic-python-agent-builder/+bug/2043112
15:18:12 <rpittau> thanks!
15:18:34 <rpittau> TheJulia: you're still up for bug deputy this week ?
15:18:46 <iurygregory> While working as bug deputy I think it would be good to have some sort of guide on the procedure we should take for old bugs specially
15:18:47 <TheJulia> yeah, I'll give it a shot, but I won't be around on monday to report
15:19:09 <rpittau> #action TheJulia is the bug deputy this week
15:19:24 <rpittau> iurygregory: probably worth adding something to the bug deputy docs
15:19:27 <TheJulia> my focus is likely going to be really old bugs which should have long been closed out
15:19:36 <iurygregory> rpittau, yeah
15:19:47 <rpittau> thanks TheJulia :)
15:21:10 <rpittau> alright, let's move on if there's nothing more on bugs
15:21:48 <rpittau> #topic Caracal release schedule
15:21:54 <rpittau> #link https://releases.openstack.org/caracal/schedule.html
15:22:14 <rpittau> caracal milestone 2 is January 11th
15:22:22 <rpittau> in 1 month and a half
15:22:54 <rpittau> #topic Review Ironic CI status & update whiteboard if needed
15:23:23 <rpittau> CI is particularly silent recently, should we worry? :)
15:23:39 <TheJulia> seems to be working at the moment :)
15:23:45 <rpittau> good :)
15:24:13 <rpittau> #topic Bug Deputy role proposal has merged
15:24:22 <rpittau> it's official now! :)
15:25:26 <rpittau> I've spoke already about the bugfix branches, and I don't see new RFEs to discuss
15:25:36 <rpittau> #topic Open Discussion
15:25:48 <rpittau> anything up to discuss?
15:25:49 <dtantsur> I did have an RFE to discuss, but I forgot to add it :D
15:26:01 <rpittau> oh!
15:26:10 <dtantsur> if you have any time
15:26:17 <rpittau> I think so :)
15:26:20 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/2044561 Dynamic boot configuration API
15:27:03 <dtantsur> TheJulia: you commented on ^^^
15:27:27 <dtantsur> Actually, making it not tied to iPXE was one of the design goals
15:27:32 <TheJulia> Yes, I guess I have two thoughts. I'd love for it to be generic upfront, instead of there being an ipxe flavor explicitly tied to parameters
15:27:40 <dtantsur> I'm using iPXE as the reference implementation because I don't know anything else
15:27:48 <TheJulia> I also kind of wonder if it needs a spec (sorry!)
15:28:04 <dtantsur> Possibly, except that it risks ending up one of my many unfinished items
15:28:10 <TheJulia> ahh, okay, luckily the vast majority of the code under the hood is used by both ipxe/pxe
15:28:32 <JayF> That needs a spec IMO as well.
15:28:37 <TheJulia> the base challenge is that anytime we built explicit logic around one, we've made the underlying code more and more complicated too :\
15:28:47 <TheJulia> not insurmountable by any means, some cleanup is needed there too
15:29:12 <TheJulia> but existing pxe parameters have kind of been lingering, so I'd personally try to avoid using ipxe in the name, I guess
15:29:15 <dtantsur> I can draft a quick spec if that's actually something of interest
15:29:36 <dtantsur> The question is "it needs a spec" means "we want to discuss details" or more of "Dmitry, please go away with your crazy ideas" :D
15:29:47 * dtantsur is ready to accept the latter
15:30:15 <JayF> Mine is more
15:30:17 <TheJulia> I could see it being a stepping stone to helping avoid the shared cluster conductor case
15:30:31 <JayF> "oh god lets not encode ipxe implementation details in to an Ironic API definition without having at least a ?mode=ipxe"
15:30:36 <JayF> but I love the idea :)
15:30:44 <dtantsur> Hold on, where is this assumption coming from?
15:30:46 <TheJulia> I guess the internal thing I'm wondering, where do we store the information to give it the correct up to date information
15:31:04 <JayF> I guess if the filename is boot.ipxe, that is telling us it's an ipxe file, eh
15:31:18 <TheJulia> grub will hunt for grub.cfg first
15:31:23 <TheJulia> but you only get one bounce with that too...
15:31:25 <dtantsur> grub with the ipxe boot interface?
15:31:33 <TheJulia> so... maybe explicitly out of the box might not work, dunno
15:31:43 <TheJulia> dtantsur: grub with boot_interface set to pxe
15:31:55 <dtantsur> ipxe will expect boot.ipxe, grub will expect grub.cfg I guess
15:32:03 <dtantsur> the file name is just a hint to the boot interface
15:32:14 <TheJulia> yup
15:32:15 <dtantsur> so that we don't corner itself with an inability to support more than one file per interface
15:32:40 <TheJulia> I'm *not* entirely sure it would completely work with grub, I'd have to go look at the code to see how many times it lets you chain
15:32:49 <dtantsur> so yeah, tl;dr: I did not expect the generic parts to have any references to iPXE
15:32:53 <TheJulia> ipxe is much more flexible in that regard
15:33:03 <TheJulia> cool
15:33:08 <JayF> The other potential headache with something like this... we haven't hit this before, so probably YAGNI
15:33:15 <JayF> but what if ipxe syntax were to change?
15:33:27 <JayF> we need any concept of versioning for this?
15:33:29 <dtantsur> That affects us now as well, no?
15:33:33 <TheJulia> JayF: if it uses the same templates/config as the conductor...
15:33:38 <JayF> Hmm. I guess so.
15:33:44 <dtantsur> We already generate iPXE scripts
15:33:52 <dtantsur> so, I will write a spec if there are people who will read it :)
15:33:54 <JayF> Fair.
15:33:59 <JayF> This is API ergonomics for a thing we already do
15:34:04 <JayF> I need to stress less and just let it happen :)
15:34:07 <dtantsur> (keeping in mind that we're otherwise stuck with a single conductor in metal3)
15:34:13 <TheJulia> I'd honestly just use as much of the existing mechanims as possible, maybe generate the response on the fly if we can get the ip address of the place to grab the files from
15:34:33 <dtantsur> TheJulia: my RFE proposes starting with just reading the existing files from disk
15:34:38 <dtantsur> it's silly, but it will get us going really quickly
15:35:02 <TheJulia> yeah, on the fly is far better for multi-conductor cases, but we can always iterate to it
15:35:10 <JayF> GET /v1/boot/<node>/../../../etc/passwd.ipxe /s
15:35:23 <dtantsur> JayF: see, so many cool features possible!
15:35:24 <TheJulia> we're not a general server
15:35:39 <dtantsur> the key for multi-conductor is the hash ring integration. my proposal gives that.
15:35:46 <TheJulia> only static file names based upon registered interfaces and deconstruct from there ;)
15:36:13 <JayF> So question
15:36:15 <TheJulia> yeah, we would likely need to store the ip address
15:36:15 <JayF> if we added this API
15:36:18 <TheJulia> addresses
15:36:19 <TheJulia> and urls
15:36:28 <JayF> we have all the pieces we need to do basically ... externally orchestrated Ironic, yeah?
15:36:41 <dtantsur> please elaborate
15:36:42 <JayF> Because we'd have the ability to change power, boot mode, and do static boot configs
15:36:52 <JayF> you could basically use Ironic as an API-controlled fancy pxe server
15:37:02 <JayF> without any of our other features
15:37:14 <dtantsur> Could be. We're even adding a way to attach virtual media (please review it!)
15:37:33 <JayF> which makes me a little sad, but also is a thing I've had multiple people say they wish they could do with an existing Ironic install (yeah, I've reviewed many of those and have +1s, I don't +2 redfish stuff unless nobody else is b/c I don't have hardware)
15:38:23 <dtantsur> JayF: you can use sushy-tools :D
15:38:36 <dtantsur> honestly, "I don't +2 things I don't have hardware for" may not be a sustainable idea
15:38:40 <JayF> I, bluntly, do not think that is sufficient testing to land a new hardware-supporting feature.
15:38:41 <dtantsur> someone has to review Fujitsu's patches
15:38:47 <JayF> dtantsur: I've never once in my life logged into a redfish BMC. Ever.
15:38:56 <JayF> dtantsur: and upon request I upgrade my votes.
15:39:03 <JayF> dtantsur: just a default not a strict personal policy :)
15:39:07 <dtantsur> How do you manage to avoid Redfish nowadays? :)
15:39:14 <JayF> I have no hardware at all :)
15:39:18 <dtantsur> haha, fair
15:39:22 <JayF> I work in Tacoma, WA, my employer is in London, UK :)
15:39:32 <dtantsur> This hardware thing, it only causes headaches, right?
15:39:32 <JayF> even when I'm in the UK I don't get to touch the gear lol
15:39:59 <rpittau> so going back to the RFE, dtantsur going to write a spec?
15:40:05 <dtantsur> I am
15:40:15 <rpittau> then I'll read it :D
15:40:19 <dtantsur> btw https://github.com/dtantsur/ironic-operator/issues/3 is the tracker for multi-conductor metal3
15:40:28 <dtantsur> in case anyone wants to jump on the discussion
15:40:52 <rpittau> it's open in my browser since last week :)
15:41:15 <rpittau> alright, anything else we need to discuss about ?
15:41:26 <dtantsur> so speaking of Fujitsu..
15:41:31 <rpittau> oh yeah
15:41:33 * dtantsur needs to find the RFE
15:42:22 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/2040236 BMC certificates
15:42:41 <dtantsur> I probably missed that meeting, but I'm puzzled by its outcome
15:42:56 <dtantsur> JayF: could you check my comment?
15:43:16 <dtantsur> Not that I mind a spec there, but it's really one of the things we tend to consider quite obvious
15:43:26 <JayF> I read the emails over the holiday. Upon reflection... 🤷
15:43:30 <JayF> we should probably look the meeting log up
15:43:43 <JayF> 10-30 is when I commented, looking
15:43:58 <dtantsur> https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-30-15.00.log.html I assume
15:44:52 <JayF> looks like that was a proxied concern mostly from Julia
15:44:58 <JayF> I can link the meeting logs into the bug
15:45:05 <dtantsur> TheJulia: ^^
15:45:21 <JayF> I was unsure, there was agreement on the uncertainty
15:45:21 <dtantsur> I'm even more puzzled by the logs to be honest
15:45:41 <dtantsur> The problem is: Ironic is currently *normally* operated with verify_ca=False
15:45:44 <dtantsur> we need to change that
15:45:55 <JayF> I wonder if we misread something meaningful in the bug, or if there's context I had then which is missing now
15:46:10 <JayF> I'm unsure, but that uncertainty makes me feel more like I want a spec, which may not be fair either :\
15:46:20 <dtantsur> Let me give it a try
15:46:22 <TheJulia> dtantsur: is the thought a boolean field value on a node?
15:46:35 <dtantsur> TheJulia: the boolean field on a node exists already, it's not helpful
15:46:36 <TheJulia> I can go for that, as a migration means
15:46:46 <TheJulia> we can't permit paths
15:46:48 <dtantsur> the only practical way to use it now is to set it to False
15:46:49 <TheJulia> realistically
15:46:51 <dtantsur> we can and should
15:47:12 <dtantsur> but not on the node level because it makes little sense
15:47:19 <dtantsur> (although we probably do allow that now already)
15:47:23 <TheJulia> I'm not sure I'm really comfortable with that, but I guess it boils down to implementation details and access rights
15:47:29 <dtantsur> this is really a site-specific setting
15:47:30 <TheJulia> i.e. don't let any member set the field
15:47:31 <JayF> My thought on the node-level stuff is
15:47:41 <dtantsur> that's why it has to go to ironic.conf
15:47:44 <JayF> if it's something shipped *in a ramdisk* paths in node level makes sense
15:47:52 <JayF> if it's something shipped *in a conductor*, you can't do it via API
15:48:00 <dtantsur> yep, the latter
15:48:02 <JayF> because ramdisks are accessible/changable via API; conductor files-on-disk are not
15:48:16 <dtantsur> it seems that we're in a full agreement, so what's the blocker?
15:48:46 <JayF> dtantsur: the suggested code in the example
15:48:50 <JayF> provides a node level override, I think?
15:49:01 <JayF> dtantsur: so the prose does not match the example code
15:49:05 <JayF> that is likely what the disconnect is
15:49:14 <dtantsur> the example code is weird, I agree. that's why I tell people not to include code in proposals....
15:49:27 <TheJulia> ++
15:49:52 <JayF> (and again, inconsistency in an RFE is more of a reason to have a spec IMO; but as long as we have a correct end state documented *somewhere* I don't care where that somewhere is)
15:49:53 <dtantsur> the idea is to have a conductor-level verify_ca for BMCs
15:50:11 <JayF> I think our two questions were primarily:
15:50:26 <dtantsur> I don't really mind a spec, just making sure the proposal is correctly understood from the beginning
15:50:28 <JayF> 1) it's [conductor]verify_ca being proposed for iRMC driver; we wanna be sure it's respected everywhere
15:50:39 * dtantsur nods
15:50:46 <JayF> 2) the example code has a node-level override, which is (for reasons discussed here) not awesome
15:50:54 <JayF> which I think is what my comment is trying to say, badly
15:51:08 <JayF> I'm going to re-post that comment with more verbosity
15:51:15 <dtantsur> yeah, I agree. thanks!
15:51:42 <dtantsur> I have a nagging desire to just junk the code examples from the RFE
15:51:58 <dtantsur> yank? I cannot do words today
15:52:40 <rpittau> well that was a good  discussion :)
15:53:06 <rpittau> I think we're good or we have something more to discuss?
15:53:47 <JayF> #link https://bugs.launchpad.net/ironic/+bug/2040236/comments/4
15:53:52 <JayF> that's the updated comment in summary
15:54:09 <rpittau> thanks JayF
15:54:17 <rpittau> I think we can close here
15:54:19 <rpittau> thanks everyone!
15:54:21 <rpittau> #endmeeting