15:00:26 <TheJulia> #startmeeting ironic
15:00:29 <rpioso> erbarr: ^^^
15:00:30 <openstack> Meeting started Mon Nov 23 15:00:26 2020 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'ironic'
15:00:35 <iurygregory> o/
15:00:35 <stendulker> o/
15:00:38 <rpioso> \o
15:00:44 <rloo> o/
15:00:46 <ajya> o/
15:00:51 <TheJulia> Good morning everyone!
15:00:57 <arne_wiebalck> o/
15:01:11 <rpittau> o/
15:01:14 <TheJulia> Our agenda can be found on the wiki, this week we have a number of items.
15:01:24 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:40 <TheJulia> #topic Announcements / Reminders
15:01:46 <TheJulia> First up!
15:02:24 <TheJulia> #info The TC has approved a new cycle goal which we did not incorporate into our planning to basically drive the migration to YAML only policy files.
15:02:32 <TheJulia> #link https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
15:02:43 <TheJulia> Secondly!
15:02:45 <dtantsur> o/
15:03:17 <TheJulia> #info iLO CI will be down for approximately 3 weeks due to a site power shutdown during the end of the year starting around ?December 18th?
15:03:55 <TheJulia> Last, but not least, at least for me.
15:04:36 <TheJulia> A reminder for everyone that this is a holiday week in the states. Many people tend to take some or this entire week off. And on that subject, I'll only be around Today and Tomorrow for this week.
15:04:50 <TheJulia> Dos anyone have anything to raise/announce/remind us of?
15:04:52 <iurygregory> enjoy the time off TheJulia =)
15:04:59 <dtantsur> ++
15:05:02 <openstackgerrit> Dmitry Tantsur proposed openstack/ironic-python-agent master: Copy any configuration from the virtual media  https://review.opendev.org/c/openstack/ironic-python-agent/+/763207
15:05:04 <TheJulia> I'll be writing for nonorimo
15:05:27 <iurygregory> we can probably mention we will have 2 new contributors since outreachy project was approved?
15:05:39 <TheJulia> (National Novel Writers Month)
15:05:55 <TheJulia> iurygregory: I hadn't even gotten to that email yet, if you wouldn't mind making the annoucement
15:05:56 <iurygregory> or wait for next monday since we will have the official email =)
15:06:08 <TheJulia> is it embargoed?
15:06:17 <openstackgerrit> vinay50muddu proposed openstack/ironic master: Add clean/deploy steps to manage certificates  https://review.opendev.org/c/openstack/ironic/+/763791
15:06:26 <TheJulia> or we can just be vague
15:06:29 <iurygregory> I only got the one saying that All interns are approved =)
15:06:34 <TheJulia> sweet
15:06:36 <TheJulia> Okay then
15:06:39 <iurygregory> so we will have 2 new contributors
15:07:25 <TheJulia> #info We will have 2 new contirbutors for this current Outreachy cycle.
15:07:37 <TheJulia> Anyway, I guess we can proceed if nobody has anything else?
15:07:41 <iurygregory> ++
15:07:53 <TheJulia> iurygregory: Your taking all of december off right?
15:07:59 <iurygregory> Yes
15:08:02 <TheJulia> k
15:08:08 * TheJulia makes a mental note to send an email today
15:08:43 <openstackgerrit> Dmitry Tantsur proposed openstack/ironic master: [WIP] inject TLS certificate when using virtual media  https://review.opendev.org/c/openstack/ironic/+/758427
15:09:00 <TheJulia> #topic Review action items from the prior week.
15:09:00 <stendulker> TheJulia: I will also be off for 2 weeks starting from Dec 18th.
15:09:10 <TheJulia> stendulker: thanks!
15:09:37 <TheJulia> We had one action item last week which was to get with stevebaker and start moving the API patches forward. Thanks everyone who helped push that forward!
15:10:02 <TheJulia> #topic Review subteam status reports
15:10:12 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:10:23 <TheJulia> Starting around line 260
15:11:33 <TheJulia> If everyone would update relevent sections on the etherpad
15:14:37 <arne_wiebalck> For the UEFI topic, is the plan to also include the re-factoring we skipped/postponed at the time for UEFI RAID? IIRC, this was around grub2install vs efibootmgr ... or is UEFI happy enough without this? ,)
15:14:49 <arne_wiebalck> ;)
15:15:05 <dtantsur> it's probably worth at least taking a look
15:15:16 <arne_wiebalck> dtantsur: ++
15:15:28 <TheJulia> I was pondering that and I'm kind of wondering if we get that for free
15:15:44 <TheJulia> already, but I may not completely understand the problem from the raid perspective
15:17:35 <arne_wiebalck> we wanted to get the UEFI code merged, and I was not keen on refactoring it at the time (b/c this would have required a lot of re-testing)
15:18:10 <TheJulia> arne_wiebalck: do you have a patch?
15:18:22 <arne_wiebalck> TheJulia: to refactor?
15:18:31 <TheJulia> yeah, sounds like one was started?
15:18:36 <arne_wiebalck> TheJulia: no
15:18:41 <TheJulia> okay, well... hmm
15:19:02 <TheJulia> I still think it may cover the case, but I'll need to look back at the comments and maybe discuss it further with you
15:19:12 <arne_wiebalck> TheJulia: ok!
15:19:24 <TheJulia> oh! it likely works for partition images now, but not wholedisk
15:19:37 <TheJulia> Taht is likely fairly easy to follow-up with
15:19:41 <dtantsur> if so, it needs fixing
15:19:57 <TheJulia> I think it is explictly cased out because it has to be handled differently
15:20:46 <TheJulia> fundimentally the patches I've been working on are bugfix soft of fixes since we're doing the wrong thing with the agent today and causing pain for deployments with partition iamges.
15:21:29 <arne_wiebalck> IIRC, it was mostly to not call grub2 anymore but efibootmgr instead (iurygregory was working on this area at the time, so things were a bit in flux)
15:21:31 * TheJulia adds notes int the etherpad
15:21:42 <arne_wiebalck> at the moment we have a big IF somewhere :-D
15:21:47 <iurygregory> we do
15:21:57 <iurygregory> when calling the install_bootloader if I do remember
15:22:09 <arne_wiebalck> iurygregory: right
15:22:10 <TheJulia> yeah
15:22:20 <openstackgerrit> Merged openstack/ironic-inspector stable/victoria: Use correct Node id attribute  https://review.opendev.org/c/openstack/ironic-inspector/+/763729
15:22:32 <TheJulia> Anyway, Is everyone good to proceed?
15:22:35 <iurygregory> ++
15:22:44 <openstackgerrit> John Garbutt proposed openstack/networking-generic-switch master: Add ngs_manage_vlans configuration  https://review.opendev.org/c/openstack/networking-generic-switch/+/763794
15:22:45 <dtantsur> yep
15:22:45 <arne_wiebalck> rpioso: rpittau: we should probably discuss how to move the interop profiles fwd
15:22:55 <TheJulia> #topic Deciding on priorities for the coming week
15:23:04 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:23:19 <TheJulia> Starting at line 121
15:23:41 <TheJulia> Looks like we got some stuff merged last week, and also the API work stevebaker largely merged which is absolutely awesome
15:23:58 * TheJulia removes merged items
15:25:13 <TheJulia> as for items to add, looks like items are appearing on line 196 and below
15:26:22 <dtantsur> yep, I've added a few things
15:27:27 <TheJulia> Does anyone have any objections on adding these items?
15:27:42 <dtantsur> btw we should have announced that most of the wsme removal has merged
15:28:07 <dtantsur> those who haven't been following it may experience shock next time they look at the API layer :D
15:28:15 <rloo> didn't the wallaby priorities get approved?
15:28:24 <rloo> line 122
15:28:48 <rloo> (still trying to get used to this new UI...)
15:28:48 <TheJulia> I just added two more related to the new cycle goal, which is mostly cookie cutter across repositories, the later step that community is starting to talk about is going to be more work
15:29:07 <TheJulia> rloo: good catch, removed
15:29:16 <TheJulia> dtantsur: ++ although haven't even seen that yet :(
15:29:30 <TheJulia> dtantsur: shock, and sudden waves of happiness? :)
15:29:34 <dtantsur> well, yes
15:29:52 <dtantsur> stevebaker has succeeded in reducing the amount of copy-paste in the API code very substantially
15:29:59 <dtantsur> like, 50% or more
15:30:07 <TheJulia> If there are no objections, then we should move on
15:30:18 <rloo> great job stevebaker!!!
15:30:23 <TheJulia> ++
15:30:59 <TheJulia> I'll move the proposed items in after the meeting
15:31:01 <TheJulia> Anyway, onward!
15:31:04 <TheJulia> #topic Discussion
15:31:58 <TheJulia> We have two-ish items for discussion. The first is ultimately sourced by a downstream bug I've got. We've observed a converged network/storage fabric adapter basically overloading the UEFI nvram boot entries list
15:32:35 <TheJulia> And while the card is well meaning, and it is definitely the wrong behavior for the card, an question of if the community would be receptive to a flag that says "ignore bootloader installation failures"?
15:32:46 <dtantsur> not yet, at least
15:32:46 <TheJulia> Any thoughts/concerns?
15:32:55 <dtantsur> I mean, does it mean the the OS simply won't boot?
15:33:02 <dtantsur> or will boot depending on how the stars align?
15:33:16 <TheJulia> The OS boots, because the card firmware goes and hunts down all the passible UEFI images
15:33:18 <TheJulia> possible
15:33:29 <TheJulia> which seems crazy, but it is doing it for all of the luns it is providing
15:33:42 <TheJulia> as well, so the machine ultimately does boot, it is just the nvram update that is blowing up
15:33:51 <TheJulia> We should be able to identify that
15:33:58 <iurygregory> ++
15:33:59 <dtantsur> and then the custom enables discovery in ironic-inspector and the machine starts booting into IPA?
15:34:04 <dtantsur> s/custom/customer/
15:34:26 <dtantsur> why cannot we add a boot entry? too many entries? hardware just rejects that?
15:34:28 <TheJulia> dtantsur: no, the card wants to boot to disk instead of network
15:34:41 <TheJulia> dtantsur: The table is full, literally overloaded to the point we cannot add new entries
15:34:48 <TheJulia> and we have no way of knowing what we can safely remove
15:34:50 <iurygregory> ouch
15:35:10 <TheJulia> yeah...
15:35:12 <dtantsur> can we try finding the corresponding disk entry?
15:35:59 <stendulker> cant we add explicit entry for the device that was provisioned and remove all other entries?
15:36:09 <dtantsur> note that linux probably won't work normally on such system anyway
15:36:10 <TheJulia> possibly, but maybe not since they are all oriented to the way the UEFI firmware views the hardware
15:36:19 <TheJulia> stendulker: that is another possibility
15:36:23 <dtantsur> because at least Red Hat shim tries to recover an UEFI record under some conditions
15:36:23 <arne_wiebalck> why would we need to preserve existing entries?
15:36:42 <dtantsur> very interesting reading: https://github.com/rhboot/shim/blob/a1170bb00a116783cc6623b403e785d86b2f97d7/README.fallback#L33-L46
15:36:42 <TheJulia> arne_wiebalck: ++
15:36:46 * dtantsur knows a lot of weird stuff like that now
15:37:35 <TheJulia> Yup, that is basically what the card is doing, populating all of the paths that seem possible with bootlaoders :\
15:37:42 <TheJulia> and it may not even hold past reboot, that is the other frustrating thing
15:38:08 <TheJulia> since they can pull/re-insert the card with out changing anything and the list of uefi boot targets explodes in nvram
15:38:19 <dtantsur> wow
15:38:37 <dtantsur> okay, it does sound like a skip_bootloader flag with an appropriate documentation note (use at your own risk)
15:38:48 <TheJulia> That is kind of what I was thinking
15:39:02 <TheJulia> anyway, one more discussion topic and two RFEs
15:39:06 <dtantsur> if we had this problem on my laptop, we could remove "LENOVO CLOUD" :D
15:39:09 <TheJulia> arne_wiebalck: premeptive ask on baremetal sig, anything to cover
15:39:17 * TheJulia blinks at dtantsur
15:39:25 <dtantsur> I'm serious, I have this entry
15:39:31 <TheJulia> Second discussion topic!
15:39:34 <TheJulia> dtantsur: I'm afraid
15:39:41 <arne_wiebalck> TheJulia: Next meeting #3 Tue Dec 8, 2020 at 2pm UTC with rpioso on interop profiles, otherwise NTR
15:40:34 <TheJulia> As previously noted the TC has approved an additional effort for this cycle to migrate json policy files to drive the migration of JSON policy files to YAML. This is viewed as a stepping stone for the secure RBAC work that is starting to be discussed which may bring many projects many headaches
15:40:37 <TheJulia> #link https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
15:41:38 <dtantsur> Just Do It (tm)
15:41:47 <TheJulia> Well, patches for that are up :)
15:41:57 <iurygregory> I was about to say that
15:42:27 <TheJulia> Lance has propsed a series of patches converting our policies to the secure rbac model, however without additional testing and that is going to drive additional discussion. I guess the question I have is should we add this to the project level cycle priorities?
15:43:05 <dtantsur> I assume we have to?
15:43:06 <TheJulia> FWIW, those patches were on ironic, not ironic-inspector.
15:43:41 <TheJulia> dtantsur: I suspect yes, I'm also curious how receptive will people be if we push forward on RBAC model changes
15:44:11 <rloo> yes, i think to support community priorities, etc, let's update our priorities to reflect that. Assuming we want to do that work this cycle...
15:44:13 <dtantsur> I think it's a question for operators, not for us
15:45:04 <TheJulia> dtantsur: Good point, I know some operators want it, I guess we need to map out the entire scope of what is imapcted and what needs to be touched in the larger case
15:45:17 <TheJulia> I've already started tinking in that direction so I can keep heading in that direction.
15:45:30 <TheJulia> Anyway, we should move on if there are no last minute discussion thoughts?
15:45:51 <TheJulia> #topic Baremetal SIG
15:46:07 <TheJulia> #info Next Meeting - December 8th at 2PM UTC
15:46:16 <TheJulia> #link https://etherpad.opendev.org/p/bare-metal-sig
15:46:19 <TheJulia> #topic RFE Review
15:46:33 * TheJulia hands the microphone to dtantsur
15:46:40 <dtantsur> thank you
15:46:47 <dtantsur> #link https://storyboard.openstack.org/#!/story/2008380 Configdrive with virtual media ramdisk ISO deploy
15:47:14 <dtantsur> the ramdisk deploy does not have support for configdrive
15:47:18 <dtantsur> I have a feeling that we can make it work for redfish-virtual-media
15:47:37 <dtantsur> since a lot of hardware (I tested 2 Dells and 1 HPE) seems to have a USB virtual media slot in addition to ISO
15:47:51 <TheJulia> I guess we would end up with maybe an additional boot interface method or two to facilitate this?
15:48:09 <TheJulia> or would we try to entirely do this inside of the boot interface?
15:48:23 <dtantsur> I haven't looked in depth what it involves
15:48:27 <TheJulia> Okay
15:48:30 <dtantsur> likely an extension of the boot interface indeed
15:48:43 <dtantsur> unless we can roll it into prepare_instance
15:48:49 <dtantsur> which is not unlikely, now that I'm thinking about it
15:48:51 <TheJulia> I guess I'd kind of like to see patches to better understand. It seems logical to me for the most part
15:49:04 <TheJulia> I'd prefer not to roll it in to prepare_instance directly
15:49:39 <TheJulia> Anyway I'm not opposed, I like the idea. Anyone else have any thoughts on this one?
15:49:40 <dtantsur> yeah, I need to see patches myself :) I want to have a prototype this week
15:50:08 <TheJulia> Okay, seems like we should try to revisit this next week :)
15:50:12 <TheJulia> but otherwise, I like the idea
15:50:17 <Qianbiao> dtantsur why not just use virtual media it self
15:50:33 <dtantsur> Qianbiao: with the ramdisk deploy we'd like to avoid changing the provided ISO
15:50:47 <Qianbiao> i see.
15:51:13 <TheJulia> I think the idea is also attach to have it be natively detected
15:51:22 <TheJulia> as a device with a label that is read
15:51:25 <Qianbiao> maybe we can provide an option, if user desired to use iso
15:51:26 <TheJulia> which kind of makes sense
15:51:37 <dtantsur> Qianbiao: your hardware doesn't have a USB slot?
15:51:46 <Qianbiao> Not sure, will ask
15:51:55 <dtantsur> please check, it's useful input for us
15:52:03 <TheJulia> Next RFE?
15:52:08 <Qianbiao> sure
15:52:19 <dtantsur> #link https://storyboard.openstack.org/#!/story/2008366 BMC event framework
15:52:29 <dtantsur> okay, this qualifies for a loong spec, but I'd like some early input :)
15:52:42 <dtantsur> and note that I may not be able to work on it in the near future
15:52:55 <dtantsur> depending on how the priorities align downstream
15:52:57 <TheJulia> This may also funnel into "Maybe hack out another API service"
15:53:14 <TheJulia> I like the idea a lot
15:53:30 <dtantsur> I still think the complexity of maintaining another service does not justify the benefits
15:53:34 <dtantsur> but we may discuss :)
15:53:51 <TheJulia> And truthfully there are a number of ideas there, but it does solve a conundrum and help operators keep their BMC's further insulated by adding intermediate mechanisms
15:54:00 * dtantsur gives everyone a chance to scroll through
15:54:27 <TheJulia> dtantsur: well, it could still be in the project and just be an increadible skimmed down API, but as you also pointed out it could just be an operating mode flag.
15:54:35 <TheJulia> much as we have lookup today
15:55:49 <TheJulia> It is a lot to take in, I guess it helps a lot that I've already read the earlier version
15:55:55 <dtantsur> right
15:56:07 <dtantsur> I'm looking for yay/nay/wtf reactions
15:56:25 <rpittau> yay from me
15:56:27 <rpittau> :)
15:56:31 <TheJulia> I'm basically yay because we've had operators ask about similar things before
15:56:43 <iurygregory> yay for me also
15:56:49 <TheJulia> the whole unfortunate thing is the nature of redfish events and the mechanics there in
15:57:13 <TheJulia> I do like the idea of maybe later storing, but with that comes great risk and would likely be what operators expect behavior/mechanics wise
15:57:27 <TheJulia> Well, then!
15:57:30 <TheJulia> I think we can move on!
15:57:42 <dtantsur> yep, I welcome any comments later on
15:57:42 * TheJulia moves on because people can still yay/nay/wtf in open discussion
15:57:48 <TheJulia> #topic Open Discussion
15:57:56 <TheJulia> So 3 minutes left, we've covered a LOT!
15:58:03 <TheJulia> Does anyone have anything else to dsicuss?
15:59:07 <rpittau> crickets say no
15:59:29 <TheJulia> Seems like it
15:59:48 <TheJulia> Well, thanks everyone!
15:59:53 <iurygregory> ty
15:59:56 <rpittau> thanks!
15:59:57 <TheJulia> Have a wonderful week!
16:00:18 <arne_wiebalck> thanks TheJulia
16:00:23 <kaifeng> thannks Julia
16:00:23 <dtantsur> o/
16:00:29 <TheJulia> #endmeeting