15:00:39 #startmeeting Ironic 15:00:39 Meeting started Mon Dec 4 15:00:39 2023 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:39 The meeting name has been set to 'ironic' 15:00:42 o/ 15:00:51 #topic Announcements/Reminder 15:00:56 Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash 15:01:18 o/ 15:01:19 No action items from previous meeting, skipping agenda item 15:01:28 #topic Carcal release schedule 15:01:35 #link https://releases.openstack.org/caracal/schedule.html 15:01:47 Next milestone is R-17, Caracal-2 on Jan 11, take notice :) 15:01:54 #topic Review Ironic CI Status 15:01:56 How is CI? 15:02:26 I think is in a good shape 15:02:41 my changes have passed recently 15:02:45 last week we were able to merge a few things without problems from what I remember 15:03:04 That matches my experience, nice to hear, thanks for keeping the gate clean. 15:03:04 we finally moved the snmp job from focal =) tks TheJulia 15:03:13 #topic Bug deputy 15:03:31 Julia was bug deputy last week, and we did some cleanup of bugtrackers 15:03:38 TheJulia: anything to report from time as bug deputy? 15:03:51 Julia is not available today 15:03:54 I think she mentioned she wouldn't be around 15:03:57 ack 15:04:02 yeah 15:04:05 Hopefully it went well, is someone signed up for enxt week? 15:04:21 afaik nope 15:04:28 Aight, I'll take a swing 15:04:31 you mean this week right? 15:04:34 #action JayF to bug deputy this week 15:04:36 yep 15:04:40 gotcha! 15:04:49 Is this bugfix branch topic leftover from last week? 15:05:01 #topic New bugfix branches proposed 15:05:22 I think rpittau was doing something related to this, but he is out today 15:05:29 Ack; we'll table the topic 15:05:34 #topic RFE Review 15:05:37 dtantsur has two 15:05:45 :O 15:05:45 #link https://bugs.launchpad.net/ironic/+bug/2045548 15:05:50 I do indeed 15:06:00 dtantsur: is the real only use case for this dual stack ip? 15:06:12 JayF: for me - yes 15:06:23 dtantsur: basically I'm a little worried this is going to end up as "Ironic API HA via 'yolo try all the api servers'" rather than properly load balanced 15:06:43 Isn't properly the same? 15:06:58 oh, I modeled this backwards 15:07:06 I was mentally thinking of this as "N" callback urls *from* IPA 15:07:13 but this is "N" callback urls *for* IPA to callback to 15:07:50 Yeah, so IPA->Ironic. My personal pain is less about HA, more about a dual-stack Ironic with a V6-only node. 15:08:03 * iurygregory hides 15:08:15 I don't have any objection to this directly; but I also think if rpittau and TheJulia is out that we don't really have strong quorum for RFE approval 15:08:20 I know your pain dtantsur 15:08:27 if you know one or both of them are +1 or at least +0 to it, I'm OK with it 15:08:49 I can ask them later on. Putting it on the meeting means that they can at least see that in the scrollback. 15:08:53 ++ 15:09:05 Let's treat this as a sanity check / announcement of intentions :) 15:09:32 #info Bug 2045548 seems ripe for RFE approval, but no strong quorum of cores at meeting. Intention is to move forward if no objection once more cores look. 15:09:36 The next one is more interesting, I believe 15:10:07 #link https://bugs.launchpad.net/ironic/+bug/2045551 Auto-configuration of iPXE script for inspection 15:10:24 So there's two things that confuse me about this: 15:10:41 1) is it still unmanaged inspection if we're generating PXE scripts around it in Ironic? hehe 15:11:00 2) when we talk about fallback scripts, is that like, generating an ipxe config which would boot anything if put in the correct spot? what is the correct spot? 15:11:21 The current logic in boot.ipxe is roughly this: 15:11:54 for mac in macs: try_chainload(http://server/$mac/boot.ipxe); chainload(http://server/fallback.ipxe) 15:12:09 So, this last item is where inspection is normally hooked into, at least for standalone deployments 15:12:42 basically "boot any specific configs we have, boot the generic config for anything else" (which in a default config is nothing/chainload to hdd I would assume?) 15:13:01 Correct 15:13:21 So far, this fallback script has to be hand-written (see examples from metal3; bifrost has the same) 15:13:44 Is there a difference from what we document today as "unmanaged inspection" and "discovery" ? 15:14:24 Technically the same thing, only the intention is slightly different 15:14:54 ack 15:15:13 my only real weirdness about this feature 15:15:24 is we can't really enable it on *all* conductors on a given dhcp domain, right? 15:15:34 hmm. I guess we could, because it's just an ipxe script 15:15:43 it's just available should the dhcp server point at it 15:15:47 Right. DHCP is a different story. 15:16:02 dhcp is [magic word] UNMANAGED in that case, right? lol 15:16:22 Right :D 15:16:31 So the feature seems OK 15:16:40 but I kinda hate the name? 15:16:48 I know it fits in ironic contexts, but I don't think it signals to operators what the behavior change will be 15:16:59 which exactly name? 15:17:16 so my only thing would be, lets make 100% sure it's clear that if someone flips that switch what they're going tobe getting 15:17:30 > [pxe]generate_ipxe_inspection_script = True/False (default False) 15:18:01 like, I feel like we could use a word like ... "universal" 15:18:01 Yep. (Also, naming suggestions welcome) 15:18:01 or "fallback" 15:18:01 or "global" 15:18:01 or "all of the things" 15:18:08 I don't have an actual good suggestion but you get the idea :D 15:18:25 This thing will be inspection-specific 15:18:36 It's not like a fallback to something abstract 15:18:47 that means ... less in a future world where everything is Ironic-based :D 15:18:55 :D 15:20:00 So I think similar adjudication for this, probably OK, lets get more feedback and maybe pick a stronger name? 15:20:06 we probably need a shared doc with good naming ideas lol 15:20:14 :D 15:20:17 JayF++ 15:20:46 #info Bug 2045551 seems ripe for RFE approval, but no strong quorum of cores at meeting. Intention is to move forward once a better config var name is chosen and if no objection once more cores look. 15:21:09 dtantsur: please update those RFE bugs with the comments from the meeting (link to the meeting logs once we get ti closed up would be great) 15:21:18 #topic Open Discussion 15:21:26 Nisha_Agarwal: mallik: You have a topic here 15:21:28 Hi Jayf 15:21:32 yup 15:21:52 Hi JayF 15:22:01 So first of all, the storyboard issues created; please create them in launchpad. We no longer use storyboard and I'm confused as to how new issues were created there. 15:22:18 https://bugs.launchpad.net/ironic 15:22:20 We are testing the redfish driver with ilo6 15:22:26 JayF, ok 15:22:40 there are two features where we see the issue 15:22:49 one is Event Scusbscription 15:22:58 ilo6 is on higher redfish schema 15:23:16 while ironic is using the schema where attributes are deprecated 15:24:03 * iurygregory was the one to write the event subscription via vendor passthru 15:24:24 So sushy needs to enhance the redfish schema implementation and may be intelligently derive which schema version does the server has.... 15:24:52 ilo5/SuperdomeFlex280 works with current implementation of event Subscription 15:25:06 while ilo6 has higher schema implemented 15:25:13 So, ilo6 removes the deprecated fields completely? 15:25:19 I think we would normally add the new attributes to sushy to match the new schema and keep backward compatibility I think 15:25:23 Looks like 15:25:49 iurygregory, yeah that should solve the issue.... 15:25:50 Sigh, okay. Patches are welcome if you have cycles (esp. since you can test on both hardware versions) 15:26:13 dtantsur, yup. We are working on the patches 15:26:27 Nisha_Agarwal, would also need to update the vendor passthru logic in ironic after sushy is ready 15:26:47 iurygregory, ok. 15:27:13 We will test end-to-end using ironic 15:27:26 nice! 15:27:30 Secondly on out-Of-Band Raid 15:27:51 Ironic implements two parameters "VolumeType" and "Encrypted" 15:28:03 in addition to other parameters 15:28:31 VolumeType is deprecated and is not present in ilo6 15:29:07 masghar: ^^^ 15:29:30 Nisha_Agarwal: what do you use instead for the RAID level? 15:30:25 "Encrypted" is not deprecated, but iLO6 has cautiouslu not impelmented it. The Storage Distinguished Technoligist has told that very few vendors have impelmented Encrypted 15:30:37 cautiously^^^ 15:30:49 dtantsur, it is deprecated in favor of "RAIDType" 15:30:50 It seems that we unconditionally send Encrypted:False. Not sure why, but I suspect we can just remove that. 15:31:23 Ah. And we already pass RAIDType too. Again, I'm curious why we did that. 15:31:28 so i believe it should work with that payload. But i need to crosscheck with the engineer who is working on it 15:32:03 Redfish driver, right? (just confirming) 15:32:18 Yes 15:32:19 masghar, correct 15:32:31 masghar: can you check if your Dell machine has RAIDType? 15:32:34 if we remove these two parameters the creation of RAID works 15:32:45 Let me see 15:33:46 So we wante dto know if we could add a condition in redfish driver (sushy) specific to Proliants? 15:33:59 that would be allowed right? 15:34:33 this wouldn't be a problem I would say 15:34:34 Nisha_Agarwal: this is not immediately disallowed, but for what purpose? 15:34:50 if VolumeType is deprecated and Encrypted is unused, we just drop them. 15:34:59 Yeah, that is kinda a last resort if we can't use non-vendor-specific ways to figure out the right thing to do 15:35:11 dtantsur, ok. 15:35:36 there is one power bug also which was raised on ilo5. But it applies to ilo6 as well 15:36:04 that was raised by Gresearch i guess 15:36:13 https://bugs.launchpad.net/sushy/+bug/2016307 ? 15:36:13 Yeah, it's already been fixed, and the backport is back pretty far already 15:36:17 there it requires vendor specific check probably in sushy 15:36:45 iurygregory, not this 15:36:59 oh ok, I've found this one when looking in launchpad 15:37:13 https://opendev.org/openstack/sushy/commit/192d897ce97120db98aca6d6bb840c4243a4b5b3 is the fix I was thinking of 15:37:29 https://bugs.launchpad.net/ironic/+bug/2021995 15:37:40 yes the fix done above was partial 15:37:47 and doesnt solve the above issue 15:38:02 i had done a workaround fix in proliantutils for ilo5 15:38:33 but it still requires a small fix in sushy to have that workaround available for ilo6 as well 15:38:42 and probably for other vendors too 15:39:12 this may require vendor specific check is what i wante dto put forward 15:39:48 Stuff like that is best evaluated in gerrit on the patch IMO 15:39:52 I'd have to see the patch to judge 15:39:53 yeah 15:39:58 dtantsur, ok 15:40:12 Is there anythign else to discuss on this topic? 15:40:44 JayF, one more point about the mail thread on driver deprecation 15:40:50 sure 15:41:48 the spec raised for this release item lists ilo driver under the heading "Drivers to be removed" 15:42:20 which looked incorrect and may discourage customers to use ilo/ilo5 driver for gen9/gen10 15:42:29 so two things, firstly, it doesn't say that 15:42:31 This was a concern raised by my management 15:42:40 it says: "Drivers to be marked for removal" 15:42:53 so just putting forward the concern 15:42:55 also in the paragraph above, it says: "We do not intend to actively remove any of these drivers until it is clear any hardware they exclusively support has gone end of life. We are primarily taking this action to indicate to operators that they should be provisioning new hardware with Redfish-based drivers." 15:42:57 yup 15:43:10 So, the context behind why we worded it this way, and put it so strongly 15:43:18 and there's willingness to change it as long as it achieves this goal 15:43:31 is we've seen the branded-drivers be very attractive to new operators of ironic 15:43:49 so we'll have users choose to use an ilo driver on their ilo6, or a idrac{-wsman} driver on a newer dell 15:44:06 even though for those devices, a redfish driver is a better choice, because they've heard of "idrac" or "ilo" but have never heard of "redfish" 15:44:19 hmm 15:44:33 ok 15:44:44 I'll note that for many drivers, we already have it printing a deprecation message -- we didn't put that in for iLo 15:44:55 Thanks JayF that answers the query :) yes thanks for that 15:45:02 and I thought it'd be worse for you all to leave you off that list entirely; I don't want HPE users to be completely lost on what driver to use 15:45:09 i saw the mail, but still i wanted to put forward the message 15:45:22 so if there's suggestions on how to reword that, I'm happy to take edits to that spec, nothign is ever set in stone 15:45:31 but the goal was to funnel new ironic operators to redfish driver by default 15:45:35 JayF, that should be great 15:45:58 I will check with management and reword if they are not ok with what you explained above 15:46:13 Thanks JayF 15:46:19 no problem o/ 15:46:23 Anything else for open discsusion? 15:46:26 thats all 15:46:32 I have one 15:46:43 What's up iurygregory 15:47:02 it's more a request than a discussion LOL 15:47:48 related to how we could speed-up multipath checking in IPA I've created https://review.opendev.org/c/openstack/ironic-python-agent/+/902012 15:48:28 Gotta be honest, I've not looked at that much because I don't have very much experience with multipath IO 15:48:40 so I'm a little scared I'd approve something that'd break the underlying tech unknowingly 15:48:43 is just my initial idea in the code, the commit explains what I'm trying to do to speed-up 15:49:07 yeah, so if anyone is interested please look and provide your thoughts in the patch \o/ 15:49:15 #link https://review.opendev.org/c/openstack/ironic-python-agent/+/902012 15:49:27 I'll look, but as I said, take any comments I put on it as advisory 15:49:37 JayF, sure =) 15:49:39 I'm not sure I've ever, once, been on a machine with multipath remote IO 15:50:12 Anything else for Open Discussion? 15:50:12 I don't have one, this is just by looking at ironic logs and looking at our logic for multipath 15:50:19 makes sense 15:50:47 tks! 15:51:46 Last call? 15:53:04 ty all o/ 15:53:06 #endmeeting