15:00:22 <TheJulia> #startmeeting ironic
15:00:23 <openstack> Meeting started Mon Jan  7 15:00:22 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:24 <TheJulia> o/
15:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:26 <dtantsur> o/
15:00:28 <openstack> The meeting name has been set to 'ironic'
15:00:30 <cdearborn> o/
15:00:31 <dnuka> o/
15:00:32 <etingof> o/
15:00:33 <iurygregory> o/
15:00:35 <rpittau> o/
15:00:40 <rloo> o/
15:00:44 <kaiokmo> o/
15:00:45 <kaifeng> o/
15:00:46 <tiendc> o/
15:00:47 <TheJulia> Happy new year!
15:00:53 <rpioso> o/
15:00:58 <TheJulia> Our agenda as always can be found on the wiki!
15:01:00 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:01:01 <mjturek> o/
15:01:24 <TheJulia> We have a moderately full agenda today, with several discussion topics!
15:01:35 <TheJulia> #topic Announcements / Reminder
15:02:03 <TheJulia> #info Currently polling days for a virtual mid-cycle call: https://doodle.com/poll/uqwywaxuxsiu7zde
15:02:31 <TheJulia> Please respond to that if you have not already, so we can identify days, then attempt to identify times.
15:02:52 <TheJulia> For a virtual PTG, I've also setup an etherpad for brainstorming and planning
15:02:54 <TheJulia> #link https://etherpad.openstack.org/p/ironic-stein-midcycle
15:03:21 <TheJulia> On the topics of reminders, I will be traveling next week and on a flight during the same time of the meeting.
15:03:45 <TheJulia> #info dtantsur volunteered to run the meeting next week
15:03:57 * dtantsur hasss poooowerrzzz
15:04:04 <TheJulia> Any questions? Does anyone have anything to announce or remind us of this morning?
15:04:24 * TheJulia just looks at dtantsur oddly
15:04:34 * TheJulia needs more coffee to engage the silliness feature
15:05:01 * dtantsur whistles innocently
15:05:22 <TheJulia> Heh, I guess nobody has anything to announce or remind us of this week, so we should carry on
15:05:43 <TheJulia> #topic Action Items from prior meeting
15:06:00 <TheJulia> #info One action item was outstanding, and it was to begin planning for a virtual mid-cycle.
15:06:07 <TheJulia> Moving on
15:06:10 <rajinir> o/
15:06:15 <TheJulia> #topic Review subteam status reports
15:06:24 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:06:47 <TheJulia> Starting aroudn line 224
15:06:55 <TheJulia> s/dn/nd/
15:08:02 <TheJulia> rloo: still hoping to at least put in a "you haven't upgraded the schema check" into the status check command?
15:08:25 <dtantsur> TheJulia: is HTTP boot really blocked by IPv6? I mean, cannot we do it with IPv4?
15:08:39 <rloo> TheJulia: i had forgotten I said I'd do it until I read it today, so yes, still planning, when do we want to get it done by?
15:08:49 <TheJulia> dtantsur: return format is identical, underlying dhcp code is identical, so I consider it technically blocked
15:09:06 <dtantsur> TheJulia: for user's perspective the features are so different thought
15:09:09 <dtantsur> * though
15:09:15 <TheJulia> dtantsur: yeah... :(
15:09:24 <dtantsur> so I nearly anticipate "wait, what, I only need IPv4"
15:09:36 <dtantsur> cannot we arrange it the opposite way? block IPv6 on HTTP boot?
15:10:39 <TheJulia> dtantsur: we described ourselves as v6 ready in the past and it never really worked to the spec, so I felt that was of more importance to fix sooner rather than later
15:11:02 <dtantsur> TheJulia: sure, but can we fix it soon? I got an impression that it's one big can of worms.
15:11:13 <TheJulia> I think boot from url is largely just a boot interface tbh
15:11:23 <dtantsur> or to phrase it more positively: if there is something I can review to speed it up, please point me at the patches :)
15:11:26 <TheJulia> dtantsur: yeah, it seems there is no fully native v6 job
15:12:27 * dtantsur has a feeling that the edge topic gives the UEFI boot a higher priority from operator's perspective
15:12:30 <TheJulia> dtantsur: Okay, lets discuss this further after the meeting because I think we can go ahead and do interface/user perception work, and just do any refactoring silently in the background
15:12:37 <dtantsur> ++
15:13:06 <TheJulia> I think the iso work plays into that as well
15:13:29 <TheJulia> rloo: If we can have it up for review before the end of the month, that would be awesome
15:13:43 <rloo> TheJulia: ok, will try...
15:14:11 <TheJulia> rloo: thanks
15:14:25 <TheJulia> jroll: any update on nova conductor_group awareness?
15:14:54 * etingof got a couple of patches relevant to uefi/iso...
15:14:58 <rloo> TheJulia: I think jroll is out til early Feb. (new papa)
15:15:03 <TheJulia> rloo: ahhh!
15:15:05 <mjturek> =-o
15:15:11 <TheJulia> rloo: I had no idea!
15:15:15 <dtantsur> wow
15:15:17 * TheJulia sends jroll congradulations
15:15:29 <rloo> I'll let him give you the great news :)
15:15:40 <TheJulia> etingof: can you put a list on the etherpad?
15:15:59 <TheJulia> Anyway, moving on! Only halfway down the list
15:16:32 <etingof> TheJulia, L174
15:16:34 <TheJulia> I need to follow-up on dhcp-less/l3 vmedia booting. I've not heard back from the folks at Nokia, so I'm going to send an email and try to see what is going on there.
15:17:07 <TheJulia> I believe initial deploy templates code was posted over the holidays
15:17:28 <TheJulia> Yup
15:17:29 <TheJulia> #link https://review.openstack.org/627663
15:17:30 <patchbot> patch 627663 - ironic - WIP: Deploy templates: data model, DB API & objects - 3 patch sets
15:17:30 <dtantsur> deploy templates \o/
15:18:31 <TheJulia> Graphical consoles, if anyone wants to volunteer to keep the patch rebased, what is up for review is the substrate for the feature. Next logical step I believe is actual API support update
15:19:02 <dtantsur> honestly, it seems like we should build a list of planned features that need help
15:19:08 <TheJulia> dtantsur: yeah
15:19:14 <rpittau> TheJulia, I can have a look at the patch rebase for the graphical console
15:19:21 <dtantsur> nice!
15:19:22 <TheJulia> rpittau: awesome, thanks
15:19:33 <TheJulia> #action TheJulia to make a list of things that need help
15:19:43 <rpittau> TheJulia, dtantsur, prepare for help calls :P
15:19:49 <dtantsur> absolutely
15:19:51 <iurygregory> me can help just need to see the list =)
15:20:04 <iurygregory> forgot the / -.-'
15:20:30 <dtantsur> heh
15:20:30 <TheJulia> I think the status on the etherpad is essentially up to date for everything else.
15:21:05 <TheJulia> Does anyone else have any questions, or are we good to proceed for priorities for the week?
15:22:20 <TheJulia> Okay, moving on to priorities for the week
15:22:42 <TheJulia> #topic Deciding on priorities for the coming week
15:22:49 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:22:56 <TheJulia> Starting at line 131
15:23:06 <TheJulia> Starting off, I'm going to remove the merged items.
15:26:27 <TheJulia> Does anyone have anything they would like to add to the list this week?
15:26:50 <TheJulia> dtantsur: thanks for the stable approval :)
15:26:59 <dtantsur> np :)
15:27:04 <TheJulia> It will be easy to remove from the list.. hopefully :)
15:27:18 <TheJulia> Are we missing any items from this list?
15:27:26 * etingof has a couple of sushy-tools patches....
15:27:33 <dtantsur> you okay with allocation API there?
15:27:48 <dtantsur> it's not entirely finished, but a few patches are ready (modulo CI being very unstable)
15:28:07 <TheJulia> dtantsur: I am
15:28:10 <dtantsur> cool
15:28:27 <TheJulia> etingof: Add a couple to the list please :)
15:28:33 <etingof> ack
15:29:18 <dtantsur> currently the list looks a bit larger than we can manage with who we have this week
15:29:37 <dtantsur> however, many items look easy
15:30:06 <TheJulia> yeah, some proceedural too
15:30:54 <TheJulia> I guess we're good to move on to Discussion topics?
15:31:59 <TheJulia> I guess everyone is happy, and we can proceed.
15:32:19 <TheJulia> #topic Discussion
15:32:29 <TheJulia> First topic! PTG!
15:32:58 <iurygregory> \o/
15:33:08 <dtantsur> ah, that PTG..
15:33:33 <TheJulia> Can I get a show of hands for those that believe they will be attending the PTG in Denver after the newly named Open Infrastructure conference?
15:33:35 <TheJulia> o/
15:33:48 <rpittau> o/
15:33:48 <cdearborn> o/
15:33:55 <iurygregory> i hope i will o/
15:33:58 * dtantsur waves his hand without much certainty
15:34:08 <dnuka> o/ :)
15:34:34 * iurygregory needs manager approval to go XD
15:34:39 * TheJulia awaits a \o
15:34:51 <dtantsur> iurygregory: that's the easiest part, no? </kidding>
15:34:51 <TheJulia> iurygregory: Essentially everyone does in this age.
15:34:52 <rpittau> iurygregory, me too :)
15:35:00 <rloo> hopefully ...
15:35:01 <rpioso> \o, hopefully :)
15:35:01 * kaifeng just waves his head..
15:35:10 <mjturek> hoping to! \o
15:35:18 <TheJulia> kaifeng: :(
15:35:20 <dtantsur> for us Europeans the budget is going to be through the roof :)
15:35:23 <iurygregory> no idea since all my summits ptgs was with my money or by TSP XD
15:35:41 <rpittau> let's be positive :P
15:35:50 <TheJulia> rpittau: you have the right attitude
15:35:50 <rloo> apart from travel, is this PTG going to be more $$ than past ones?
15:35:54 <iurygregory> thats why i said i hope hehe
15:36:04 <dtantsur> rloo: I suspect so. the location is downtown this time.
15:36:20 <rpittau> I believe also for travel, at least one stop from europe
15:36:23 <dtantsur> and the PTG itself is much more expensive ($400?)
15:36:24 <TheJulia> I've not checked the hotel rates, I had heard they were comperable
15:36:35 <dtantsur> $150+ last time I checked
15:36:37 <TheJulia> eek
15:36:45 <rpioso> Denver has an awesome rail public transport system.
15:36:54 <TheJulia> This is true
15:37:04 <rloo> (and who is going to be there for the 'whole' thing... that'll make it more $$ too, but less than going to two events?)
15:37:08 <TheJulia> Okay, I have a rough idea to give the foundation for planning, thanks everyone
15:37:10 <dtantsur> I mean, I'm likely to go because that's me :) but this is pending budget and renewed USA visa
15:37:30 <iurygregory> cool =D
15:37:34 <dtantsur> rloo: this is ever harder to predict (except for Julia, I guess :)
15:37:41 <TheJulia> rloo: I have to be :(
15:38:00 <TheJulia> Anyway, carrying on!
15:38:02 <rloo> lucky TheJulia!
15:38:05 <dtantsur> the joined ticket is >$1000, then hotel for what 6 nights....
15:38:12 <dtantsur> yeah, let's move on from this sad topic :)
15:38:27 <TheJulia> Dtantsur's topic was the ironic-tempest-plugin CI job
15:38:29 <TheJulia> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001346.html
15:38:44 * TheJulia hands the virtual microphone to dtantsur
15:39:01 <dtantsur> Please read that rumbling about our gate being too big :)
15:39:12 <dtantsur> tl;dr let's do some cuts to stable coverage of the tempest plugin job
15:39:32 <TheJulia> I think option 1 is the most reasonable path forward
15:39:36 <TheJulia> personally
15:40:37 <rloo> wrt option 1, is it possible (after doing 1) for someone to explicit trigger a CI job for ocata? eg, after backporting a change to ocata, want to see what happens...?
15:40:39 <dtantsur> they're not mutually exclusive thought
15:40:48 <TheJulia> Plugins are now version tagged as well, so...
15:40:49 <dtantsur> rloo: we can move it to experimental queue
15:41:28 <rloo> dtantsur: i'm good with that. guessing it won't get used or if it does it'll break but at least it'll be avail if anyone needs it
15:41:45 <dtantsur> ack
15:41:53 <dtantsur> on a related topic, our gate is barely working :(
15:42:06 <rloo> wrt 2, i'm good with that
15:42:18 <TheJulia> dtantsur: I saw the note when I sat down before the meeting :(
15:42:26 * rpittau still have nightmares cause of grenade multinode multitenant
15:42:50 <dtantsur> everyone has, rpittau, everyone here has..
15:42:53 <dtantsur> :D
15:43:09 <rloo> wrt 3. so i guess when we backport, we ought to be careful and check the non-voting jobs?
15:43:44 <TheJulia> rpittau: If so inclined, there are beverages that ease the grenade nightmares
15:43:56 <rpittau> lol
15:43:58 <rloo> not called grenade for nothing...
15:44:05 <dtantsur> rloo: there are no backports there. it's rather, when changign any of theses tests, watch out for the stable jobs
15:44:25 <TheJulia> I was just about to point that out
15:44:55 <dtantsur> the thing is, we barely ever change these tests
15:45:02 <TheJulia> I feel more complex networking lends itself to more neutron race condition failures
15:45:03 <rloo> i'm just concerned that if they are non-voting, people won't notice/look. (I probably will forget)
15:45:28 <TheJulia> And I feel like that might be okay to make non-voting in older branches as we find them no longer useful
15:45:34 <rloo> but i'm fine trying it out. we can always change it again.
15:46:25 <rloo> if i understand, this is the only patch that needs to be approved? https://review.openstack.org/#/c/627955/
15:46:26 <patchbot> patch 627955 - ironic-tempest-plugin - [gate] update the list of the voting jobs - 3 patch sets
15:46:35 <dtantsur> yeah
15:47:20 <rloo> dtantsur: so i will approve it now (or in 1 minute) unless someone disagrees.
15:47:28 <rloo> timer has been started...
15:47:31 * dtantsur counts to 60
15:48:07 <TheJulia> Heh, okay
15:48:11 <TheJulia> Are we good to proceed?
15:48:33 <rloo> ++
15:48:38 <TheJulia> #topic RFE Review
15:48:40 <TheJulia> #link https://storyboard.openstack.org/#!/story/2004592
15:49:14 <dtantsur> I've left a comment there
15:49:16 <TheJulia> rpioso asked about the patch above, which is a RFE to begin the process of migrating the idrac hw type over to redfish based interfaces
15:49:54 <rpioso> dtansur: Thank you :) DracPower interacts with DracManagement in a "unique" way to set the boot device. To configure DracManagement with RedfishPower on a node, that would have to be accommodated. The RFE briefly mentions it in the "Adapt DracRedfishPower to Work with Drac[WSMan]Management" subsection.
15:50:02 <rpioso> The code's at https://github.com/openstack/ironic/blob/c10ee94b92174ce78073afc2eacb300fa649736f/ironic/drivers/modules/drac/power.py#L75-L76.
15:50:03 * dtantsur makes sad panda face at "iDrac does not support standard BIOS"
15:50:23 <dtantsur> rpioso: can we rather fix the "uniqueness"?
15:50:25 * rpioso awkwardly giggles
15:50:55 <TheJulia> I concur with your comment, I'm good with the overall theme, I think those sorts of details are kind of the outstanding questions in my mind
15:50:57 <rpioso> dtantsur: No, not as far as I'm aware.
15:51:06 <dtantsur> or rather: why cannot this line be $ task.driver.management.set_boot_device?
15:51:28 <rpioso> It revolves around the need to create an iDRAC configuration job targeted at the BIOS subsystem to configure the boot device.
15:51:38 <rloo> i haven't read through the spec, but am trying to remember what we decided/if anything, wrt redfish and support for non-generic (or whatever it is called) redfish support. eg vendor-specific redfish stuff.
15:52:03 <etingof> OEM, perhaps
15:52:16 <TheJulia> rloo: Basically what has been proposed, vendor superset interfaces on top of the redfish interfaces or OEM extensions as necessary to conform to using the redfish rest api interface
15:52:25 <dtantsur> rloo: well, I personally decided that life is pain and everything is vendor-specific anyway
15:52:29 <rpioso> dtantsur: driver.management.set_boot_device simply caches the desired setting on the node object. It's applied during the next power event.
15:52:52 <rloo> if life is vendor-specific anyway, then let's approve whatever APIs the vendors want!
15:52:53 <TheJulia> dtantsur: I feel like watching "The Princess Bride" is now on the agenda
15:52:54 <rloo> j/k
15:53:18 <dtantsur> heh
15:53:29 <dtantsur> rpioso: I guess I'm fine with the proposal if this explanation is added to it
15:53:36 <rpioso> I could use assistance with deprecation of default interfaces and removing support for interfaces.
15:53:49 <rpioso> Is that a thing?
15:53:51 <TheJulia> rpioso: so tl;dr, the redfish actions and support still has the same basic mechanical setting constraints?
15:54:12 <TheJulia> rpioso: Is what a thing?
15:54:13 <dtantsur> rpioso: re deprecation: we did it for iRMC once. It involved a release note and warnings.
15:54:26 <rpioso> TheJulia: That does not compute to my Monday, under caffeinated mind.
15:54:34 <dtantsur> if you deprecate the default interface, two cycles are preferred to one
15:54:42 <rpioso> TheJulia: Deprecation
15:55:06 <TheJulia> rpioso: oh... I guess irccloud displayed messages out of order or something
15:55:20 <rpioso> dtantsur: Thanks for the iRMC pointer. What about migration?
15:55:42 <dtantsur> rpioso: we haven't done any. but you can consider creating an online data migration, similar to one I did for the driver composition.
15:55:42 * rpioso takes a note to add the detail dtantsur requested.
15:56:01 <rpioso> dtantsur: Is it required or extra credit?
15:56:13 <dtantsur> rpioso: extra credit from my point of view
15:56:34 <TheJulia> rpioso: It would be a good idea™
15:56:38 * rloo wonders why there isn't an actual spec PR for this. Seems like there are quite a few details involved here.
15:57:25 <TheJulia> rloo: its all vendor interface stuff in the grand scheme of the universe
15:57:25 <rpioso> rloo: Perhaps I over achieved in the story ;0
15:57:40 <etingof> pardon my ignorance, but it is not possible to express idrac power/boot/etc operations within the standard redfish schema/actions, right?
15:57:49 <etingof> I mean on the BMC side
15:58:02 <rloo> it just makes it harder to connect the/any comments with the description. and in my mind -- i'm wondering if all the various sections of a spec are covered.
15:58:10 <dtantsur> etingof: well, it is possible from the protocol perspective. but the boot device operation can be done once per reboot.
15:58:21 <rloo> adding new api is one thing, renaming etc is another.
15:58:27 <dtantsur> which reminds us that it's not enough to agree on the common transport protocol, semantics also matter
15:58:42 <dtantsur> and semantics is something redfish completely drops on the floor.
15:58:45 <dtantsur> am I whining again?
15:58:47 <rpioso> etingof: Yes, the iDRAC supports Redfish power and boot.
15:58:48 <TheJulia> rloo: I completely agree
15:58:49 * dtantsur opens whiskey
15:59:06 <TheJulia> heh
15:59:15 <TheJulia> We have one minute left
15:59:17 <rloo> i'm not insisting on a spec PR here since the description is very detailed. just commenting about how I feel :)
15:59:52 <NobodyCam> Good Morning Ironic'erd
15:59:54 * rpioso notes to add detail about deprecation
15:59:57 <NobodyCam> ieek
16:00:04 <NobodyCam> Good Morning Ironic'ers
16:00:07 <rpittau> hi NobodyCam , nice timing :P
16:00:09 <TheJulia> rloo: Ack, I was feeling the same way early on when it was all defined in the first posted version in storyboard
16:00:23 <TheJulia> Anyway! sounds like we're done with the rfe
16:00:28 <rpioso> Is it acceptable to the cores?
16:00:31 <rloo> i wonder if we even want to rename the existing idrac interface classes. that's internal. what matters is the 'idrac' names that users see.
16:00:50 <NobodyCam> Good morning rpittau, rloo, TheJulia, and dtantsur
16:00:58 <dtantsur> morning NobodyCam
16:01:01 <rpioso> rloo: The idrac names are being deprecated.
16:01:13 <rloo> oh, meeting is over?
16:01:18 <dnuka> morning NobodyCam
16:01:24 <rpioso> And replaced with idrac-wsman and idrac-redfish.
16:01:28 <TheJulia> rloo: just about :)
16:02:16 <TheJulia> Thanks everyone! We can have open discussion time after I end the meeting
16:02:20 <TheJulia> #endmeeting