05:00:37 #startmeeting Ironic 05:00:37 #chair devananda 05:00:38 Meeting started Tue Feb 3 05:00:37 2015 UTC and is due to finish in 60 minutes. The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:00:39 Welcome everyone to the Ironic meeting. 05:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:00:42 The meeting name has been set to 'ironic' 05:00:43 Current chairs: NobodyCam devananda 05:00:51 hi 05:00:53 Of course the agenda can be found at: 05:00:56 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 05:01:00 good evening 05:01:09 #topic Greetings, roll-call and announcements 05:01:09 Roll-call: Who's here for the Ironic Meeting? 05:01:24 lol howdy y'all 05:01:24 o/ 05:01:25 \o 05:01:26 o/ 05:01:27 o/ 05:01:30 hi 05:01:31 \o 05:01:32 o/ 05:01:55 :) I may fall asleep just kick e if I do :) 05:02:09 great to see everyone here :) thank you :_ 05:02:19 announcements: 05:02:21 NobodyCam: :) 05:02:21 Devananda may be lurking, but I expect he's having fun in Grenoble. 05:02:35 I hope he's sleeping :P 05:02:42 speaking of the Grenoble meet up is going on now! 05:02:55 lol its only 6 there :-p 05:02:57 hehehe 05:03:31 oh Question Does anyone know if there is a ether pad to follow along with them? 05:03:38 yep 05:03:40 #link https://etherpad.openstack.org/p/kilo-ironic-midcycle 05:03:50 (is for both meetups) 05:03:53 awesome thank yoy jroll :) 05:03:55 nice 05:04:41 oh ya... there is also a meetup in san fran next week :) 05:04:52 anyone in this meeting attending the sf meetup next week? 05:04:54 Thank you RackSpace for hosting 05:05:01 o/ 05:05:03 (besides josh and I) 05:05:17 \o/ 05:05:23 lol 05:05:38 all of the onmetal people will be there 05:06:02 :) awesome 05:06:22 thats really it for my announcements anyone else have any? 05:06:23 NobodyCam: may want to announce kilo 2 is thursday 05:06:33 #link https://launchpad.net/ironic/+milestone/kilo-2 05:06:37 lots to review 05:06:40 oh yes 05:07:07 what features are targeted for kilo2? 05:07:26 see the link there, wanyen 05:07:36 wayan all on that link jroll pasted 05:07:58 #topic kilo-2 progress 05:08:02 none of the iLO specs are targeted? 05:08:33 wanyen: which ones can be code complete by thursday? 05:08:42 amt is blocked? 05:08:44 I would like to add iLO hw instrospection 05:09:12 NobodyCam: it's waiting on a spec update 05:09:14 #link https://review.openstack.org/#/c/141269/ 05:09:24 and introspection mgmt i/f 05:10:00 wanyen: I see ilo introspection is targeted to kilo 3 05:10:30 the coding is pretty much done for ilo intropsepction 05:10:35 wanyen: no code is proposed for that as far as I can find 05:10:55 * jroll still looking 05:10:58 okay. let me discuss it with Nisha 05:11:22 oh, I see it now 05:11:35 Ty jroll let see if we can unblock that amt by tomorrow 05:11:42 please have Nisha us the blueprint for the topic, e.g. bp/blueprint-name 05:11:48 wanyen: ^ 05:11:51 NobodyCam: +1 05:11:55 cool 05:12:24 * jroll will review tonight 05:12:31 jroll,, what;s about blueprint-name? 05:12:34 looks like most are in need of code review 05:13:05 wanyen: code should be tagged with the blueprint name in the commit message and gerrit topic, or else it's hard to find 05:13:17 all love to get eyes one the code reviews for anything tagged for k-2 05:13:20 jroll, I see. 05:13:24 I think we have enough review to do in the next 3 days, I'd rather not target anything more to k-2 05:13:34 jroll: +1 05:13:55 how are cleaning states looking? 05:14:00 bump to k-3? 05:14:05 yeah, need to bump that 05:14:13 JoshNang: ^ correct? 05:14:13 iLO driver has quite a few specs therefore I would like to traget at least one for Kilo2 05:14:50 wanyen: I just dont know if we'll have the review time 05:15:00 wanyen: kilo-2 is thursday, can any of those be coded, reviewed and merged by thursday? I kind of doubt it. if one happens to make it that's great, but I don't think it's priority 05:15:04 there a lot up now 05:16:01 jroll, I think Niahs is pretty much done with coding 05:16:12 anything eles on what we need for k-2? 05:16:31 wanyen: we can try 05:16:32 Can we just target it if it makes to Kilo that's great otherwise wait for kilo3? 05:16:46 wanyen: all of nisha's introspection code is failing tests... I don't think it's done, we can try but it's bottom of the priority list 05:16:47 NobodyCam; ty 05:16:52 jroll: yeah it's going to need a bump 05:17:09 cores are reviewing like crazy this week, don't overwork us too hard :P 05:17:11 i'm planning on actually writing code for cleaning tomorrow, but it won't land 05:17:19 JoshNang: cool, thanks 05:17:20 (land by thurs, that is) 05:17:29 JoshNang: are you bumping? 05:17:40 I'm doing it now 05:17:46 kk 05:17:46 ty 05:17:49 thanks! 05:17:50 hehe 05:18:00 oh idk if I can 05:18:12 anything else for k-2 05:18:25 yeah, I can't bump that, I'll ping deva 05:18:52 ok moving on... 05:18:52 jroll: i bumped it 05:18:58 oh, neat 05:19:03 #topic SubTeam: status report (deprecated) 05:19:14 any questions, on the status we have? 05:19:19 "deprecated" :P 05:19:26 #link https://etherpad.openstack.org/p/IronicWhiteBoard 05:19:30 status report is ^ as always 05:19:32 some folks are at hte meet up so we may be a little stat lite 05:19:57 I see looks like we have a Proposal to make agent_ssh jobs vote.. w00t 05:20:10 yes! 05:20:15 I put that up today 05:20:29 clarkb said he was cool with it in terms of gate resources and whatnot 05:20:41 jroll: off the top of your head you know the current pass / fail %'s 05:20:56 NobodyCam: no, but anecdotally it's just as stable as the pxe_ssh job 05:21:13 then I think its something we need 05:21:13 I haven't seen a not-real failure in a while afaik 05:21:16 yep 05:21:32 I saw a patch that actually broke it today, so decided to put that up 05:21:39 thoughts form other folk? 05:22:13 I take that as a do it 05:22:18 :) 05:22:21 +1! 05:22:23 ++ 05:22:45 jroll: you have a link for the review? 05:23:15 #link https://review.openstack.org/#/c/152340/ 05:23:24 awesome :) 05:24:11 # info agent_ssh to be voting in gate when https://review.openstack.org/#/c/152340/ lands 05:24:42 did you want #info? 05:24:44 :) 05:24:52 doh 05:25:02 #info agent_ssh to be voting in gate when https://review.openstack.org/#/c/152340/ lands 05:25:19 ok moving on 05:25:25 #topic Discuss per driver sensor meters spec 05:25:32 wanyen: thats you 05:25:37 Jim and myself would like to discuss “Support per driver sensor meters” spec https://review.openstack.org/#/c/130074/. This spec proposes 3 work items. It looks to me that all reviewers agreed to the 1st two proposed work items, namely conductor to remove all ipmi assumptions and to allow drivers to collect sensors for un-deployed nodes. However, there seems to be different opinions on whether to have conductor to 05:26:06 wanyen: you cut off at "different opinions on whether to have conductor to" 05:26:07 However, there seems to be different opinions on whether to have conductor to do meter sensor and resource id naming needed for the targeted metering systems. We would like to discuss this proposed work item and hopefully get guidance/resolution on this. Jim is the author of the spec so I will hand the discussion over to Jim. 05:26:39 do we have a link to the spec? 05:26:40 jmanko, do you want to give more details? 05:26:56 https://review.openstack.org/#/c/130074/ 05:26:57 #link https://review.openstack.org/#/c/127378/ 05:26:58 #link https://review.openstack.org/#/c/130074/ 05:27:13 ??? 05:27:34 Ok, current spec outlines conductor doing meter name transformation instead of ceilomter plugin 05:28:01 This enables a single generic plugin in ceilometer instead of a per sensor provider plugin. 05:29:20 wanyen: jmanko which of the two specs are we looking at? 05:29:27 what's the argument for the conductor not doing meter name things? 05:29:34 transformation, I guess 05:29:48 what does "meter name transformation" entail, anyway? 05:29:49 It's the per driver sensor meter spec 133074 05:30:03 if conductor supports multiple metering systems, more code in the conductor instead of inside metering system plugins 05:30:15 sorry 130074 05:30:38 character string transformation to valid metering system characters 05:31:00 and metering system name composition 05:31:36 a small amount of code from my perperspective 05:32:07 hm, so the debate is 1) conductor builds the sensor names vs 2) sensor plugin (e.g. ceilometer) builds the sensor names? 05:32:28 pretty much, 05:32:56 reading Chris Dent's comments on rev 6 now 05:33:10 "sensor names" being the keys in the key/value structure of the data, I guess 05:33:41 I don't see how the conductor can do it generically for many sensor providers, since there may be different valid characters/names/etc 05:34:05 e.g. / and . have meaning to graphite (if we were to make a graphite plugin) 05:34:20 (idk if those have special meaning in ceilometer) 05:34:23 jroll: Thats where I'm leaning 05:35:09 conductor should not have to account for every thing. thats what plugins are for really 05:35:21 I mean, the conductor could do normalization of the sensor name, but the plugins will have to do other things specific to that provider 05:35:37 like conductor could normalize "cpu temperature" to "cpu_temperature" 05:35:44 There isn't so much special meaning as there is inability to use certain characters in keys meter names. 05:35:52 jroll: righ 05:36:05 jroll: +1, should depends on sensor providers to handle the naming logic 05:36:06 but only the ceilometer plugin can know if _ is valid 05:36:12 simple transformation for acceptable characters 05:36:46 acceptable metering system character set. 05:37:10 for both keys and meter name strings 05:38:31 jroll: The plugin can 100% generic (provider independent) 05:38:45 Chris dent on the other hand like the idea of having a generic ccilometer plug-in. 05:39:21 no, chris dent wants a completely generic sensor emitter 05:39:34 however different sensor consumers will have different APIs, formats, etc 05:39:35 with a generic celiometer plug-in then producer will need to do the naming xformation 05:39:39 It's a pain to coordinate release of ironic with appropriate ceilometer plugin 05:40:03 wait, define "ceilometer plugin" for me? 05:40:27 I feel like you're not talking about what I think you're talking about 05:40:44 There is an IPMI sensor plugin in ceilometer today that creates meters for sensors 05:41:11 The plugin assumes the producer of the sensors it receives are from an ipmi driver 05:41:25 oh. 05:41:29 oh 05:41:41 I assumed ceilometer just took a key/value and stored it 05:42:00 sigh, why does ceilometer care if the metrics are from an ipmi thing 05:42:06 no no no. Ceilometer morphs sensor data into meter names 05:42:29 That is the issue! Ceilometer shouldn't care who produced them. 05:42:53 jmanko: ya I see yourpoint 05:43:02 so if we send e.g. hardware.current, it won't care? 05:43:09 (as opposed to hardware.ipmi.current) 05:43:58 yes if ironic creates the name 05:44:14 Today, the ceil plugin creates the name hardware.ipmi.current 05:44:17 and the goal here is to send sensor data from non-ipmi drivers, and have the names normalized, correct? 05:44:28 so that ipmi sensors and ilo sensors look the same? 05:44:29 we defined the ipmi-independent data model for sensor data which send out via notification bus - https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L567 05:44:59 current, fan, are the sensor types 05:45:37 yes, but if you need a new one like "health" you have change the ceilometer plugin today. 05:46:00 yeah, that's horrible 05:46:17 where's the code that sends things to ceilometer? 05:46:25 jmanko: that is because ceilometer hardcode the sensor types I think 05:46:43 jroll: in the conductor 05:46:55 jroll: this is the base method interface - https://github.com/openstack/ironic/blob/master/ironic/drivers/base.py#L567 05:47:08 Haomeng: Yea, its the way the Ceilomter plugin is implemented 05:47:16 ok yeah, I hate this 05:47:33 does anyone actually run ceilometer in production? 05:47:38 jroll: and this one - https://github.com/openstack/ironic/blob/master/ironic/conductor/manager.py#L1139 05:47:46 Haomeng|2: right, I've found it 05:48:05 jroll: :) 05:48:09 the word 'ipmi' should never appear in ironic.conductor.manager 05:48:18 that seems like a huge violation of concerns to me 05:48:42 I'm +1000000000 on making this generic 05:48:42 I've used ceilometer (not in production) and tried to write code which makes use of sensors. It's not straightforward 05:48:46 probably the way of this spec 05:48:57 yes, but the event type is requried for ceilometer, they suggest to define - 'event_type': 'hardware.ipmi.metrics.update' 05:49:22 You get rid of that and have a single sensor event type 05:49:25 jroll: so it is ceilometer special 05:49:38 the other way to deal with this is to add e.g. hardware.ilo.metrics.update to ceilometer 05:49:45 and hardware.drac.metrics.update 05:49:49 and so on and so on 05:49:57 jroll: yes, this is issue 05:50:06 and that seems like a huge violation of separation of concerns to me 05:50:09 * ten minutes* 05:50:13 I wanted this generic so I could send sensor data to other metering systems. I was able to easily use Monasca 05:50:19 jroll: we can define as common name such as 'hardware.metrics.update' 05:50:27 +1 05:50:34 jmanko: +1000 05:50:45 jroll: but not sure if ceilometer can handle such common name 05:50:47 we shouldn't hard depend on ceilometer, this should be pluggable 05:51:04 Haomeng|2: then we drop support for ceilometer, that's absurd if they can't handle it 05:51:09 (or we fix ceilometer) 05:51:24 jroll: ++ for fix 05:51:37 to be clear, it won't be me fixing it :) 05:51:52 jroll: ++ 05:52:03 jmanko: I think I like the direction of this spec 05:52:22 ok so did I get yes to making it more generic? 05:52:29 it's a yes from me 05:52:33 and from me 05:52:39 ++ 05:52:40 wanyen: ?? 05:52:42 +1 from irmc's point of view 05:52:56 the I's have it 05:53:01 jmanko: I'm going to promise to do a proper review on this spec, with more research etc 05:53:02 cool 05:53:16 jmanko: please ping me if I don't review it this week and yell at me :) 05:53:16 jroll, ty 05:53:18 thank you wanyen and jmanko 05:53:19 jroll: Great :) 05:53:33 and everyone for there input 05:53:34 thank you 05:53:43 ok inthe last few minutes 05:53:43 cool, anything else on this topic? 05:53:48 #topic Open Discussion 05:54:00 doh 05:54:12 should we #undo and have an #agreed there 05:54:14 ? 05:54:30 #topic Discuss per driver sensor meters spec 05:54:45 lol 05:54:51 I raised one bp for our ironic-discovery - https://blueprints.launchpad.net/ironic-discoverd/+spec/in-band-ipmi-auto-configuration, welcome your comments if this is good idea:) 05:55:32 ilo driver stillhave quite a few specs taht needs review and approval, so please review them, ty 05:55:38 Haomeng|2: neat idea 05:55:53 #agreed to make ironic more handle sensor data in a more generic way 05:56:02 #topic Open Discussion 05:56:07 jroll: :) 05:56:41 open discussion: I need sleep 05:56:49 same here 05:57:03 lol yep 05:57:16 if theres nothing more we can end the meeting 05:57:34 I've got nothing 05:57:36 awesome meeting everyone one thank you 05:57:43 NobodyCam: thank you:) 05:57:44 ty 05:57:46 thanks for chairing, NobodyCam! :) 05:57:48 see ya all tomorrow 05:57:48 NobodyCam: good night! 05:57:50 thanks 05:57:51 bye thank you 05:57:52 #endmeeting