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