15:01:58 #startmeeting ironic 15:01:58 Meeting started Mon Feb 1 15:01:58 2021 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:00 Good morning everyone! 15:02:02 o/ 15:02:03 The meeting name has been set to 'ironic' 15:02:05 o/ 15:02:08 o/ 15:02:09 o/ 15:02:19 o/ 15:02:21 o/ 15:02:22 Our agenda can be found on the wiki, as always. 15:02:33 We should likely discuss what to do without a wiki one day... 15:02:34 Anyway 15:02:36 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:02:48 o/ 15:02:51 * TheJulia makes a quick last minute fix 15:02:51 o/ 15:03:05 Okay! 15:03:15 o/ 15:03:16 #topic Announcements / Reminders 15:03:39 o/ 15:03:41 #info This week is R-10 for the Wallaby release. Again, R-6 is non-client library freeze, R-5 is client library and requirements freeze. 15:04:01 #info Second sprint ends next week with hopefully a release. CI of course permitting :) 15:04:35 #info Review Jam poll link has been posted. More votes will be appreciated. If your interested and have not voted, please do so today. 15:04:44 #link https://doodle.com/poll/mdv6vpw6qdfzteg2 15:04:51 Does anyone have anything else to announce or remind us of? 15:05:00 An iLO CI Gate has been added to Sushy. Test ran successfully for https://review.opendev.org/c/openstack/sushy/+/773273 15:05:07 nice! 15:05:10 Excellent! 15:05:32 would be good for the ironic-cores to review https://review.opendev.org/c/openstack/project-config/+/772427 =) 15:05:45 stendulker: That almost sounds worthy of #success 15:05:54 maybe I missed something to add the support for editHashtag =) 15:05:56 Thank you :) 15:06:11 iurygregory: that looks good, I'll add my +1 15:06:19 iurygregory: please add that link to the list of priority reviews 15:06:27 TheJulia, ack o/ 15:06:46 Does anyone else have anything else to announce or remind us of this week? 15:07:37 I wanted to take a quick moment to thank everyone for midcycle participation last week! It was great to hear everyone's voices. :) 15:08:13 So last week didn't have any action items, so I believe we can proceed to subteam status reports if there are no objections. 15:08:47 #topic Review subteam status reports 15:08:56 #link https://etherpad.opendev.org/p/IronicWhiteBoard 15:09:12 Starting at line 260 15:09:20 we had action items from the midcycle, does it counts? 15:10:04 Some of them are longer items, I guess we can circle back later on 15:10:08 We've got a lot on the agenda 15:10:12 ++ 15:12:05 bdodd: thanks for the update on redfish raid 15:12:18 TheJulia Of course 15:12:54 iurygregory: still fighting with privsep I guess? :) 15:13:48 TheJulia, correct =) 15:14:09 will try to add notes after finding something about the error 15:14:16 Okay 15:14:35 I think that is pretty good, are we good to proceed 15:14:37 ? 15:14:46 ++ 15:15:17 let's 15:15:25 #topic Deciding on priorities for the coming week 15:15:37 So I went through and checked patches to see if they had merged/been approved/etc 15:15:50 I have not added patches outside of the nvme erase code 15:16:06 I'll clean up the list of merged patches if others will post their links for the week 15:18:31 Anything else to add? 15:19:43 I guess that looks good to me 15:20:12 should be good 15:20:27 Onward then! 15:20:36 #topic Discussion 15:20:47 dtantsur: looks like this item is something you added? 15:21:00 Train branch status? 15:21:06 yes, thank you 15:21:32 It's a follow-up to the midcycle topic. I'm holding up the release proposed by the release team for ironic. 15:21:40 Since we have a few outstanding patches, and the gate does not seem to work. 15:21:57 So the pressing question is: should we fix it asap or should I give them go-ahead with the proposed release? 15:21:59 Do we have a list of issues or failed example jobs? 15:23:20 lemme see 15:23:25 It is a hard question to answer without being consciously aware the failures and what is outstanding 15:23:41 actually, the patch to remove grenade passed: https://review.opendev.org/c/openstack/ironic/+/773330/ 15:23:47 maybe it boils down to landing it 15:24:03 ship it! 15:24:06 * TheJulia adds +2 15:24:15 yeah ironic in train doesn't look that bad 15:24:30 okay, we're fine that. let's make sure to recheck any outstanding patches when this one lands 15:24:35 k 15:24:37 ++ 15:24:40 * dtantsur is ready to move on 15:24:46 Excellent! 15:24:49 Onward to the SIG 15:24:52 #topic Baremetal SIG 15:25:10 arne_wiebalck couldn't join us today, but he gave me a heads up for the SIG's next topic! 15:25:43 yep :) 15:25:47 Next week, dtantsur will be presenting deploy steps to the SIG! Hopefully we'll also see the previous recordings posted to youtube this week. 15:25:56 \o/ 15:26:09 Onward then! 15:26:16 #topic RFE Review 15:26:36 dtantsur: looks like you've proposed these three, do you want to walk us through them? 15:26:40 yup 15:26:56 #link https://storyboard.openstack.org/#!/story/2008567 Expose boot mode and secure boot status in the API 15:27:03 This should be more or less self-explanatory 15:27:21 Reading it, it seems reasonable 15:27:25 The only non-trivial bits: I'm proposing changing to be asynchronous (so unlike boot device and like power states) 15:27:45 Seems like it might be a bit unreliable on ipmi based machines, at least for boot_mode. 15:27:57 (because ipmi bmc response is not super reliable) 15:27:57 Boot mode API is not implemented for ipmitool 15:28:01 \o/ 15:28:04 nevermind then! 15:28:05 :) 15:28:31 I think it is good, I would consider these purely administrative endpoints for humans, not programmatic interaction which might be useful say as a member 15:28:37 of the system that is 15:28:51 * TheJulia now sees everything in RBAC terms :( 15:28:56 yep. and seeing these values in node listing may be really helpful for debugging 15:29:03 I have no objection to this change. 15:29:20 any other opinions? 15:29:23 the PUT API endpoints. 15:29:28 are they avail any time? 15:29:36 or only when the node is in certain states? 15:29:55 rloo: I'll check what we do for other actions, but likely in stable states only 15:30:04 i think it's depended? 15:30:05 (and without a reservation, of course) 15:30:23 ok thx, as long as consistent and makes sense, i think i'm good with it :) 15:30:50 if there is a failure, will last_error be updated? 15:31:13 guessing yes, that's what you mean by 'the only way... will be to poll the node'. 15:31:24 yep 15:31:43 Seems reasonable and hopefully we'll have node history soon() 15:31:53 Onward to the next rfe since this one seems "approved" 15:32:04 #link https://storyboard.openstack.org/#!/story/2008366 BMC event framework for ironic (reduced scope) 15:32:17 This is a lighter version of the RFE I've already proposed once 15:32:29 MVP without proxying by ironic 15:33:44 dtantsur: my feeling is "yes" to both of the questions at thebottom of the rfe 15:33:57 Seems reasonable to build one piece at a time. 15:35:06 why just active nodes. 15:35:38 That is a good question, but I think it helps curtail the action of having to remove/cleanup on deploy 15:36:10 i was wondering whether that info would be useful for debugging, if clean/deploy failed :) 15:36:27 hmm 15:36:46 so lets do this.. I think dmitry is trying to keep it skimmed down, but there may be value in persistent 15:36:48 am ok with the rfe. could start with active. and just stick with active. 15:36:52 so I think we need a class of two 15:37:03 yeah, relaxing restrictions is easier than adding them 15:37:16 (I don't remember why I settled on active only, probably for an absolute MVP) 15:37:18 would just like it documented why 'only' active. if it is for now only. 15:37:35 I think active only is fine for first pass and then we add a field for persistent or something 15:37:36 I'm fine with dropping this requirement, one fewer check in the code 15:37:49 or we could just drop the constraint 15:37:59 * TheJulia is fine either way and has no hard opinion 15:38:52 ++ for dropping =) 15:39:03 dtantsur: I guess update the rfe and your good to go 15:39:12 yup, will do after the meeting 15:39:13 so if i understand it. this provides an event framework. but at the end of this, one can't do much cuz the actual events won't be avail? 15:39:37 rloo: not the framework yet, more so the ability to change the knobs on the hardware 15:39:43 to eventually reach a framework 15:39:56 dtantsur if node is none-active, maybe subscribtion will fails? 15:40:16 Qianbiao: subscriptions themselves are not related to our states 15:40:29 Does creating a subscription mean registering an event subscriber? 15:40:32 like wrong credential 15:40:34 it will fail if the BMC has some problem =) 15:40:57 or your request has some problem to create the subscription 15:40:59 kaifeng: yep. you're providing a URL that will be called by the BMC in case of a hardware event (overheating etc) 15:41:34 like some admin tools of BMC :) 15:41:49 wow, I don't know BMC can do such a thing 15:41:58 What kind of events are expected from BMC? 15:42:10 things like overheating 15:42:17 I feel like the disconnect is modeled around the redfish events functionality 15:42:25 where the bmc can broadcast $things 15:42:33 but yeah, I don't define the data model, merely exposing what can be done already 15:42:37 ++ 15:42:42 if your BMC can do it, we can implement that as well 15:42:54 So will there be event catalog from Ironic and drivers needs to map it to their BMC and create a subscription? 15:43:08 there cannot be 15:43:36 so vendors have an open-ended capability to define these things, dmitry is just trying to propose the ability to add/remove subscriptions which is a defined feature of the standard 15:43:40 The events supported by BMC could differ from vendor to vendor... 15:43:50 the bmc then enumerates through the endpoints and transmits data to whereever the subscription defines 15:43:58 from family to family and even from model to model 15:44:22 in this case, it is not transmitting to ironic from what I understand 15:44:23 same situation as with BIOS settings: I don't think we can provide a catalog 15:44:31 I wonder who consumes the driver-specific-filters? 15:44:42 So 'filters' in the RFE is going to driver specific ? 15:44:43 kaifeng: the BMC at this point 15:44:45 yes 15:45:22 Then do we need some kind listing of supported filters by a driver? Or just refer doc for that 15:45:31 okay, if i get this rignt, the rfe is to implement a passthrough api to set up some event callback to the bmc 15:45:38 kaifeng: correct 15:46:41 sounds useful, so this is only applicable for the redfish right, do we have consistent support from the standard? 15:47:21 I haven't checked the real-life status, I must admit 15:47:48 I checked like a year ago and I think at least two vendors supported it 15:48:14 I think a third, you could see it was stubbed into place, but maybe not usable 15:48:17 I didn't dig much further 15:49:16 Anyway, I don't see any objections, just scoping questions 15:49:37 dtantsur: maybe a slight bit more clarity in the rfe and I suspect you'll be good 15:49:54 okay, I'll try to type some words and ping you later 15:50:16 TheJulia ibmc supports subscribtion 15:50:24 Qianbiao: good to know, thanks 15:50:28 Anything else? 15:50:31 dtantsur: ^^ 15:50:42 I have another one if we have time 15:50:50 I think we do 15:50:53 #link https://storyboard.openstack.org/#!/story/2008491 An ability to run manual cleaning without booting a ramdisk 15:51:06 This has been discussed many times as a nice-to-have thing 15:51:14 This is a concrete proposal 15:51:34 ++ 15:51:43 we've discussed this enough times I feel like this is good 15:51:44 this is a great feature 15:52:02 i tried some raid work last year and it appears that idrac actually doesn't need in-band at all 15:52:13 yes kaifeng 15:52:19 ibmc is the same. 15:52:41 for pure oob it would be a good enhancement 15:53:24 the major complaint in the past has been reset of the bmc where no other commands are permitted 15:53:25 We would very much appreciate this change. 15:53:38 #chair dtantsur 15:53:39 Current chairs: TheJulia dtantsur 15:53:44 I need to step away 15:54:49 k 15:55:19 I think we've agreed with the direction, what about the specific implementation proposal? 15:55:20 Qianbiao: good to know 15:56:18 * dtantsur usually assumes that crickets agree with him 15:56:50 For us, it is much more than a nice to have feature. The iDRAC can be placed in a a state in which it cannot be removed unless this feature is added. 15:57:34 If memory serves, it is called recovery mode. 15:58:13 yup 15:58:23 okay, back 15:58:37 Merged openstack/sushy master: Fix TaskMonitor constructor calls in volume.py https://review.opendev.org/c/openstack/sushy/+/773273 15:58:59 Sounds good, time to move on? 15:59:05 #topic Open Discussion 15:59:11 Any open items? 15:59:59 s/open/other? 16:00:10 * TheJulia hears crickets and thinks everyone has gone off to get more coffee 16:01:18 Well everyone! Thanks! 16:01:22 #endmeeting