15:00:07 <rpittau> #startmeeting ironic
15:00:07 <opendevmeet> Meeting started Mon Feb 24 15:00:07 2025 UTC and is due to finish in 60 minutes.  The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:07 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:07 <opendevmeet> The meeting name has been set to 'ironic'
15:00:24 <rpittau> Hello everyone!
15:00:24 <rpittau> Welcome to our weekly meeting!
15:00:24 <rpittau> The meeting agenda can be found here:
15:00:24 <rpittau> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_February_24.2C_2025
15:01:22 <iurygregory> o/
15:02:10 <masghar> o/
15:02:17 <rpittau> let's wait a couple of minutes for people to join :)
15:02:23 <cardoe> o/
15:02:29 <dtantsur> o/
15:02:41 <TheJulia> o/
15:02:49 <cardoe> I forgot to add it to the agenda but can we discuss sushy release?
15:02:50 <cid> o/
15:02:59 <rpittau> well I think we're good with quorum :)
15:03:07 <rpittau> cardoe: it's there actually, I added it
15:03:20 <rpittau> #topic Announcements/Reminders
15:03:31 <rpittau> Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio:
15:03:31 <rpittau> #link https://tinyurl.com/ironic-weekly-prio-dash
15:04:20 <rpittau> some patches to review there, need to get them quick as the time is running out for the release
15:04:23 <kubajj> o/
15:04:53 <rpittau> #info 2025.1 Epoxy Release Schedule
15:04:53 <rpittau> #link https://releases.openstack.org/epoxy/schedule.html
15:04:57 <iurygregory> I will prioritize review in sushy, I was on PTO
15:05:04 <rpittau> we're at R-5 !
15:05:12 <rpittau> feature freeze is upon us
15:05:16 <JayF> o/
15:05:40 <rpittau> so anything that we want to go in Epoxy needs to merge before EoW
15:06:19 <rpittau> I will also start working on the cycle highlights that are due next week
15:07:05 <rpittau> #info Flamingo PTG will take place place April 7-11, 2025!
15:07:05 <rpittau> don't forget to register!
15:07:05 <rpittau> the etherpad is ready here:
15:07:05 <rpittau> #link https://etherpad.opendev.org/p/ironic-ptg-april-2025
15:07:51 <cardoe> grrr there was something I was suppose to add there.
15:08:11 <rpittau> anything else to announce/remind ?
15:08:27 <JayF> Ironic is DPL; or will be at the flip of the cycle.
15:08:36 <JayF> I will work with TC to ensure that change merges
15:08:47 <iurygregory> tks JayF
15:08:58 <rpittau> yep, when Epoxy is released ironic will switch to DPL
15:09:14 * JayF hands rpittau his "Last PTL of Ironic Ever (maybe)" sash
15:09:19 <rpittau> :D
15:09:42 <rpittau> thanks!
15:10:09 <rpittau> anything else or we can move to the discussion topics?
15:11:13 <rpittau> ok moving on
15:11:13 <rpittau> #topic Discussion Topics
15:11:33 <rpittau> #info migrate sushy-oem-idrac to sushy
15:11:33 <rpittau> #link  https://review.opendev.org/c/openstack/sushy/+/940557
15:11:47 <rpittau> I guess we need to move this to the next cycle
15:12:04 <rpittau> sushy release is already late
15:12:12 <TheJulia> Well, we can do it, it just won't make this cycle
15:12:16 <rpittau> yeah
15:12:25 <rpittau> that's what I meant :)
15:12:26 <iurygregory> omg +6550
15:12:27 <cardoe> I just don't know what we need to do.
15:12:28 <TheJulia> and by do it, I mean approve the patches right now
15:12:36 <cardoe> Cause it works.
15:12:49 <cardoe> It even installs along side together just fine
15:12:59 <cardoe> It's just "wrong" to install both"
15:13:03 <rpittau> it's a last minute huge change
15:13:15 <JayF> yeah; it seems like the ideal thing to have at the top of the cycle
15:13:17 <rpittau> and IMHO we probably need to deprecate sushy-oem-idrac first
15:13:32 <JayF> I know it's painful to wait but it's extremely good it's lined up
15:13:48 <cardoe> https://review.opendev.org/c/openstack/ironic/+/942520 is all that ironic needed.
15:13:49 <rpittau> cardoe: you did a great job, thanks a lot for that :)
15:14:10 <cardoe> I'm good with pushing to the next cycle and deprecating sushy-oem-idrac first.
15:14:24 <rpittau> that's another last minute change, FF is this week
15:14:35 <rpittau> cardoe: perfect
15:14:36 <rpittau> thanks
15:14:42 <JayF> Traditionally Ironic hasn't complied with overall OpenStack FF
15:14:53 <JayF> those are usually for cycle-with-rc, not cycle-with-intermediary
15:14:53 <iurygregory> ++
15:14:54 <cardoe> I just want to know WHAT we want to do to formally merge it all.
15:15:28 <dtantsur> If it's co-installable, we might JFDI right after branching ironic
15:15:39 <rpittau> yep
15:15:53 <JayF> ++
15:15:56 <rpittau> I'd say we can merge the sushy change whenever, but wait for the ironic one
15:16:14 <dtantsur> This may cause troubles for people consuming master
15:16:19 <dtantsur> but probably not critical troubles
15:17:08 <cardoe> I dunno what trouble it will cause for packagers. Cause they do install the same file (for the entry point). And while pip doesn't care. An RPM built up from a Python package might care if they both install the same file?
15:17:10 <rpittau> mmmm well it won't be released, so if we see issues we're more relaxed in fixing them
15:17:28 <cardoe> So I'd rather hold off and understand WHAT I need to do to communicate the change the best way.
15:17:51 <cardoe> But that's what I'm saying.. I dunno how to best communicate that.
15:18:02 <rpittau> production RPMs usually are built from releases, not from master
15:18:30 <dtantsur> yeah, I'm just being overly cautious
15:18:37 <rpittau> :)
15:18:45 <dtantsur> but *at latest* when Ironic is branches we should just merge everything
15:18:50 <dtantsur> * is branched
15:18:54 <rpittau> yep
15:19:22 <rpittau> I'll release the krak... the sushy release then
15:20:33 <dtantsur> pull the lever!
15:20:41 <rpittau> done! :D
15:20:42 <iurygregory> ship it!
15:20:52 <rpittau> cardoe: I just udpated the ironic change so it's clear what we need to do
15:21:18 <rpittau> the sushy change can go in at will
15:21:57 <rpittau> are we good to move on?
15:23:00 <rpittau> ok!
15:23:17 <rpittau> #info ironic-lib deprecation
15:23:17 <rpittau> #link  https://review.opendev.org/q/topic:%22ironic-lib-deprecation%22
15:23:38 <rpittau> I think we're waiting for https://review.opendev.org/c/openstack/governance/+/939278 ?
15:23:53 <JayF> yes, I'll nudge TC about that, too
15:23:59 <rpittau> thanks JayF :)
15:24:33 <rpittau> any other discussion topics for today?
15:25:14 <cid> RFEs
15:25:26 <rpittau> cid: yes!
15:25:32 <rpittau> which one(s) ?
15:26:10 <cid> This, https://bugs.launchpad.net/ironic/+bug/2098884
15:26:26 <cid> I have updated the agenda with the links to the rest.
15:27:00 <JayF> I assume (cc: TheJulia) that the redfish serial interface is shaped similarly to the ipmi stuff?
15:27:06 <JayF> If so, seems like an obvious JFDI
15:27:17 <TheJulia> JayF: It really doesn't exist afaik
15:27:28 <dtantsur> Well, it can be over IPMI or SSH
15:27:28 <JayF> then what is the RFE wanting us to do?
15:27:31 <dtantsur> (or OEM, yay)
15:27:36 <JayF> wait, what
15:27:37 <TheJulia> well, true, it can be
15:27:51 <JayF> redfish bmcs expose serial consoles over ipmi, is that what you just said?
15:27:53 <dtantsur> JayF: Redfish specifies IPMI or SSH as possible protocols for serial console :)
15:27:56 <TheJulia> I've *yet* to see a bmc that offers that though
15:28:01 <dtantsur> \o/
15:28:20 <TheJulia> possible being the magical aspect :)
15:28:22 <JayF> oroborous is gonna sue hardware companies for gimmick infringement lol
15:28:27 <dtantsur> If we did not have a VPN outage, I would check our internal Redfish dumps
15:28:37 <TheJulia> wheeeeeeee
15:28:51 <TheJulia> Anyway, yeah, given its a possible option, jfdi just seems to make sense to me
15:29:10 <dtantsur> TheJulia: is what you offer basically just adding ipmitool-socat to the list of supported interfaces?
15:29:16 <dtantsur> I.e. without actually checking the Redfish data?
15:29:34 <JayF> I assume we'd actually need some glue code, the RFE implies we'd have to do some credential and metadata passing
15:30:08 <TheJulia> dtantsur: Thinking so *and* likely allowing the ipmitool exec code to understand it can grab username/password/host address from the redfish fields
15:30:41 <cardoe> TheJulia: does that just work?
15:30:51 <TheJulia> I've not looked closely at it, so my brain is running form memory, but it should just work if the values are already populated for ipmi
15:31:03 <TheJulia> and the interface is available/loaded
15:31:16 <dtantsur> Hmm. I don't object to it, but let's make sure (naming etc) that we can introduce a more proper Redfish interface later (even if it looks unlikely right now)
15:31:23 <cardoe> https://www.dmtf.org/sites/default/files/Redfish_Serial_Console_Enhancements_05-2020_WIP.pdf afaik is what I had bookmarked for changes
15:31:47 <JayF> IPMISoCatConsoleViaRedfish console class coming up? :D
15:31:48 <TheJulia> I suspect our introduced interfaces will be more-so graphical :)
15:31:50 <TheJulia> but yeah
15:32:07 <TheJulia> Eh, I suspect some folks would prefer ssh if we have a known working example
15:32:19 <TheJulia> but I'm just trying to do the needful, not boil an ocean
15:32:33 * TheJulia is working on ocean boiling network switching at the moment
15:32:39 <TheJulia> (well, testing)
15:34:26 <vsaienko> ironic team, can somebody please point me to the code where connectivity between multinode devstack builds is configured on CI? I'm looking similar place https://review.opendev.org/c/openstack/devstack-gate/+/335981/7/devstack-vm-gate.sh in zuul ansible roles
15:35:28 <rpittau> vsaienko: let's wait for after the meeting for that, thanks :)
15:35:58 <cardoe> There's a few more RFEs. Let's go through them.
15:36:16 <cardoe> cid said 4 but I see 5. :shifty:
15:36:28 <cardoe> https://bugs.launchpad.net/ironic/+bug/2098886
15:36:30 <TheJulia> folk scan blame me for some of these, I was quickly filing bugs from discussions
15:36:32 <cid> :)
15:36:47 <cardoe> #link https://bugs.launchpad.net/ironic/+bug/2098886
15:36:53 <cardoe> To steal rpittau's thunder a little.
15:37:03 <TheJulia> This one comes from a disucssion where someone conveyed they really neede to deploy a whole bunch of identical machines, and didn't care about fine details
15:37:21 <TheJulia> and didn't also care about much of the openstacky primitives
15:37:30 <dtantsur> Oh. TheJulia is going to hate me, but this should be reworked in terms of allocations and ideally the deployment API
15:37:31 <TheJulia> they just wanted it to be single-action oriented
15:37:40 <dtantsur> maybe not allocations, maybe only the deployment API..
15:37:54 <TheJulia> The key aspet is they are just a tenant with restricted views and basically wanted bulk deployments
15:38:17 <TheJulia> dtantsur: actually, I was kind of thinking something along the basic idea but sans allocations since that is something else they need to interact with
15:38:25 <TheJulia> basically, they just want a bulk interactions interface
15:38:31 <TheJulia> where the conductor can solve the details
15:38:45 <dtantsur> But in all honesty.. it's a simple loop in Python, no?
15:38:45 <TheJulia> I realize, the idea needs a lot of work, so its fine if people want to put notes in and we can move on
15:38:59 <TheJulia> they don't want to have to think/manage at that level
15:39:02 <dtantsur> I think a much bigger usability issue is the lack of a deployment API, which caused metalsmith
15:39:03 <JayF> I don't really like the idea of that at all tbh
15:39:09 <JayF> == dtantsur
15:39:25 <dtantsur> if we have deployment API, what you need would be 4 lines of Python probably
15:39:36 <TheJulia> They don't want that, they want a single rest call.
15:39:40 <cardoe> So honestly I think this puts complexity into Ironic that should really be done by the caller of the API.
15:39:50 <TheJulia> fair enough
15:40:00 <cardoe> Cause what should be the result if 1 fails and 3 succeed cause of locking?
15:40:02 <JayF> I mean, I'd rather them have a short script or client hack than have ironic do a bad job of batching
15:40:04 <TheJulia> I'm just the proxy, I'm not going to advocate endlessly for this
15:40:12 <JayF> because it's not... ^^^ yes exactly cardoe is going down my path
15:40:32 <dtantsur> My comment is not a hard no, but I pretty firmly believe we need to solve the general deployment UX first
15:40:44 <JayF> yeah; have a "deploy one in one rest API call"
15:40:49 <JayF> before "deploy many in one rest API call"
15:41:09 <TheJulia> I sort of think one of the next ones actually approaches that, so I think we can carry on to the next rfe?
15:42:26 <cardoe> #link https://bugs.launchpad.net/ironic/+bug/2098888
15:42:57 <cardoe> Feels like a better replacement for shellinabox?
15:43:09 <JayF> I'm assuming the mechanism for this would be a sidecar container, like for redfish gfx console?
15:43:28 <JayF> I'd prefer something like this not end up with ssh connections routed through/proxied by a conductor
15:43:41 <dtantsur> Yeah, I'm also curious about technical details, but the idea sounds good
15:44:21 <TheJulia> Socat console would get you a graphical console
15:44:31 <TheJulia> this is just... ssh wrapping the connection
15:45:07 <TheJulia> JayF: to be determined, but if we follow the existing model of console interfaces each responsible conductor would manage the "sshds"
15:45:31 <JayF> I have a lot of security nervousness if those sshds are colocated with the conductor, but that's implementation detail territory
15:45:39 <TheJulia> indeed
15:45:43 <dtantsur> I potential issue may be the requirements on root access
15:45:56 <dtantsur> We've just got rid of oslo.rootwrap
15:46:19 <dtantsur> Could be a case for a small companion service
15:46:20 <TheJulia> at least a long time ago, you could invoke sshd without root if you were doing a highly sepcific configuraiton
15:46:32 <dtantsur> hmmm
15:46:45 <dtantsur> I'd read a more detailed proposal, be it in a spec or simply on LP
15:46:49 <TheJulia> specific configurations would be be the soup of the day for something like this
15:46:50 <dtantsur> but I'm not against the idea
15:46:55 <TheJulia> ack
15:46:58 <rpittau> TheJulia: yeah you can do that with a user config
15:47:06 <TheJulia> rpittau: yup
15:47:10 <JayF> Yeah the idea seems good here but likely valuable to write more details (if it were me I'd do a spec)
15:47:27 <dtantsur> We really need some form between an RFE and a spec
15:47:44 <TheJulia> Okay, onward!
15:47:45 <rpittau> or just add more details to the RFE ?
15:47:47 <JayF> eh; I think it's mainly "don't be a stick in the mud when reviewing specs for minor things" :D
15:47:59 <dtantsur> true :D
15:48:01 <JayF> I appreciate the structure, but maybe that's just me
15:48:59 <TheJulia> onward?
15:49:12 <JayF> onward!
15:50:40 <rpittau> #link https://bugs.launchpad.net/ironic/+bug/2098694
15:51:38 <TheJulia> Just an idea placeholder for the aformentioned serial console topic
15:51:41 <dtantsur> I guess the blocking concern is lack of hardware?
15:51:44 <JayF> is that a differently worded version of the other two RFEs we've looked at around ssh->socat and ipmi-over-redfish consoles?
15:52:03 <rpittau> I was wondering the same
15:52:12 <TheJulia> I added this one as "we should look into this in general, not specifically"
15:52:36 <TheJulia> so there is no ipmi-over-redfish console and this is entirely unrelated to ssh->socat->ipmitool sol
15:53:06 <JayF> I'm happy for the feature to exist; but I would not have a use case or consume it :)
15:53:08 <TheJulia> This might be a source of redfish-ssh console or soemthing like that
15:53:24 <dtantsur> This is probably ENEEDSPEC
15:53:37 <dtantsur> Generally valid idea but we don't have enough information to approve it
15:53:49 <JayF> seems like this is less an RFE at this point and more a place to put research until we see what the feature owuld loook like
15:53:57 <dtantsur> ++
15:54:07 <rpittau> +1
15:54:55 <JayF> RFE: research for enhancement lol
15:55:09 <dtantsur> :D
15:55:10 <rpittau> :)
15:55:23 <rpittau> next (and last) one ?
15:55:39 <rpittau> #link https://bugs.launchpad.net/ironic/+bug/2099906
15:56:03 <JayF> wait, really?
15:56:08 <JayF> +2 JFDI
15:56:26 <rpittau> yep not a lot to discuss  there
15:56:42 <cardoe> What do ya want the field called?
15:56:45 <dtantsur> Is it similar to node.description?
15:56:52 <dtantsur> because it sounds like node.description
15:57:00 <TheJulia> a port.description filed?
15:57:02 <TheJulia> field
15:57:05 * TheJulia cannot type today
15:57:12 <cardoe> port.description works for me.
15:57:17 <rpittau> sounds good
15:57:25 <TheJulia> so one last item I wanted to bring up
15:57:28 <TheJulia> if we've got time
15:57:38 <rpittau> we have 2:25 minutes :)
15:57:43 <TheJulia> #link https://bugs.launchpad.net/ironic/+bug/2098697
15:58:25 <dtantsur> A solid idea, definitely needs a spec in my book
15:58:27 <TheJulia> The idea is "it would be really nice if we didn't have to think in neutron primitives and have a vif" so to enable a model where ironic can fill the gap to it's neutron preferred data model, or even non-neutron usage models with some automatic logic
15:58:37 <JayF> Well, I wonder if at the PTG
15:58:54 <JayF> we should try to have a chat with neutron/nova/ironic devs and see if there's a better path forward including ideas like this
15:59:20 <TheJulia> This is semi-disjointed, because a nova user will always send us a vif
15:59:23 <JayF> (that's not an instead; that's an in-addition-to / as a part of)
15:59:25 <TheJulia> well, nova will do it
15:59:38 <JayF> TheJulia: well, I'm asking, is there a world where there'd be value in Nova not doing it, and Ironic doing it
15:59:41 <TheJulia> nova (last time I looked) had paths to magically get you a vif
16:00:15 <JayF> It seems like pushing some of the network config to Ironic/neutron without nova involved could lead to more flexibility, especially for cases where you are owner/lessee and have some control over the node
16:00:22 <TheJulia> I would avoid nova like the plauge since nova has all of the logic "if we get handed a network, we need to do x, if we get handed a this other value we need to do y logic"
16:00:47 <JayF> ack
16:00:51 <cardoe> Gonna have to chat with the nova folks about that change.
16:01:08 <cardoe> I know they've been breaking out the vif bits into a separate os-vif library.
16:01:17 <TheJulia> I'm just thinking, is there a path to make the non-nova user life easier
16:01:28 <dtantsur> non-nova but with neutron?
16:01:31 <TheJulia> yup
16:01:34 <dtantsur> metalsmith-style
16:01:36 <dtantsur> okay, yeah
16:01:38 <TheJulia> or, potentially without
16:02:16 <TheJulia> sort of depends on where the matrix needs to end up overall, but not trying to join other stuff together in a grand vision at the moment
16:02:30 <TheJulia> hopefully, that makes sense
16:03:20 <JayF> I understand, I do worry sometimes that we haven't taken a high level view of the integrated process in a while, and often assume that the status quo is unchangable
16:03:20 <rpittau> we can bring up the topic next time for a deeper discussion if needed, or even add something to the PTG etherpad
16:03:31 <JayF> I wanted to imagine for a second that we could change the status quo :)
16:04:25 <rpittau> alright thanks everyone, going to close the meeting now :)
16:04:30 <rpittau> #endmeeting