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