15:00:19 #startmeeting ironic 15:00:20 o/ 15:00:20 Meeting started Mon Oct 7 15:00:19 2019 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:24 The meeting name has been set to 'ironic' 15:00:28 o/ everyone 15:00:29 o/ 15:00:30 \o 15:00:31 \o 15:00:45 o/ 15:00:48 rpioso: I guess we'll get to that topic, just curious after reading the meeting agenda 15:00:52 o/ 15:00:55 o/ 15:00:58 \o 15:01:02 TheJulia: ack 15:01:05 Greetings everyone! 15:01:14 Our meeting agenda can be found on the wiki! 15:01:29 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:01:32 \o 15:02:04 o/ 15:02:09 #topic Announcements / Reminders 15:02:26 I guess I can say I'm back! Until Shanghai that is. 15:02:33 \o/ 15:02:58 A quick reminder, The Shanghai summit is in just about one month, so I'm sure presentations will be the order of the coming weeks. 15:03:12 Does anyone have any reminders or things they would like to announce? 15:03:53 o/ 15:04:01 (o/) 15:04:08 o/ 15:04:33 Speaking of reminders! I guess if there are any thoughts for things that need to be discussed during the PTG, it would be good to add/note that on the etherpad. 15:04:52 #link https://etherpad.openstack.org/p/PVG-Ironic-Planning 15:05:15 \o (sorry I'm late) 15:05:35 no worries! 15:05:59 Looks like we had no action items from the last meeting, so I guess we can jump directly to subteam status review if there are no objections? 15:06:29 * iurygregory in doubt why the etherpad has PVG o.o 15:07:06 iurygregory: Shanhai Pudong International Airport 15:07:10 Shanghai 15:07:16 lol 15:07:19 good! 15:07:51 Moving on 15:07:55 #topic Review subteam status reports 15:08:05 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:08:25 Starting around line 226 15:09:09 Who's taking over the Bare Metal Program from hogepodge? 15:10:01 FWIU the fondation will not have the resources to have someone working on this. 15:10:12 foundation 15:10:13 Taht is a very good question rpioso 15:10:50 I did reach out to the foundation, after discussing this with arne_wiebalck, to at least identify a primary point of contact that we as a larger community could co-ordinate with on such things should the community carry things forward. 15:11:32 I suspect my email was lost, because multiple people were posting from all sorts of places around the world around and after I sent the emails, so I'll try to follow-up in a few days 15:11:54 TheJulia: I look forward to hearing what you learn. arne_wiebalck, TheJulia: Thank you! 15:12:52 A question popped up on the etherpad regarding python 2.x testing, and I believe we can start to drop py2 testing this cycle. We should likely make sure all of our jobs are py3 soon-ish. 15:13:11 Would someone be willing to take the action item to check the documentation and let us know? 15:13:19 TheJulia: that was my question as I saw some projects already starting tp drop py2 testing 15:13:29 I think we have python3 jobs for all projects 15:13:46 maybe bifrost doesn't 15:13:49 iurygregory: our integration tests are still somewhat mixed unless we quietly changed the defaults all over and didn't fix job names 15:13:53 TheJulia, I will check the documentation. Thanks! 15:14:01 TheJulia: I can check that, can't wait to get rid of Py 2 :D 15:14:22 #action mkrai to check Python testing documentation and let us know when we can begin removing python2 15:14:33 rpittau: So... Python3.8 is something else we need to circle back kto 15:14:53 TheJulia, i can look at the integration tests 15:14:58 TheJulia: yep, and py3.7 too, like oslo.db min version compatibility 15:15:11 #link https://etherpad.openstack.org/p/Python_3.8_Deprecation_Hunt 15:15:34 iurygregory: action item for you to check py3.8 unit testing? or am I misinterpretting your comment 15:15:38 oh 15:15:40 integration tests 15:15:42 okay 15:15:47 * TheJulia needs more coffee 15:15:59 #action iurygregory to look at changing all of our integration tests over to py3 15:16:13 TheJulia: I'll keep working on py38 and py37 15:16:25 iurygregory: one thing to keep in mind, we have a duplicate or two for jobs that were cross py2/py3 15:16:34 iurygregory: so we can remove the duplicate :) 15:16:37 that uses py2 15:17:00 #action rpittau to look at py37/py38 comparability issues 15:17:07 TheJulia, ack 15:17:44 arne_wiebalck: so we got power callback done this cycle, but nothing state wise right? 15:17:54 TheJulia: correct 15:17:58 okay 15:18:34 So that is largely the list. I think those action items do cover the most important things in the next few weeks which should set us on a good path for the next cycle. 15:19:10 Is everyone ready to move on? 15:19:33 let's 15:19:50 #topic Priorities for the coming week 15:19:56 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:20:14 Starting at line 151 15:21:03 So it looks like most of the items from last week need some reviews/rebases, or revision. I think we just clean the list up and use it as is for this week. That is unless there are additional items people are aware of at this time? 15:21:54 * TheJulia removes merged items from the list 15:21:57 I added https://review.opendev.org/686965 to the backports section. 15:21:58 patch 686965 - networking-baremetal (stable/train) - Fix unit tests with ironicclient >=3.0.0 - 1 patch set 15:22:21 this ^^ has 1 +2 15:22:40 That seems reasonable 15:22:42 Anything else? 15:22:46 Any other backports? 15:23:13 yep, the log level change 15:23:22 https://review.opendev.org/#/q/b8fa188a29481b11b2f3117cdeecfd920a8f5a0e 15:24:03 .. if puppet-ironic counts - https://review.opendev.org/#/q/Ic95dbf1867fb5397f1b6d8f23466910a97051cb6 15:24:06 Anything else today? 15:24:10 I added this to the ironic list https://review.opendev.org/#/c/675853/ 15:24:11 patch 675853 - ironic - Add support for replacing WSME - 3 patch sets 15:24:24 hjensas: largely that is TripleO controlled, we don't have have rights on puppet-ironic 15:24:30 mkrai: thanks 15:24:33 That seems reasonable 15:24:36 TheJulia: ack 15:24:39 hjensas: no train yet for puppet-ironic ? 15:24:50 mkrai: adding a quick description 15:25:01 mkrai: nevermind, I see you just did it! 15:25:01 Im core on puppet-ironic 15:25:04 Thanks! 15:25:11 rpittau: the change merged before train was cut on master. 15:25:13 TheJulia, Thanks! 15:25:22 hjensas: oh kk thanks 15:25:32 hjensas, +A on puppet-ironic =) 15:25:38 \o/ 15:25:41 iurygregory: thank. 15:25:42 Excellent! 15:25:47 Anything else before we move on? 15:27:18 Then I guess we're good to move to Discussion 15:27:21 #topic Discussion 15:27:46 First discussion item comes from rpioso! 15:28:09 TheJulia: Thank you 15:28:15 rpioso: Would you like to describe the situation and root problem that exists? 15:28:26 Absolutely 15:28:56 About a year ago, Dell EMC added UEFI boot mode support to the idrac hardware type. 15:29:43 At that time, we did not realize IPA in-band inspection sets boot_mode on the ironic node. 15:30:17 For UEFI boot mode, it must be set to 'uefi'; otherwise, deployment fails. 15:30:54 If we had known about IPA's behavior, idrac's out-of-band inspection would have been changed to do the same. 15:31:19 However, at the time, we were not aware of it. 15:31:29 Okay, so what actually fails today? 15:31:36 Therefore, we have always considered it a bug. 15:32:08 Where does a deployment fail today? 15:32:25 If memory serves, every booting of the ramdisk. 15:32:47 So your saying, UEFI ramdisk booting is broken on idrac hardware? 15:33:00 the driver interaction their-in 15:33:05 When boot_mode is not set to 'uefi'. 15:33:45 if the user uses IB inspection, then it works fine. if they use OOB introspection then it doesn't work because OOB introspection does not set boot_mode 15:33:59 Right! IPA in-band inspection causes it to be automagically set. 15:34:14 needless to say, this can be very confusing and lead to a bad user experience 15:35:34 agreed, also seems rather confusing. So the minimal impact fix sounds like boot mode should be set as part of OOB inspection? Or should boot mode be asserted just prior to ramdisk being booted? I thought the latter is what we ended up doing and should be in the code paths, however it may rely upon an method that might not be present for idrac or something along those lines 15:36:12 so what is the question at hand here? 15:36:14 Why do you need to set boot mode in OOB inspection? Do you power on the node? 15:36:24 jroll: they want to backport a fix 15:36:42 well, feature/fix which entirely depends on point of view. 15:36:47 TheJulia: thanks, that's what I thought, just making sure 15:36:54 We strongly prefer the former, so that OOB inspection is on par with in-band. That what the topic's change proposes. 15:38:07 * TheJulia gives coffee to the opendev webpage 15:39:16 * iurygregory hopes TheJulia is not using google-chrome, otherwise she would need to give memory 15:39:27 iurygregory: heh 15:39:30 both tonyb and dtantsur|afk indicate that they believe it is a feature, though they seem close to the line 15:39:52 I tend to trust their opinion, personally 15:39:54 jroll: where do you see that? 15:40:03 TheJulia: comments in https://review.opendev.org/#/c/656425/2 15:40:03 patch 656425 - ironic (stable/rocky) - Set boot_mode in node properties during OOB Intros... - 2 patch sets 15:40:04 I ask because there was another issue that was similar in nature 15:40:14 it seems like a feature to me. but it causes problems cuz w/o it, things are inconsistent to your customers/users. 15:40:20 stendulker, we don't want to set boot mode on the server, we want to discover what boot mode the server is set to as part of OOB inspection. this will make servers that are in uefi boot mode "just work" 15:40:54 cdearborn: oh ok. Thanks. 15:41:10 so this change went into master in March -- is that in Stein then? 15:41:32 Separate change, the change being asked abou tis 15:41:57 rloo: it is in stein 15:41:59 oh, nope 15:42:02 sorry, is there a PR to backport this already? i thought that as the link jroll gave 15:42:02 I'm wrong 15:42:14 rloo: sorry, I got confused 15:42:16 656425 is the rocky backport, yes 15:42:44 and who has a link to the docs wrt backporting so I can read/remember what is allowed? 15:42:59 https://docs.openstack.org/project-team-guide/stable-branches.html 15:43:08 I need to dig through through the code because there seems to be a separate bug 15:43:24 Which should negate the need to make any change to the inspection path 15:43:27 rocky is in "maintained" mode per https://releases.openstack.org 15:45:17 actually, re-reading the "appropriate fixes" section, I'm probably +0 on backporting this. I believe it's technically a feature, if we're only looking at inspector. if we're looking at a full baremetal environment/workflow, it seems like more of a bug. it definitely fits the criteria given here, otherwise. 15:45:40 I believe idrac UEFI boot mode support landed in Queens. 15:46:05 A very similar idrac bug fix/feature was recently backported and merged into stable/rocky, https://review.opendev.org/#/c/648360/ 15:46:05 patch 648360 - ironic (stable/rocky) - DRAC: Fix OOB introspection to use pxe_enabled fla... (MERGED) - 32 patch sets 15:46:32 That merged change simplified the already small-ish change we're discussing. 15:46:33 Some types of changes are completely forbidden: New features 15:46:46 the 'story' is an RFE: https://storyboard.openstack.org/#!/story/2005119 15:46:51 We're discussing what Dell EMC has viewed as a bug from day one. 15:47:04 The Story also doesn't have the level of detail that we now understand through the meeting 15:47:14 rpioso: is that the story ^^ ? 15:47:32 Nobody has asked the reverse question: if this patch were backported, what's the likelyhook that it would break an existing user 15:47:34 if it doesn't have the level of detail -- shouldn't someone update it? 15:47:44 rloo: We didn't label it that. 15:47:48 it sounds like pretty close to zero if it's considered a bug by iDRAC users? 15:47:57 In late 2017, we retooled boot mode setting code, in that process the prepare_ramdisk method should be setting the boot mode as user/system requested, so completely absent is a valid case for a user 15:48:14 * jroll adds a full comment and a +1 on https://review.opendev.org/#/c/656425 15:48:15 patch 656425 - ironic (stable/rocky) - Set boot_mode in node properties during OOB Intros... - 2 patch sets 15:48:38 rpioso: if you didn't label it that, and given the docs wrt backporting, how would you decide, given the current description in the story? 15:49:12 so i'm fine wrt the impact, risk etc. all are low and to make things consistent, it makes sense. 15:49:31 so I see the issue with the code since 2017, the idrac management interfaces lack the get/set bood mode methods 15:49:40 however, whoever wants this change, needs to do their part (which i guess they're doing now). but change that to a bug not an rfe. or at least elaborate in the story. 15:49:51 rloo: +++ 15:50:07 TheJulia: Correct. They're optional methods. 15:50:28 not if you want boot mode assetion to work correctly for your hardware type prior to ramdisk booting 15:50:30 the fact that the release note claims it as a feature tells me that Dell EMC has not viewed this as a bug from day one 15:50:36 https://review.opendev.org/#/c/656425/2/releasenotes/notes/set-boot-mode-4c42b3fd0b5f5b37.yaml 15:50:37 patch 656425 - ironic (stable/rocky) - Set boot_mode in node properties during OOB Intros... - 2 patch sets 15:50:53 jroll: dtantsur tagged it as an RFE. We did not agree with that. 15:50:59 that said, I'm good with backporting it 15:51:02 Still don't. 15:51:32 A follow-on change could change the release note from feature to bug fix. 15:51:52 sure, I said the same in the rocky review 15:52:01 If we can clarify what is broken in the user experience/interaction and focus on that, then I think that would be the correct path for mutual understanding as well. 15:52:42 anyway, I think from a user POV, this is a bug. from an ironic ecosystem POV, it's a bug. for inspector specifically, it's a feature. the right thing to do is to backport it. 15:52:54 TheJulia: We're glad to do that. Where? 15:53:41 rpioso: In a story in storyboard so we focus on what is broken, the bug 15:54:09 TheJulia: +1 15:54:40 I completely agree with jroll, it is all about how the context is set for reviewers 15:54:41 TheJulia: May the existing story be updated. 15:54:52 yes, please add a task to the changeset 15:54:58 the task: ##### tag 15:55:27 Hrm ... the original change doesn't have a tag :-( 15:55:32 I have to run for another meeting - please ping me to make my +1 a +2 if we end up agreeing to backport it :) 15:55:38 It is fine to edit the commit message 15:55:43 +1 15:56:05 jroll: I think we agree, but I need to clear my mind... and do expense reporting first :) 15:56:35 +1 thx much! 15:56:41 Thank you! 15:56:47 sure, no rush :) 15:56:51 Okay, we have like four minutes left 15:57:17 I think we'll skip RFE review and just jump to open discussion for a couple minutes 15:57:25 And we can review the RFE next week 15:57:31 (For context, that RFE is https://storyboard.openstack.org/#!/story/2003594) 15:57:35 #topic Open Discussion 15:57:45 Does anyone have anything they would like to bring up in the next couple of minutes? 15:57:51 qq: do we have any guidelines for docs changes? 15:58:06 cdearborn: what do you mean by guidelines? 15:58:22 I think the question may next be what do you feel needs to change? 15:58:27 format, when to ``asdf`` things, etc 15:58:41 That is a really good question 15:58:58 we are at long last going to be bringing the iDRAC drivers docs up to date 15:59:10 I don't think there are a unified formatting guidelines, but there are structural guidelines 15:59:18 but for a driver, structural really doesn't matter 15:59:22 TheJulia: Another qq. Have community goals been determined for Ussuri? I wonder if projects' implementation of driver matrices for the OpenStack Marketplace is a goal. 15:59:24 Ilya Etingof proposed openstack/ironic master: Add `instance_info/kernel_append_params` to `redfish` https://review.opendev.org/687092 15:59:25 and just wondering what tech docs guidelines we should adhere to if any to ease reviews, etc 15:59:40 I've gotten good feedback on https://review.opendev.org/#/c/681066/ , if anyone else has comments I'd be happy to hear them! 15:59:41 patch 681066 - ironic-specs - Expose node owner information to oslo.policy checks - 7 patch sets 15:59:47 `constant` <-- constant such as driver name or variable kind of thing. :) 16:00:25 rpioso: I think we would want the operator feedback session first before we really set that forward path 16:00:36 tzumainn: awesome! 16:00:45 Anyway, we're at our time. Thanks for attending today's meeting! 16:00:55 #endmeeting