21:01:39 <jd__> #startmeeting ceilometer
21:01:40 <openstack> Meeting started Wed Apr 24 21:01:39 2013 UTC.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:44 <openstack> The meeting name has been set to 'ceilometer'
21:01:56 * dhellmann has finally figured out timezones
21:02:03 <dhellmann> and dst
21:02:06 <jd__> hehe dhellmann
21:02:18 * n0ano needs a dst tutorial
21:02:23 <dragondm> o/ howdy!
21:02:25 <dhellmann> google's calendar doesn't have a UTC timezone, but apple's ical does
21:02:25 <eglynn> o/
21:02:27 <n0ano> o/
21:02:27 <dhellmann> o/
21:02:30 <llu-laptop> o/
21:02:30 <apmelton> o/
21:02:33 <epende> o/
21:02:37 <jd__> dhellmann: oh it does, I use it
21:02:39 <gordc> o/
21:02:42 <eglynn> asalkeld sends apologies ... it's ANZAC Day
21:02:49 <eglynn> (a public holiday in Australia http://en.wikipedia.org/wiki/Anzac_Day)
21:02:55 * dhellmann will ask jd__ about that later
21:02:59 <fnaval> o/
21:03:11 <jd__> eglynn: was worried you meant prozac day, hopefully I googled :]
21:03:17 <eglynn> LOL :)
21:03:29 <jd__> #topic Blueprints creation and assignment for Havana
21:03:32 <sandywalsh> o/
21:03:50 <jd__> so our dear RM asked us to create blueprint, assign them to people and to havana series
21:04:02 <jd__> so let's do that this week!
21:04:02 <sileht> o/
21:04:18 <eglynn> yep, absolutely ... it's on todo list
21:04:24 <eglynn> (while the summit is still fresh)
21:04:43 <jd__> I think me and sileht are going to split alarming in bp, with help of eglynn and asalkeld I imagine :)
21:04:49 <sandywalsh> #link https://etherpad.openstack.org/stacktach-cm-integration
21:04:49 <jd__> so we'll coordinate as usual
21:04:56 <eglynn> cool
21:05:01 <sandywalsh> #link https://blueprints.launchpad.net/ceilometer/+spec/stacktach-integration
21:05:10 <jd__> feel free to cover other topics you're interested in and to ping me if you need help, or anything
21:05:13 <nijaba> o/
21:05:19 <sandywalsh> that's the Epic BP for the sub-bp's ^
21:05:37 <sandywalsh> still working on it
21:05:39 <jd__> sandywalsh: awesome
21:06:00 <jd__> sandywalsh: can you target this yourself to havana or should I?
21:06:08 <eglynn> are we aiming to have all Havana BPs filed and reviewed by end of week?
21:06:13 <eglynn> (or by next meeting?)
21:06:22 <jd__> eglynn: well next meeting/week would be good
21:06:25 <sandywalsh> jd__, not sure if I can ... lemme check
21:06:29 <eglynn> cool
21:07:01 <llu-laptop> ah, just want to ask the same question as eglynn's
21:07:15 <jd__> llu-laptop: same answer then
21:07:24 <sandywalsh> jd__, I targeted the epic to havana-3 ... will try to get the subs done tomorrow
21:07:24 <eglynn> sandywalsh: you may need to be on the drivers team https://launchpad.net/~ceilometer-drivers to do so
21:07:34 <eglynn> sandywalsh: scratch that!
21:07:38 <sandywalsh> :)
21:07:48 <jd__> sandywalsh: perfect, i've set the series to havana too
21:08:38 <sandywalsh> jd__, cool ... thanks
21:09:13 <jd__> I think you can set the series to havana and then I can approve
21:09:17 * jd__ discovers LP
21:09:28 <sandywalsh> seems to be set already
21:09:40 <jd__> sandywalsh: yeah I did it manually for this one :)
21:10:05 <jd__> and I'll set the priorities when we're done based on some random thoughts and opinions
21:10:29 <sandywalsh> cool ... I'll try to map the dependencies in best order I can
21:10:31 <nijaba> jd__: use coin flips too, please
21:10:33 <jd__> anything else you want to discuss on bp? we can coordinate later anyway
21:11:09 <jd__> nijaba: sure :-)
21:11:15 <sandywalsh> I have dependent olso and nova bp's as well, hopefully it all syncs up
21:11:48 <jd__> #topic Initial alarm implementation
21:12:09 <eglynn> it may make sense to split this monolithic patch into smaller more digestible chunks
21:12:15 <jd__> so the point was to discuss about the few bp and pieces we could start with and on
21:12:20 <jd__> eglynn: totally
21:12:30 <eglynn> e.g. core alarms API, storage layer, initial v. simple threshold evaluation, metric pre-aggregation
21:12:48 <jd__> +1 again :)
21:12:53 <eglynn> ... then maybe add history API, split transports, metric caching etc.
21:13:04 <jd__> eglynn or sileht, is there a particular area you prefer to tackle?
21:13:16 <llu-laptop> eglynn: what's "initial v."?
21:13:30 <jd__> I can coordinate the blueprints as a whole, but pick what you want to do :)
21:13:32 <eglynn> v. simple = very simple
21:13:45 <eglynn> yep, I'm pretty open
21:14:16 <eglynn> I wouldn't mind working on anything I spoke about at summit ... say the threshold evulation piece initially
21:14:40 <jd__> fine with me, sileht, opinion?
21:14:57 <sileht> me too
21:15:03 <eglynn> cool
21:15:26 <jd__> ok whatever you do, just synchronise :)
21:15:36 <jd__> I'll build some blueprints tomorrow unless someone wants to take over
21:15:41 <jd__> based on what eglynn described
21:15:51 <jd__> and you'll affinate if you want!
21:15:58 <jd__> like cheese.
21:16:09 <eglynn> jd__: cool, I'm up for helping with BP definition also
21:16:20 <jd__> eglynn: thank you :)
21:16:28 <jd__> eglynn: I'll ping you tomorrow then!
21:16:37 <eglynn> jd__: great!
21:17:19 <jd__> anything else?
21:17:31 <eglynn> sileht: in terms of splitting up the patch, git rebase -i / add -i are your friends ;)
21:18:03 <sileht> yep :)
21:18:28 <nealph> jd_: do we have a master list of bp's needing to be generated, or are we going from memory?
21:18:43 <nealph> or perhaps from the summit proposal list?
21:19:10 <eglynn> that's a good starting point, plus the etherpads
21:19:31 <jd__> nealph: yeah I think etherpad is a good starting point
21:19:34 <sandywalsh> nealph, I went from the summit talks and worked backwards
21:19:50 <sandywalsh> (and the etherpads, yes)
21:20:22 <nealph> sandywalsh:thanks, will look at doing the same.
21:20:43 <jd__> thanks guys
21:20:48 <jd__> #topic Open discussion
21:21:29 <n0ano> dare I ask what's happening with the Healthnmon integration/co-existence?
21:21:30 <DanD_> question for sandywalsh in your presentation you talked about a data model to support the events you want to add. is that available somewhere?
21:21:46 <sandywalsh> DanD_, the one I've been working from is on the etherpad
21:21:48 <jd__> n0ano: they're supposed to come to us with some piece of code we'd use
21:22:06 <eglynn> n0ano: primarly to give ceilo hypervisor breath & reach
21:22:07 <sandywalsh> DanD_, https://etherpad.openstack.org/Supporting-rich-data-types
21:22:07 <jd__> n0ano: first would be the virt pollster support for Xen and others
21:22:15 <sandywalsh> (and the github repo link is in there too)
21:22:29 <DanD_> ok thanks
21:22:30 <sandywalsh> DanD_, it's likely to change
21:22:34 <sandywalsh> but not terribly
21:22:52 <DanD_> i figured that we would like some input on it too :)
21:23:06 <n0ano> so that means we're effectively going straight to the coding phase & bypassing the architectural phase
21:23:14 <sandywalsh> DanD_, absolutely
21:23:25 <sandywalsh> n0ano, the what? ;)
21:23:49 <eglynn> n0ano: we spoke at lenght with them at summit about bridging the architectural mismatches
21:23:50 <sandywalsh> we definitely need to figure out the settling time problem and the multi-queue-per-data-type changes
21:23:55 <n0ano> I'm still unclear how the two integrate, are they separate services, do they get merged into one.
21:24:20 <dhellmann> n0ano: the idea is for the healthnmon team to bring their hypervisor monitoring agent into ceilometer to replace our existing agent
21:24:36 <dhellmann> it will need to change to emit data in the right format using the pipeline publisher, etc.
21:24:47 <sandywalsh> dhellmann, I thought the agent was going away in favor of the nova notification approach?
21:25:23 <jd__> yeah kudos for eglynn for clearing things with healthnmon :)
21:25:23 <eglynn> n0ano: IIRC the aggreement was that the peice of healthnmon that makes more sense to ceilo will move the ceilo, but the inventory manager peice stays separate
21:25:41 <dhellmann> sandywalsh: that was not my understanding based on the meeting I was in, but maybe I missed a conversation
21:26:08 <sandywalsh> eglynn, might want to re-confirm that
21:26:09 <jd__> sandywalsh: that was my understanding at some point, but that requires anyway someone to do that into Nova
21:26:41 <sandywalsh> dhellmann, jd__ we can help with that certainly ... an agentless approach will keep operations happy
21:26:41 <n0ano> this is why I prefer the mailing list, things are more concrete when typed out
21:26:41 <dragondm> sandywalsh: helthnmon's agents monitor multiple hypervisors. It's more sensible, since the code exists, and they can monitor things outside of Nova's sphere (i.e. host stats)
21:26:44 <dhellmann> if nova starts emitting enough data frequently enough, we don't need the healthnmon agent, so there's nothing to integrate, right?
21:26:48 <llu-laptop> sandywalsh: by saying agent, do you mean compute agent or central agent?
21:26:54 <eglynn> my understanding is that initially their hypervisor drivers will be used to extend our virt inspector model to be non-libvirt-specific
21:27:24 <eglynn> (we wrap in our compute agent as opposed to taking their agent)
21:27:41 <eglynn> eventually tho' the compute agent goes away in fvour of native nova notifications
21:27:42 <dhellmann> We have, I think, had this conversation several times. Perhaps what we need is a blueprint with a specific proposal?
21:27:46 <sandywalsh> hmm
21:27:52 <DanD_> I would be happy if the nova events and the seperate agent could cooexist initially but you could turn one or the other off
21:27:56 <llu-laptop> eglynn: that's my understanding too.
21:28:04 <n0ano> dhellmann, +1
21:28:22 <dragondm> also their proxies/agents/whatever monitor n to 1 hypervisors. They don't need to be installed on the computes.
21:28:43 <sandywalsh> dhellmann, what's "frequently enough"?
21:28:48 <eglynn> ok let's try to codify what we all took from the conversation with healthnmon into a BP
21:28:53 <dhellmann> sandywalsh: that's up to the deployer
21:28:55 <eglynn> I'll get the ball rolling tomorrow
21:28:59 <sandywalsh> dragondm, good point, forgot about that part
21:29:23 <dhellmann> dragondm: right, that was the other key feature (in addition to having more drivers than we do now)
21:29:40 <sandywalsh> dhellmann, I think we need to have limits on what's possible there. The could result in a *lot* of messages
21:29:52 <sandywalsh> dhellmann, can't just say "it's up to you"
21:30:19 <dhellmann> sandywalsh: they wouldn't all go to the message bus, it would depend on how the pipeline is configured
21:30:35 <sandywalsh> dhellmann, true, but still
21:30:48 <sandywalsh> anyway, certainly room for more discussion
21:31:07 <dhellmann> yep
21:32:00 <dragondm> I'll want to look at how the healthnmon pollers send their data. Given the n-1 polling, they could condense alot into a smaller # of messages.
21:32:32 <dhellmann> it will need to be updated to use the pipeline publisher in ceilometer, and that does support batching
21:33:24 <eglynn> cool, do we have specific actions on this topic?
21:33:47 <eglynn> e.g. #action eglynn get BP(s) on healthnmon proposed as a condensation point for discussion & agreement
21:35:14 <dhellmann> yes, I think it would be really helpful to have the proposals for changing hypervisor "polling" written down so we have something concrete and everyone can understand what will be changed, why, and potentially when
21:35:32 <dhellmann> I think we have 2 proposals, for nova notification changes and for healthnmon's agent
21:35:40 <dhellmann> those should be considered separately
21:35:50 <eglynn> dhellmann: +1
21:36:15 <sileht> I must go, see you
21:36:20 <eglynn> are BPs the best way to do this?
21:36:30 <eglynn> or wiki/ML/etherpad?
21:36:41 <eglynn> sileht: bye!
21:36:46 <sandywalsh> dhellmann, +1
21:36:55 <dhellmann> I think a combination of BP, wiki, and then ML for discussion makes sense
21:36:56 <nijaba> goodnight sileht
21:37:18 <dhellmann> we need the BP for tracking, we need the wiki for details, and we need the ML for hashing it out to make sure we all understand and all details are covered
21:37:41 <eglynn> so, all of the above ;)
21:38:24 <dhellmann> well, no etherpad, but we have some notes there now so I guess yeah :-)
21:38:34 <sandywalsh> ours is essentially done, which consists of adding the xen hypervisor driver support to libvirt
21:38:50 <sandywalsh> and then the .exists records will be correct
21:39:13 <dhellmann> cool
21:39:37 <jd__> nice
21:39:38 <eglynn> so is the goal just xenapi & libvirt? (healthnmon have coverage on ESX, hyper-V etc.)
21:39:52 <jd__> I'd tend to answer the goal is nova… :)
21:39:57 <eglynn> not that I'm shouting for ESX, hyper-V support or anything ;)
21:40:05 <dhellmann> we want to cover all of them if we can, right?
21:40:20 <jd__> sure
21:40:33 <sandywalsh> the mechanism is already in the virt layer, if the hypervisor maintainers support or not is a different question.
21:41:01 <eglynn> that's fair enough
21:41:24 <sandywalsh> one option would be for HP to put their last mile code in a library and the virt drivers could just access it ... dunno
21:41:29 <eglynn> the healthnmon guys would argue that they've got the existing hypervisor breath right now
21:41:36 <dhellmann> should we open bugs against the hypervisor drivers that don't provide the data, in nova?
21:41:43 <sandywalsh> agreed
21:41:48 <eglynn> makes sense
21:41:50 <sandywalsh> (to both points :)
21:42:26 <sandywalsh> if they want CM support, it would need to be in there
21:42:44 <dhellmann> I wonder if they don't know we want it, though?
21:42:51 <sandywalsh> I'm sure they don't
21:43:19 <dhellmann> it sounds like we need a volunteer to open some bugs.
21:43:20 * dhellmann not it
21:44:10 <sandywalsh> #action, sandywalsh will open bugs for virt layers support with other hypervisor maintainers
21:44:28 <dhellmann> thanks, sandywalsh :-)
21:44:29 <eglynn> so the bugs would be for parity with xenapi on the bw counters / get_diagnostics APIs?
21:44:36 <dhellmann> right
21:44:38 <sandywalsh> correct
21:44:44 <eglynn> cool, understood
21:44:46 <dragondm> yup
21:44:59 <dhellmann> even if we do still use an agent (ours, healthnmon, whatever), it would be good for those notification messages to be consistent
21:45:12 <eglynn> yep, absolutely
21:45:13 <dragondm> also yup.
21:45:41 <jd__> cool :)
21:47:29 <jd__> ending the meeting in a minute unless someone has anything else
21:47:55 <eglynn> nowt from me ...
21:48:04 <dhellmann> that's all I have
21:48:13 <sandywalsh> that's enough :)
21:48:18 <jd__> thanks guys!
21:48:19 <jd__> #endmeeting