15:00:27 <TheJulia> #startmeeting ironic
15:00:28 <TheJulia> o/
15:00:28 <openstack> Meeting started Mon Jan 20 15:00:27 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:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:31 <openstack> The meeting name has been set to 'ironic'
15:00:34 <iurygregory> o/
15:00:35 <rpittau> o/
15:00:37 <rpioso> o/
15:00:38 <etingof> o/
15:00:39 <rloo> o/
15:00:39 <TheJulia> Good Morning Ironic!
15:00:41 <kaifeng_> o/
15:00:59 <arne_wiebalck> o/
15:01:24 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:37 <TheJulia> Our agenda for the meeting looks fairly normal, so I guess we'll get started!
15:01:46 <TheJulia> #topic Announcements/Reminders
15:02:12 <stendulker> o/
15:02:21 <dtantsur> o/
15:02:24 <cdearborn> o/
15:02:32 <openstackgerrit> Dmitry Tantsur proposed openstack/ironic master: Fix incorrect ibmc_address parsing on Python 3.8  https://review.opendev.org/703411
15:02:57 <TheJulia> For context, we're a few weeks away from the Ussuri-2 milestone.
15:03:29 <TheJulia> We're planning a midcycle at CERN in about a month as well.
15:03:31 <TheJulia> #link https://etherpad.openstack.org/p/ironic-ussuri-midcycle
15:04:05 <arne_wiebalck> Please register if you plan to attend in person.
15:04:14 <TheJulia> Some topics that would be good to discuss have already been added.
15:04:20 <arne_wiebalck> Most have already I think.
15:04:24 <TheJulia> ++
15:04:38 * TheJulia loves the sushy topic being added
15:04:51 <TheJulia> Anyway, does anyone else have anything to announce?
15:04:52 <arne_wiebalck> I would not send anything on the ML for the mid cycle meetup.
15:05:26 <TheJulia> Oh, I'm taking PTO tomorrow for personal reasons. If you guys really need me, just let me know.
15:06:05 <TheJulia> Well, if there is nothing else we can move on.
15:06:57 <TheJulia> It appears that there were no action items last week.
15:07:01 <TheJulia> So we can skip that
15:07:22 <TheJulia> #topic Review subteam status reports
15:07:35 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:08:41 <TheJulia> Line 262
15:09:08 <openstackgerrit> Dmitry Tantsur proposed openstack/ironic-python-agent-builder master: Fix and return the CentOS 7 job  https://review.opendev.org/703371
15:09:09 <TheJulia> On scale/performance, who put that they were going to do scale testing in Feburary ?
15:10:56 <arne_wiebalck> I did.
15:10:58 <dtantsur> the color looks like arne_wiebalck
15:11:00 <dtantsur> right :)
15:11:03 <TheJulia> thanks!
15:11:17 <arne_wiebalck> it's just to say it is on our list for hte coming weeks
15:11:34 <TheJulia> Looks like the L3 spec could use some reviews
15:11:42 <TheJulia> arne_wiebalck: Excellent!
15:12:39 <yolanda> hi dtantsur , seems that the problem is that i had redfish-virtualmedia as default_boot_interface. If i move to ipxe as default, i can deploy
15:12:43 * dtantsur needs to get back to the L3 spec
15:12:46 <TheJulia> Is uefi support for software raid still a desired thing?
15:12:54 <arne_wiebalck> yes
15:13:01 <TheJulia> arne_wiebalck: using xXraphXx's patches?
15:13:07 <arne_wiebalck> yes
15:13:13 <TheJulia> k
15:13:19 <arne_wiebalck> I just didn't have time yet
15:13:30 <dtantsur> yolanda: generally, I recommend people NOT to use default_**_interface for vendor stuff specifically for this reasons: there's no sane default for other hardware types
15:13:42 <TheJulia> okay, I noticed, at least the ironic side was showing lots of failures, but it looks like it got uploaded when CI was not in great shape.
15:14:30 <dtantsur> completely unrelated, but we missed an announcement that hit my mailbox 5 days ago: The next Project Teams Gathering (PTG) [1] will be in Vancouver, BC from June 8-11.
15:15:11 <TheJulia> Bifrost dropping py2 and moving to py3 is moving forward. I actually had the agent start on my test VM and everything \o/
15:15:41 <TheJulia> dtantsur: Thanks for pointing that out and reminding me. Somehow that feels a little worrisome to me as there is yet another format change.
15:15:53 <TheJulia> But I've not raised that yet because life
15:16:37 <yolanda> dtantsur, ack. In that case the specific boot interface always need to be setup at node level, right?
15:16:46 <dtantsur> yolanda: correct
15:16:51 <TheJulia> is the zuulv3 migration basically done?
15:16:59 <TheJulia> iurygregory: I think you were working on that?
15:17:03 <dtantsur> grenade?
15:17:15 <TheJulia> well, until it is re-written, we can't do anything I don't think
15:17:20 <iurygregory> TheJulia, it's wip
15:17:25 <TheJulia> k
15:17:39 <iurygregory> tosky is working on the job for grenade I'm doing tests already
15:17:44 <TheJulia> iurygregory: could you add some more detail to the etherpad?
15:17:49 <TheJulia> ahh, maybe just a date then
15:17:55 <iurygregory> doing now =)
15:18:00 <TheJulia> thanks!
15:18:22 <TheJulia> Has anyone discussed the state callback work with nova recently?
15:19:10 <arne_wiebalck> not me
15:19:53 <TheJulia> Well the statuses look good to me
15:21:38 <openstackgerrit> Tzu-Mainn Chen proposed openstack/python-ironicclient master: Add allocation owner  https://review.opendev.org/702728
15:22:01 <TheJulia> Everyone ready to move on to priorities for the coming week?
15:22:31 <iurygregory> ++
15:22:33 <dtantsur> ++
15:22:53 <rpittau> let's
15:23:34 <TheJulia> #topic Deciding on priorities for the coming week
15:23:45 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:24:06 <TheJulia> Starting at line 166
15:24:52 <dtantsur> I've added the ironicclient part of the ownership work
15:25:02 <TheJulia> I think the list looks fairly good, a number of bifrost patches landed last week, thanks for the reviews everyone
15:25:08 <TheJulia> It is super close \o/
15:25:42 <rpittau> TheJulia: this might also help https://review.opendev.org/703343
15:25:42 <patchbot> patch 703343 - bifrost - Define venv package for debian based distro - 1 patch set
15:25:53 <dtantsur> speaking of bifrost, I could use reviews of https://review.opendev.org/#/c/703069/ and its backports
15:25:53 <patchbot> patch 703069 - bifrost - Use upper-constraints for ironicclient, sushy and DIB - 5 patch sets
15:26:19 <TheJulia> rpittau: If that does what I suspect, that might also save me a patch today :)
15:26:30 <rpittau> hope so :)
15:27:48 <TheJulia> dtantsur: Added to the list for bifrost, hopefully we get the CI semi-working for at least bionic before we merge that patch though
15:28:10 <TheJulia> Does anyone have anything else to add?
15:28:25 <dtantsur> TheJulia: just note that stable bifrost is broken without it
15:28:41 <TheJulia> dtantsur: yay!
15:28:43 <TheJulia> good point
15:29:00 <dtantsur> and then stein exhibits some weird behavior WITH this patch. sooooo....
15:29:09 <TheJulia> ugh
15:29:09 <TheJulia> yay
15:29:31 <TheJulia> Speaking of stein, has anyone looked at the stein sushy-tempest-ironic-partition-redfish-src job? https://review.opendev.org/#/c/701814/
15:29:31 <patchbot> patch 701814 - sushy (stable/stein) - SSC.disks_sizes_bytes handle CapacityBytes is None - 1 patch set
15:29:37 <rpioso> Not sure if this is on topic, but what's the state of the sushy gate?
15:29:39 <TheJulia> It seems there is unhappiness
15:29:57 <rpioso> TheJulia: jinx
15:30:17 <TheJulia> Master branch seems to be good, I rebased one of bdodd_'s patches late last week
15:30:20 <rpioso> TheJulia: That's what prompted my question.
15:30:41 <TheJulia> Likely someone just needs to look
15:30:52 <TheJulia> Anyway, everyone good with the list of priorites and moving on?
15:30:55 <TheJulia> priorities
15:31:03 <dtantsur> etingof: another case of the same sushy sadness? https://storyboard.openstack.org/#!/story/2006641
15:31:21 <dtantsur> fixing this ^^^ should become a priority IMO
15:31:40 <rpioso> TheJulia: There's another cherry pick of that change to stable/train. It failed to be verified by the same tests.
15:31:44 <TheJulia> Ithought that was already fixed...
15:32:07 <dtantsur> https://review.opendev.org/670720 is a part of it
15:32:08 <patchbot> patch 670720 - sushy - Handle incomplete messages in MessageRegistry - 1 patch set
15:32:11 <TheJulia> but I saw another report of registry. Maybe we tweeked the registry code in review too much to tolerate the reality of BMCs?
15:32:14 <dtantsur> but here's probably more
15:32:22 <etingof> oh, sushy
15:32:49 <TheJulia> stendulker: Any reason for the WF-1 on the aformentioned patch?
15:33:13 <TheJulia> I'm wondering if ops feedback is from last week from johnthetubaguy?
15:33:16 <TheJulia> mgoddard: ^?
15:34:05 <stendulker> TheJulia: It is not required. I had to check with f/w team and got it confirmed that its a firmware bug.
15:34:09 <etingof> diverting sushy from official schema can be complicated...
15:34:12 <stendulker> TheJulia: I will abandon it.
15:34:28 <TheJulia> stendulker: but it seems we're running into missing registry items with other vendors :\
15:34:43 <stendulker> oh :(
15:35:11 <stendulker> Shall we take this fix?
15:35:25 <dtantsur> even with a firmware bug.. we cannot (unfortunately!) expect everyone to always chase the latest firmware..
15:35:59 <stendulker> dtantsur: I was testing pre-release bits of firmware...
15:35:59 <TheJulia> I think we should move forward on handling if it is not present... because I think missing registry entries is a thing in two other vendors as well, so I think it just makes sense
15:36:18 <yolanda> i was hitting this missingregistry errors, using latest firmware on my boxes last week
15:36:19 <dtantsur> stendulker: yolanda hit it on something production, I think
15:36:26 <stendulker> Will remove workflow-1
15:36:31 <TheJulia> stendulker: thanks
15:37:05 <TheJulia> Added to the sushy list
15:37:12 <TheJulia> Moving on!
15:37:14 <stendulker> TheJulia: np
15:37:27 <TheJulia> #topic Baremetal SIG
15:38:01 <TheJulia> #info If you have submitted case studies to the foundation, please feel free to add the contents to the whitepaper document.
15:38:35 <TheJulia> #link https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsfGooA/edit
15:39:04 <TheJulia> arne_wiebalck: Hopefully I'll be able to supply one for Red Hat... soon. :)
15:39:17 <arne_wiebalck> nice! thanks
15:39:47 <TheJulia> I guess we're good to move to Open Discussion if there is nothing else?
15:41:08 * TheJulia hears crickets
15:41:09 <TheJulia> #topic Open Discussion
15:41:55 <kaifeng_> i have filed a small rfe for discussion: https://storyboard.openstack.org/#!/story/2007099
15:42:31 <TheJulia> That seems reasonable
15:42:44 <TheJulia> I guess the code could also check if the port is already in-use...
15:43:10 <kaifeng_> if the story provides enough information, i guess we can skip the spec?
15:43:32 <TheJulia> It seems really small and like it shouldn't need a spec at all
15:43:42 <TheJulia> more like a logical improvement to me
15:43:57 <kaifeng_> yes, we will save the allocated port as a driver internal info
15:45:05 <dtantsur> "support an auto value for the ipmi_terminal_port" maybe just no value at all?
15:45:25 <TheJulia> dtantsur: I like that idea a lot
15:45:25 <dtantsur> otherwise looks very reasonable to me
15:45:34 <TheJulia> that makes the feature way more usable
15:45:49 <kaifeng_> it means ipmi_terminal_port can be a string 'auto'
15:46:33 <kaifeng_> when user update the node with "auto" value, conductor will allocate a port from the configured range.
15:46:56 <TheJulia> could it be better to deprecate ipmi_terminal_port?
15:47:54 <dtantsur> or at least make it an optional advanced-only setting?
15:48:55 <TheJulia> Yeah... this feels like a detail that can be sorted in code review, to be honest
15:49:18 <TheJulia> just thinking from a usability standpoint... allocating as needed from a range is a way better way to handle these sorts of things
15:49:32 <kaifeng_> well, i haven't thought about deprecation of ipmi_terminal_port, but it's possible
15:51:19 <kaifeng_> the main advantage of this is to avoid manual management of the console port, so we can avoid port conflicts and better takeover
15:52:11 <kaifeng_> when it's done, i think we can start removing the ipmi_terminal_port
15:52:19 <TheJulia> I concur, I suspect the logic path is always going to need to check if a port is in use and possibly change ports up. The nova client code should be reading the field out of ironic when the port needs to be accessed
15:52:55 <dtantsur> I'm mostly suggesting that we don't need the 'auto' value because a missing value will serve the same role
15:54:16 <rloo> ++ with dtantsur.
15:54:28 <kaifeng_> yeah, that's a nice suggestion.
15:54:29 <TheJulia> Makes sense
15:54:45 <rloo> (and will make it easier to deprecate/remove ipmi_terminal_port)
15:55:02 <TheJulia> ++
15:55:14 <TheJulia> Anyway, seems like we're done today...
15:55:15 <rloo> i have been wondering about stashing things in driver_internal_info and whether we're stashing too many things there, but that might be another discussion
15:55:33 <kaifeng_> i will update the story accordingly :)
15:56:10 <TheJulia> rloo: I feel like that topic needs an example since it is driver state filed that a user can't edit.
15:56:18 * rloo thinks we need to provide API for user to know which port is being used for console
15:56:39 <TheJulia> rloo: we expose it as part of the console field data
15:56:51 <rloo> oh,in that case, it is fine.
15:56:59 <kaifeng_> rloo: we provide console link if enabled
15:57:02 <TheJulia> okay
15:57:07 <TheJulia> Well, thanks everyone!
15:58:18 <TheJulia> Have a wonderful week!
15:58:31 <rpittau> thanks! you too!
15:58:35 <TheJulia> #endmeeting