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