15:00:22 #startmeeting ironic 15:00:23 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 o/ 15:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:26 o/ 15:00:28 The meeting name has been set to 'ironic' 15:00:30 o/ 15:00:31 o/ 15:00:32 o/ 15:00:33 o/ 15:00:35 o/ 15:00:40 o/ 15:00:44 o/ 15:00:45 o/ 15:00:46 o/ 15:00:47 Happy new year! 15:00:53 o/ 15:00:58 Our agenda as always can be found on the wiki! 15:01:00 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:01:01 o/ 15:01:24 We have a moderately full agenda today, with several discussion topics! 15:01:35 #topic Announcements / Reminder 15:02:03 #info Currently polling days for a virtual mid-cycle call: https://doodle.com/poll/uqwywaxuxsiu7zde 15:02:31 Please respond to that if you have not already, so we can identify days, then attempt to identify times. 15:02:52 For a virtual PTG, I've also setup an etherpad for brainstorming and planning 15:02:54 #link https://etherpad.openstack.org/p/ironic-stein-midcycle 15:03:21 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 #info dtantsur volunteered to run the meeting next week 15:03:57 * dtantsur hasss poooowerrzzz 15:04:04 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 Heh, I guess nobody has anything to announce or remind us of this week, so we should carry on 15:05:43 #topic Action Items from prior meeting 15:06:00 #info One action item was outstanding, and it was to begin planning for a virtual mid-cycle. 15:06:07 Moving on 15:06:10 o/ 15:06:15 #topic Review subteam status reports 15:06:24 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:06:47 Starting aroudn line 224 15:06:55 s/dn/nd/ 15:08:02 rloo: still hoping to at least put in a "you haven't upgraded the schema check" into the status check command? 15:08:25 TheJulia: is HTTP boot really blocked by IPv6? I mean, cannot we do it with IPv4? 15:08:39 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 dtantsur: return format is identical, underlying dhcp code is identical, so I consider it technically blocked 15:09:06 TheJulia: for user's perspective the features are so different thought 15:09:09 * though 15:09:15 dtantsur: yeah... :( 15:09:24 so I nearly anticipate "wait, what, I only need IPv4" 15:09:36 cannot we arrange it the opposite way? block IPv6 on HTTP boot? 15:10:39 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 TheJulia: sure, but can we fix it soon? I got an impression that it's one big can of worms. 15:11:13 I think boot from url is largely just a boot interface tbh 15:11:23 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 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 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 ++ 15:13:06 I think the iso work plays into that as well 15:13:29 rloo: If we can have it up for review before the end of the month, that would be awesome 15:13:43 TheJulia: ok, will try... 15:14:11 rloo: thanks 15:14:25 jroll: any update on nova conductor_group awareness? 15:14:54 * etingof got a couple of patches relevant to uefi/iso... 15:14:58 TheJulia: I think jroll is out til early Feb. (new papa) 15:15:03 rloo: ahhh! 15:15:05 =-o 15:15:11 rloo: I had no idea! 15:15:15 wow 15:15:17 * TheJulia sends jroll congradulations 15:15:29 I'll let him give you the great news :) 15:15:40 etingof: can you put a list on the etherpad? 15:15:59 Anyway, moving on! Only halfway down the list 15:16:32 TheJulia, L174 15:16:34 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 I believe initial deploy templates code was posted over the holidays 15:17:28 Yup 15:17:29 #link https://review.openstack.org/627663 15:17:30 patch 627663 - ironic - WIP: Deploy templates: data model, DB API & objects - 3 patch sets 15:17:30 deploy templates \o/ 15:18:31 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 honestly, it seems like we should build a list of planned features that need help 15:19:08 dtantsur: yeah 15:19:14 TheJulia, I can have a look at the patch rebase for the graphical console 15:19:21 nice! 15:19:22 rpittau: awesome, thanks 15:19:33 #action TheJulia to make a list of things that need help 15:19:43 TheJulia, dtantsur, prepare for help calls :P 15:19:49 absolutely 15:19:51 me can help just need to see the list =) 15:20:04 forgot the / -.-' 15:20:30 heh 15:20:30 I think the status on the etherpad is essentially up to date for everything else. 15:21:05 Does anyone else have any questions, or are we good to proceed for priorities for the week? 15:22:20 Okay, moving on to priorities for the week 15:22:42 #topic Deciding on priorities for the coming week 15:22:49 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:22:56 Starting at line 131 15:23:06 Starting off, I'm going to remove the merged items. 15:26:27 Does anyone have anything they would like to add to the list this week? 15:26:50 dtantsur: thanks for the stable approval :) 15:26:59 np :) 15:27:04 It will be easy to remove from the list.. hopefully :) 15:27:18 Are we missing any items from this list? 15:27:26 * etingof has a couple of sushy-tools patches.... 15:27:33 you okay with allocation API there? 15:27:48 it's not entirely finished, but a few patches are ready (modulo CI being very unstable) 15:28:07 dtantsur: I am 15:28:10 cool 15:28:27 etingof: Add a couple to the list please :) 15:28:33 ack 15:29:18 currently the list looks a bit larger than we can manage with who we have this week 15:29:37 however, many items look easy 15:30:06 yeah, some proceedural too 15:30:54 I guess we're good to move on to Discussion topics? 15:31:59 I guess everyone is happy, and we can proceed. 15:32:19 #topic Discussion 15:32:29 First topic! PTG! 15:32:58 \o/ 15:33:08 ah, that PTG.. 15:33:33 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 o/ 15:33:48 o/ 15:33:48 o/ 15:33:55 i hope i will o/ 15:33:58 * dtantsur waves his hand without much certainty 15:34:08 o/ :) 15:34:34 * iurygregory needs manager approval to go XD 15:34:39 * TheJulia awaits a \o 15:34:51 iurygregory: that's the easiest part, no? 15:34:51 iurygregory: Essentially everyone does in this age. 15:34:52 iurygregory, me too :) 15:35:00 hopefully ... 15:35:01 \o, hopefully :) 15:35:01 * kaifeng just waves his head.. 15:35:10 hoping to! \o 15:35:18 kaifeng: :( 15:35:20 for us Europeans the budget is going to be through the roof :) 15:35:23 no idea since all my summits ptgs was with my money or by TSP XD 15:35:41 let's be positive :P 15:35:50 rpittau: you have the right attitude 15:35:50 apart from travel, is this PTG going to be more $$ than past ones? 15:35:54 thats why i said i hope hehe 15:36:04 rloo: I suspect so. the location is downtown this time. 15:36:20 I believe also for travel, at least one stop from europe 15:36:23 and the PTG itself is much more expensive ($400?) 15:36:24 I've not checked the hotel rates, I had heard they were comperable 15:36:35 $150+ last time I checked 15:36:37 eek 15:36:45 Denver has an awesome rail public transport system. 15:36:54 This is true 15:37:04 (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 Okay, I have a rough idea to give the foundation for planning, thanks everyone 15:37:10 I mean, I'm likely to go because that's me :) but this is pending budget and renewed USA visa 15:37:30 cool =D 15:37:34 rloo: this is ever harder to predict (except for Julia, I guess :) 15:37:41 rloo: I have to be :( 15:38:00 Anyway, carrying on! 15:38:02 lucky TheJulia! 15:38:05 the joined ticket is >$1000, then hotel for what 6 nights.... 15:38:12 yeah, let's move on from this sad topic :) 15:38:27 Dtantsur's topic was the ironic-tempest-plugin CI job 15:38:29 #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 Please read that rumbling about our gate being too big :) 15:39:12 tl;dr let's do some cuts to stable coverage of the tempest plugin job 15:39:32 I think option 1 is the most reasonable path forward 15:39:36 personally 15:40:37 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 they're not mutually exclusive thought 15:40:48 Plugins are now version tagged as well, so... 15:40:49 rloo: we can move it to experimental queue 15:41:28 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 ack 15:41:53 on a related topic, our gate is barely working :( 15:42:06 wrt 2, i'm good with that 15:42:18 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 everyone has, rpittau, everyone here has.. 15:42:53 :D 15:43:09 wrt 3. so i guess when we backport, we ought to be careful and check the non-voting jobs? 15:43:44 rpittau: If so inclined, there are beverages that ease the grenade nightmares 15:43:56 lol 15:43:58 not called grenade for nothing... 15:44:05 rloo: there are no backports there. it's rather, when changign any of theses tests, watch out for the stable jobs 15:44:25 I was just about to point that out 15:44:55 the thing is, we barely ever change these tests 15:45:02 I feel more complex networking lends itself to more neutron race condition failures 15:45:03 i'm just concerned that if they are non-voting, people won't notice/look. (I probably will forget) 15:45:28 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 but i'm fine trying it out. we can always change it again. 15:46:25 if i understand, this is the only patch that needs to be approved? https://review.openstack.org/#/c/627955/ 15:46:26 patch 627955 - ironic-tempest-plugin - [gate] update the list of the voting jobs - 3 patch sets 15:46:35 yeah 15:47:20 dtantsur: so i will approve it now (or in 1 minute) unless someone disagrees. 15:47:28 timer has been started... 15:47:31 * dtantsur counts to 60 15:48:07 Heh, okay 15:48:11 Are we good to proceed? 15:48:33 ++ 15:48:38 #topic RFE Review 15:48:40 #link https://storyboard.openstack.org/#!/story/2004592 15:49:14 I've left a comment there 15:49:16 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 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 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 rpioso: can we rather fix the "uniqueness"? 15:50:25 * rpioso awkwardly giggles 15:50:55 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 dtantsur: No, not as far as I'm aware. 15:51:06 or rather: why cannot this line be $ task.driver.management.set_boot_device? 15:51:28 It revolves around the need to create an iDRAC configuration job targeted at the BIOS subsystem to configure the boot device. 15:51:38 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 OEM, perhaps 15:52:16 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 rloo: well, I personally decided that life is pain and everything is vendor-specific anyway 15:52:29 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 if life is vendor-specific anyway, then let's approve whatever APIs the vendors want! 15:52:53 dtantsur: I feel like watching "The Princess Bride" is now on the agenda 15:52:54 j/k 15:53:18 heh 15:53:29 rpioso: I guess I'm fine with the proposal if this explanation is added to it 15:53:36 I could use assistance with deprecation of default interfaces and removing support for interfaces. 15:53:49 Is that a thing? 15:53:51 rpioso: so tl;dr, the redfish actions and support still has the same basic mechanical setting constraints? 15:54:12 rpioso: Is what a thing? 15:54:13 rpioso: re deprecation: we did it for iRMC once. It involved a release note and warnings. 15:54:26 TheJulia: That does not compute to my Monday, under caffeinated mind. 15:54:34 if you deprecate the default interface, two cycles are preferred to one 15:54:42 TheJulia: Deprecation 15:55:06 rpioso: oh... I guess irccloud displayed messages out of order or something 15:55:20 dtantsur: Thanks for the iRMC pointer. What about migration? 15:55:42 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 dtantsur: Is it required or extra credit? 15:56:13 rpioso: extra credit from my point of view 15:56:34 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 rloo: its all vendor interface stuff in the grand scheme of the universe 15:57:25 rloo: Perhaps I over achieved in the story ;0 15:57:40 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 I mean on the BMC side 15:58:02 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 etingof: well, it is possible from the protocol perspective. but the boot device operation can be done once per reboot. 15:58:21 adding new api is one thing, renaming etc is another. 15:58:27 which reminds us that it's not enough to agree on the common transport protocol, semantics also matter 15:58:42 and semantics is something redfish completely drops on the floor. 15:58:45 am I whining again? 15:58:47 etingof: Yes, the iDRAC supports Redfish power and boot. 15:58:48 rloo: I completely agree 15:58:49 * dtantsur opens whiskey 15:59:06 heh 15:59:15 We have one minute left 15:59:17 i'm not insisting on a spec PR here since the description is very detailed. just commenting about how I feel :) 15:59:52 Good Morning Ironic'erd 15:59:54 * rpioso notes to add detail about deprecation 15:59:57 ieek 16:00:04 Good Morning Ironic'ers 16:00:07 hi NobodyCam , nice timing :P 16:00:09 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 Anyway! sounds like we're done with the rfe 16:00:28 Is it acceptable to the cores? 16:00:31 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 Good morning rpittau, rloo, TheJulia, and dtantsur 16:00:58 morning NobodyCam 16:01:01 rloo: The idrac names are being deprecated. 16:01:13 oh, meeting is over? 16:01:18 morning NobodyCam 16:01:24 And replaced with idrac-wsman and idrac-redfish. 16:01:28 rloo: just about :) 16:02:16 Thanks everyone! We can have open discussion time after I end the meeting 16:02:20 #endmeeting