15:00:11 #startmeeting ironic 15:00:12 Meeting started Mon Apr 15 15:00:11 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:13 o/ 15:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:14 o/ 15:00:16 The meeting name has been set to 'ironic' 15:00:18 ohai 15:00:18 o/ 15:00:22 o/ 15:00:24 Good morning everyone! 15:00:26 o/ 15:00:29 o/ 15:00:29 o/ 15:00:43 o/ 15:00:46 o/ 15:00:48 o/ 15:00:50 Our agenda for this week can be found on the wiki. 15:00:52 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:00:55 TheJulia: good morning! 15:01:13 #topic Announcements / Reminders 15:01:15 o/ 15:01:41 \o 15:02:20 #info A tentative PTG schedule has been proposed for ironic. Please let TheJulia know if there are any questions, concerns, or items that need to be added/changed. 15:02:22 #link https://etherpad.openstack.org/p/DEN-train-ironic-ptg 15:02:46 #info The Denver PTG ironic team evening gathering doodle has been posted. 15:02:52 #link https://doodle.com/poll/e6q5e6pm72wbiwtz 15:03:53 #info Git repositories will be migrating to OpenDev on Friday of this week week. tl;dr gerrit will be down. 15:04:00 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html 15:04:21 and finally from the list for this week! 15:04:39 Kaifeng Wang proposed openstack/ironic-inspector master: Support reapply with supplied introspection data https://review.openstack.org/639039 15:04:44 #info Python 3.5 "support" is going to be dropped from the master branches. 15:04:50 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005097.html 15:04:57 and Stein was released ;) 15:05:09 #info And Stein was released. Great job everyone! 15:05:26 Does anyone have anything they would like to announce or remind us of this week? 15:07:19 I guess not! 15:07:23 Proceeding onward! 15:07:27 ++ 15:07:38 #topic Reviewing action items from previous meeting 15:07:55 #link http://eavesdrop.openstack.org/meetings/ironic/2019/ironic.2019-04-08-15.00.html 15:08:11 We had three action items. All of them mine \o/ 15:08:36 I followed up with neutron folk regarding smartnics. They anticipate early in the cycle for merging their side of the code. 15:09:08 I added the fast-track tempest test scenario to the proposed list for review. 15:09:13 And I created the doodle. 15:09:16 So that was it! 15:09:19 Onward! 15:09:45 thank you TheJulia. * 3 :) 15:09:55 #topic Review subteam status reports 15:10:07 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:10:26 Starting around line 268 15:11:19 mgoddard: Regarding https://review.openstack.org/#/c/641731/ 15:11:20 patch 641731 - ironic - WIP: Add iDRAC RAID deploy steps - 5 patch sets 15:11:34 TheJulia: I should take that out :) 15:11:42 WIP? 15:12:05 It's still WIP, I would still like feedback, but it hasn't moved along 15:12:18 Should we add it to the list to review? 15:12:58 I think the WIP scares people off, but sure 15:13:07 It definitely does 15:13:25 realistically I won't have time to update until after the summit, I'm on vacation for a week from tomorrow 15:13:44 ack 15:13:50 mgoddard: I will try to find some time to review today 15:13:52 if there are minor things would you like people to revise it? 15:14:10 thanks cdearborn that would be great 15:15:27 locking would <3 reviews, just saying. I'll gladly write an etcd driver if we land the framework 15:16:30 Looks like we might want to go back to considering graphical console. Looks like they have been working on updating the patches. 15:16:35 would be possible to add to review https://review.openstack.org/#/c/647774/ https://review.openstack.org/#/c/651466/ ? both have +2 Both are cherry-pick to stable/stein (Zuulv3+Python3 jobs) 15:16:35 patch 647774 - python-ironicclient (stable/stein) - Move to zuulv3 - 2 patch sets 15:16:37 patch 651466 - python-ironicclient (stable/stein) - Run jobs under python2 and python3 - 1 patch set 15:17:11 Anyway, that is the only questions I have from the list. Is everyone else good to proceed? 15:17:21 iurygregory: I'll add them to the list 15:17:30 TheJulia, ty =) 15:18:23 ++ proceed 15:18:35 #topic Deciding on priorities for the coming week 15:18:43 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:18:55 starting around line 125 15:18:59 * TheJulia removes merged things 15:19:58 So I've got a long list of patches, about half of them are stable reviews 15:20:11 Starting at 185. 15:20:33 I think they are all worthy to add and we should be able to nuke the stable patches from the list quickly 15:21:54 * TheJulia makes more coffee for everyone 15:22:11 ++ 15:22:55 * TheJulia adds 15:23:54 the exception refactoring is kind of tricky to test in CI because of the cross-project reference and I think it breaks grenade anyway if not backported ? 15:24:06 looks about right, although probably too much for a week 15:24:27 rpittau: grenade update all packages, so it will pull the newer ironic-lib 15:24:32 * updates 15:25:15 Yeah, a lot of sushy patches for good things like sensor data eventually :) 15:25:49 are we standardising this sensor data? 15:25:58 I'm good with the list, I'll likely turn around and approve most of the stable stuff anyway 15:26:02 the ipmitool data is a mess 15:26:08 sorry, derailing 15:26:10 later 15:26:27 mgoddard: oh yeah, very much so :( 15:27:18 dtantsur: yeah, I'm just puzzled by the output of the upgrade check, but we can talk later 15:27:21 I guess we should proceed to RFE review? 15:27:59 * dtantsur hides 15:28:09 let's 15:28:28 Proceeding onward! 15:28:31 #topic RFE Review 15:28:59 And now that dtantsur is hiding, he brings us a fun neat addition which could be extremely useful for things like usb drives :) 15:29:02 #link https://storyboard.openstack.org/#!/story/2005393 Use mDNS for discovering ironic and ironic-inspector services by the ramdisk 15:29:22 so, there is a lot of text there, but the idea is to allow IPA that got started anyhow to find ironic locally 15:29:52 essentially, enabling Bring-Your-Own-IPA :) be it a flash drive, a virtual media implementation that we do not support, or anything 15:30:19 the technical side is to use DNS service discovery + multicast DNS (details in the RE) 15:30:21 * RFE 15:30:32 I <3 it, personally 15:31:19 the v6 limitation is concerning, but I feel like we would be driving innovation 15:31:39 I really like the txt record, is there a length limit to the txt field? 15:31:50 the length of a UDP package, largely 15:31:59 so tail end of a packet 15:32:06 Makes sense I guess 15:32:11 to put it simply, yes 15:32:39 so we shouldn't get overly creative with using it, but we can add e.g. inspector collectors list 15:32:53 Makes tons of sense to me 15:33:06 or maybe even a trusted cert url :\ 15:33:35 yep 15:33:41 I'm all for this feature, are there any questions? 15:34:11 Totally as an aside, great job detailing everything dtantsur! 15:34:18 thx :) 15:34:21 It reads as very well thought out 15:34:45 * TheJulia begins to spin up the crickets 15:35:29 Any concerns out there? Are we good with this RFE? 15:35:54 I am good with it 15:36:06 I'm also good with it 15:36:15 totally good with that :) 15:36:29 * rloo still reading/grok'ing, wondering why it isn't a spec but maybe we're good with it in a story. 15:36:51 rloo: there's really not much to say in a formal spec structure 15:37:01 no API changes, no RPC changes, no driver changes, etc 15:37:21 so if I'm asked to do a spec, I'll mostly copy-paste the whole text into the "Proposed solution" :) 15:37:25 dtantsur: just config changes? (and code?) 15:37:36 yeah, config and code 15:37:53 and versioning? 15:38:04 no versioning impact 15:38:18 no API or RPC changes -> no versioning? 15:38:24 thought we had ipa versioning and this includes ipa code changes? 15:38:35 any security issues? 15:38:37 we have IPA API versioning, but this is not API 15:38:45 We do, but only to track conductor -> IPA API changes 15:38:47 (have we actually finished implementing it btw?) 15:38:56 (I haven't read the RFC or proposed SIG guidelines yet 15:39:03 dtantsur: basic guards I believe 15:39:29 i am not against it, just cannot be for it. but if we have enough cores that are good with it? 15:39:59 security wise, local segment so attached... and I believe the idea is to fallback to this if we don't have command lines? 15:40:03 if IPA broadcasting service, it's a way for polling instead of lookup, just imaging 15:40:03 err, command line/kernel params? 15:40:11 should the mdns server be integrated with the conductor? 15:40:22 is it not an external service? 15:40:22 fwiw, the usefulness of the spec process are the questions/sections, to make sure they are all covered :) 15:40:47 mgoddard: yep, why not? I mean, we could use Avahi, but that's a big thing to maintain compared to the actual code we care about 15:41:15 I don't mind writing a spec out of it tomorrow morning if people actually will review it :) 15:41:18 * TheJulia thinks rfe-approved and then time for open discussion 15:41:45 dtantsur: it's another dependency 15:41:56 dtantsur: as long as folks are good with it (and eg gone through and addressed/thought about things we typically ask in a spec) 15:42:17 mgoddard: python-zeroconf is quite small, one python file 15:42:21 dtantsur: i mean, if no one wants a spec and you/others think you've addressed any/most issues. 15:42:29 dtantsur: then don't write a spec. 15:42:36 dtantsur: ok, we can probably handle that 15:42:55 #topic Open Discussion 15:43:02 wondering now about making it optional. guess overkill to make it eg some sort of plugin. 15:43:10 So what if someone wants to or needs to run avhali??? 15:43:35 rloo: we don't have these kind of plugins, but it will be guarded by a configuration option (on the ironic side) 15:43:55 dtantsur: right, that's the overkill (for now :)) 15:44:11 Maybe a logical iteration may be to plugin-ize it 15:44:15 but not starting out 15:44:15 TheJulia: we got them covered: set [mdns]enabled=False and configure avahi the way they want :) 15:44:24 dtantsur: very true! 15:44:34 so plugins then are kind of silly 15:44:38 Anyway 15:44:46 mgoddard: yes, ipmi sensor data is crazy 15:45:17 TheJulia: yeah. Will there be an effort to provide some sort of schema? 15:45:18 iurygregory has been having some fun converting some sensor data to something prometheus can read via a plugin and it has been all sorts of fun. 15:45:48 it's \o/ 15:46:00 mgoddard: I _think_ the ideal path is for us to create plugins that can pre-sort/transform data and then transmit or offer up data as we go on 15:46:55 so if sensor data from vendor zz-alpha has super weird formatting, it can be transformed by a specific plugin 15:47:10 just someone would need to create that transform 15:47:30 Ultimately, it's a set of time series, with a name, 'dimensions' (in Influx speak) and possibly metadata 15:47:34 iurygregory: do you have the link handy to your pull request? 15:48:06 TheJulia, yup 15:48:16 I remember the IPMI sensor data being a big JSON blob, really we need a list of measurements 15:48:26 mgoddard: it varies by bmc 15:49:26 There is a whole huge section in the ipmi standard doc that you have to wrap your brain around to grok it. I think for redfish we should end up with something slightly more sane... Hopefully 15:49:36 mgoddard, yup is a huge json 15:49:47 https://github.com/metalkube/ironic-prometheus-exporter/pull/2 15:50:25 will ironic-prometheus-exporter be usable outside of metalkube? 15:50:39 mgoddard, yup 15:50:48 is bassicaly an oslo notifier driver 15:51:02 * etingof thinks that Redfish gives more freedom to the vendors that want to distinguish themselves 15:51:09 that will convert IPMI JSON metrics to prometheus format 15:51:52 I need to drop now, if you need anything tomorrow we can talk 15:51:55 we may want to take something like that into ironic or into our namespace at some point, but yeah, more thought likely required 15:51:59 goodnight iurygregory 15:52:03 good night ppl o/ 15:52:23 We were actually talking about this today, but with monasca 15:52:39 how do we get sensor data from nodes into monasca? 15:53:12 so how does monasca collect data? 15:53:14 the approach will probably be similar - consume rabbit notifications, translate, push to monasca 15:53:20 yeah 15:53:39 or 15:53:47 monasca has metrics identified by a name, with 'dimensions' - most commonly hostname 15:53:51 use the notifier plugin framework and grab the message before it is ever sent to rabbit 15:54:23 there is that option. we'd need to do translation in ironic 15:54:45 so maybe a ironic-monasca-exporter? 15:54:48 s/a/an/ 15:54:54 also have some 'business' logic for adding metadata to our metrics 15:54:56 Ilya Etingof proposed openstack/sushy master: Deprecate System-specific `IndicatorLED` state constants https://review.openstack.org/652709 15:55:12 but we could potentially do that in monasca later 15:55:21 I already added some of the metadata that we needed as well into the messages 15:55:30 but there may always be more needed 15:56:12 This sounds like an awesome integration point potentially 15:56:51 Anyway, we have four minutes left 15:56:59 Does anyone have anything else they would like to discuss? 15:57:22 you see my desire for standardisation? Standard metric names that at most would have some sensible transformation to get into prometheus/monasca/whatever format 15:58:06 I think we would need to take several vendors and essentially boil down what they offer into a condensed data set to really create standard metric names 15:58:06 For L3 Deploy spec, ironic already approved it. BUt it was not implemented yet, did we have plan to implement L3 deploy spec? 15:59:12 "drives_healthy" "power_healthy" instead of "drive1 connected: healthy" and "psu1: ok" and "psu3: ok" 16:00:05 w14161_1: It is not implemented. It is more about getting IP configuration information without DHCP. We had a contributor that started it but then went on to focus on other things and I think someone expressed interest in trying to pick it up this cycle 16:00:22 Anyway, it is time for the end of the meeting 16:00:25 Thanks everyone! 16:00:32 This doesn't mean we have to stop chatting though :) 16:00:34 #endmeeting