15:00:26 #startmeeting ironic 15:00:29 erbarr: ^^^ 15:00:30 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:33 The meeting name has been set to 'ironic' 15:00:35 o/ 15:00:35 o/ 15:00:38 \o 15:00:44 o/ 15:00:46 o/ 15:00:51 Good morning everyone! 15:00:57 o/ 15:01:11 o/ 15:01:14 Our agenda can be found on the wiki, this week we have a number of items. 15:01:24 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:01:40 #topic Announcements / Reminders 15:01:46 First up! 15:02:24 #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 #link https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html 15:02:43 Secondly! 15:02:45 o/ 15:03:17 #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 Last, but not least, at least for me. 15:04:36 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 Dos anyone have anything to raise/announce/remind us of? 15:04:52 enjoy the time off TheJulia =) 15:04:59 ++ 15:05:02 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 I'll be writing for nonorimo 15:05:27 we can probably mention we will have 2 new contributors since outreachy project was approved? 15:05:39 (National Novel Writers Month) 15:05:55 iurygregory: I hadn't even gotten to that email yet, if you wouldn't mind making the annoucement 15:05:56 or wait for next monday since we will have the official email =) 15:06:08 is it embargoed? 15:06:17 vinay50muddu proposed openstack/ironic master: Add clean/deploy steps to manage certificates https://review.opendev.org/c/openstack/ironic/+/763791 15:06:26 or we can just be vague 15:06:29 I only got the one saying that All interns are approved =) 15:06:34 sweet 15:06:36 Okay then 15:06:39 so we will have 2 new contributors 15:07:25 #info We will have 2 new contirbutors for this current Outreachy cycle. 15:07:37 Anyway, I guess we can proceed if nobody has anything else? 15:07:41 ++ 15:07:53 iurygregory: Your taking all of december off right? 15:07:59 Yes 15:08:02 k 15:08:08 * TheJulia makes a mental note to send an email today 15:08:43 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 #topic Review action items from the prior week. 15:09:00 TheJulia: I will also be off for 2 weeks starting from Dec 18th. 15:09:10 stendulker: thanks! 15:09:37 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 #topic Review subteam status reports 15:10:12 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:10:23 Starting around line 260 15:11:33 If everyone would update relevent sections on the etherpad 15:14:37 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 ;) 15:15:05 it's probably worth at least taking a look 15:15:16 dtantsur: ++ 15:15:28 I was pondering that and I'm kind of wondering if we get that for free 15:15:44 already, but I may not completely understand the problem from the raid perspective 15:17:35 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 arne_wiebalck: do you have a patch? 15:18:22 TheJulia: to refactor? 15:18:31 yeah, sounds like one was started? 15:18:36 TheJulia: no 15:18:41 okay, well... hmm 15:19:02 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 TheJulia: ok! 15:19:24 oh! it likely works for partition images now, but not wholedisk 15:19:37 Taht is likely fairly easy to follow-up with 15:19:41 if so, it needs fixing 15:19:57 I think it is explictly cased out because it has to be handled differently 15:20:46 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 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 at the moment we have a big IF somewhere :-D 15:21:47 we do 15:21:57 when calling the install_bootloader if I do remember 15:22:09 iurygregory: right 15:22:10 yeah 15:22:20 Merged openstack/ironic-inspector stable/victoria: Use correct Node id attribute https://review.opendev.org/c/openstack/ironic-inspector/+/763729 15:22:32 Anyway, Is everyone good to proceed? 15:22:35 ++ 15:22:44 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 yep 15:22:45 rpioso: rpittau: we should probably discuss how to move the interop profiles fwd 15:22:55 #topic Deciding on priorities for the coming week 15:23:04 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:23:19 Starting at line 121 15:23:41 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 as for items to add, looks like items are appearing on line 196 and below 15:26:22 yep, I've added a few things 15:27:27 Does anyone have any objections on adding these items? 15:27:42 btw we should have announced that most of the wsme removal has merged 15:28:07 those who haven't been following it may experience shock next time they look at the API layer :D 15:28:15 didn't the wallaby priorities get approved? 15:28:24 line 122 15:28:48 (still trying to get used to this new UI...) 15:28:48 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 rloo: good catch, removed 15:29:16 dtantsur: ++ although haven't even seen that yet :( 15:29:30 dtantsur: shock, and sudden waves of happiness? :) 15:29:34 well, yes 15:29:52 stevebaker has succeeded in reducing the amount of copy-paste in the API code very substantially 15:29:59 like, 50% or more 15:30:07 If there are no objections, then we should move on 15:30:18 great job stevebaker!!! 15:30:23 ++ 15:30:59 I'll move the proposed items in after the meeting 15:31:01 Anyway, onward! 15:31:04 #topic Discussion 15:31:58 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 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 not yet, at least 15:32:46 Any thoughts/concerns? 15:32:55 I mean, does it mean the the OS simply won't boot? 15:33:02 or will boot depending on how the stars align? 15:33:16 The OS boots, because the card firmware goes and hunts down all the passible UEFI images 15:33:18 possible 15:33:29 which seems crazy, but it is doing it for all of the luns it is providing 15:33:42 as well, so the machine ultimately does boot, it is just the nvram update that is blowing up 15:33:51 We should be able to identify that 15:33:58 ++ 15:33:59 and then the custom enables discovery in ironic-inspector and the machine starts booting into IPA? 15:34:04 s/custom/customer/ 15:34:26 why cannot we add a boot entry? too many entries? hardware just rejects that? 15:34:28 dtantsur: no, the card wants to boot to disk instead of network 15:34:41 dtantsur: The table is full, literally overloaded to the point we cannot add new entries 15:34:48 and we have no way of knowing what we can safely remove 15:34:50 ouch 15:35:10 yeah... 15:35:12 can we try finding the corresponding disk entry? 15:35:59 cant we add explicit entry for the device that was provisioned and remove all other entries? 15:36:09 note that linux probably won't work normally on such system anyway 15:36:10 possibly, but maybe not since they are all oriented to the way the UEFI firmware views the hardware 15:36:19 stendulker: that is another possibility 15:36:23 because at least Red Hat shim tries to recover an UEFI record under some conditions 15:36:23 why would we need to preserve existing entries? 15:36:42 very interesting reading: https://github.com/rhboot/shim/blob/a1170bb00a116783cc6623b403e785d86b2f97d7/README.fallback#L33-L46 15:36:42 arne_wiebalck: ++ 15:36:46 * dtantsur knows a lot of weird stuff like that now 15:37:35 Yup, that is basically what the card is doing, populating all of the paths that seem possible with bootlaoders :\ 15:37:42 and it may not even hold past reboot, that is the other frustrating thing 15:38:08 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 wow 15:38:37 okay, it does sound like a skip_bootloader flag with an appropriate documentation note (use at your own risk) 15:38:48 That is kind of what I was thinking 15:39:02 anyway, one more discussion topic and two RFEs 15:39:06 if we had this problem on my laptop, we could remove "LENOVO CLOUD" :D 15:39:09 arne_wiebalck: premeptive ask on baremetal sig, anything to cover 15:39:17 * TheJulia blinks at dtantsur 15:39:25 I'm serious, I have this entry 15:39:31 Second discussion topic! 15:39:34 dtantsur: I'm afraid 15:39:41 TheJulia: Next meeting #3 Tue Dec 8, 2020 at 2pm UTC with rpioso on interop profiles, otherwise NTR 15:40:34 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 #link https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html 15:41:38 Just Do It (tm) 15:41:47 Well, patches for that are up :) 15:41:57 I was about to say that 15:42:27 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 I assume we have to? 15:43:06 FWIW, those patches were on ironic, not ironic-inspector. 15:43:41 dtantsur: I suspect yes, I'm also curious how receptive will people be if we push forward on RBAC model changes 15:44:11 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 I think it's a question for operators, not for us 15:45:04 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 I've already started tinking in that direction so I can keep heading in that direction. 15:45:30 Anyway, we should move on if there are no last minute discussion thoughts? 15:45:51 #topic Baremetal SIG 15:46:07 #info Next Meeting - December 8th at 2PM UTC 15:46:16 #link https://etherpad.opendev.org/p/bare-metal-sig 15:46:19 #topic RFE Review 15:46:33 * TheJulia hands the microphone to dtantsur 15:46:40 thank you 15:46:47 #link https://storyboard.openstack.org/#!/story/2008380 Configdrive with virtual media ramdisk ISO deploy 15:47:14 the ramdisk deploy does not have support for configdrive 15:47:18 I have a feeling that we can make it work for redfish-virtual-media 15:47:37 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 I guess we would end up with maybe an additional boot interface method or two to facilitate this? 15:48:09 or would we try to entirely do this inside of the boot interface? 15:48:23 I haven't looked in depth what it involves 15:48:27 Okay 15:48:30 likely an extension of the boot interface indeed 15:48:43 unless we can roll it into prepare_instance 15:48:49 which is not unlikely, now that I'm thinking about it 15:48:51 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 I'd prefer not to roll it in to prepare_instance directly 15:49:39 Anyway I'm not opposed, I like the idea. Anyone else have any thoughts on this one? 15:49:40 yeah, I need to see patches myself :) I want to have a prototype this week 15:50:08 Okay, seems like we should try to revisit this next week :) 15:50:12 but otherwise, I like the idea 15:50:17 dtantsur why not just use virtual media it self 15:50:33 Qianbiao: with the ramdisk deploy we'd like to avoid changing the provided ISO 15:50:47 i see. 15:51:13 I think the idea is also attach to have it be natively detected 15:51:22 as a device with a label that is read 15:51:25 maybe we can provide an option, if user desired to use iso 15:51:26 which kind of makes sense 15:51:37 Qianbiao: your hardware doesn't have a USB slot? 15:51:46 Not sure, will ask 15:51:55 please check, it's useful input for us 15:52:03 Next RFE? 15:52:08 sure 15:52:19 #link https://storyboard.openstack.org/#!/story/2008366 BMC event framework 15:52:29 okay, this qualifies for a loong spec, but I'd like some early input :) 15:52:42 and note that I may not be able to work on it in the near future 15:52:55 depending on how the priorities align downstream 15:52:57 This may also funnel into "Maybe hack out another API service" 15:53:14 I like the idea a lot 15:53:30 I still think the complexity of maintaining another service does not justify the benefits 15:53:34 but we may discuss :) 15:53:51 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 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 much as we have lookup today 15:55:49 It is a lot to take in, I guess it helps a lot that I've already read the earlier version 15:55:55 right 15:56:07 I'm looking for yay/nay/wtf reactions 15:56:25 yay from me 15:56:27 :) 15:56:31 I'm basically yay because we've had operators ask about similar things before 15:56:43 yay for me also 15:56:49 the whole unfortunate thing is the nature of redfish events and the mechanics there in 15:57:13 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 Well, then! 15:57:30 I think we can move on! 15:57:42 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 #topic Open Discussion 15:57:56 So 3 minutes left, we've covered a LOT! 15:58:03 Does anyone have anything else to dsicuss? 15:59:07 crickets say no 15:59:29 Seems like it 15:59:48 Well, thanks everyone! 15:59:53 ty 15:59:56 thanks! 15:59:57 Have a wonderful week! 16:00:18 thanks TheJulia 16:00:23 thannks Julia 16:00:23 o/ 16:00:29 #endmeeting