21:00:02 <nijaba> #startmeeting Ceilometer 21:00:02 <nijaba> #meetingtopic Ceilometer 21:00:02 <nijaba> #chair nijaba 21:00:02 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda 21:00:03 <openstack> Meeting started Wed Nov 7 21:00:02 2012 UTC. The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:05 <openstack> The meeting name has been set to 'ceilometer' 21:00:08 <openstack> Current chairs: nijaba 21:00:11 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting? 21:00:11 <nijaba> o/ 21:00:12 <dhellmann> o/ 21:00:29 <timjr> \o 21:00:31 <eglynn> o/ 21:00:36 <rhochmuth> 0/ 21:00:41 <anniec_> o/ 21:01:10 <tasdomas> o/ 21:01:18 <nijaba> #topic actions from previous meeting 21:01:38 <nijaba> #topic nijaba to send private email to all comitter to come vote on the etherpad in the next 24h 21:01:44 <nijaba> that was done 21:02:05 <nijaba> #topic nijaba to then update wiki page as follow: 3+ votes=high, 1or2 vote=medium, low for rest in terms of priorities 21:02:19 <nijaba> I updated the roadmap page, we'll discuss this a bit later 21:02:40 <nijaba> #topic nijaba to prepare survey for ml next week 21:02:56 <nijaba> some of view may have bee 21:03:04 <nijaba> invited to check it out 21:03:15 <nijaba> we'll discuss it in a bit 21:03:33 <nijaba> #topic dhellmann update versioning in ceilometer repo to match openstack standards 21:03:39 <dhellmann> I'm working on that right now. 21:03:54 <jd__> (hi) 21:03:56 <dhellmann> I think I've figured out what to do, so I expect to have the changes ready before our next meeting. 21:03:57 <nijaba> cool. any issues? 21:04:04 <dhellmann> it's confusing, but I'm working it out 21:04:14 <dhellmann> if I run into blockers, I know who to talk to for help 21:04:19 <jd__> isn't that just changing version to 2013.1 ? 21:04:28 <nijaba> ok, should we carry the action for next meeting? 21:04:37 <dhellmann> jd__: no, there are some modules in common for keeping it up to date correctly 21:04:39 <dhellmann> nijaba: yes 21:04:51 <jd__> dhellmann: ok :) 21:04:52 <nijaba> jd__: dhellmann has to use a funky vresion generation script 21:05:09 <nijaba> #action dhellmann update versioning in ceilometer repo to match openstack standards 21:05:21 <dhellmann> I've been trying to cargo-cult it from some changes proposed for quantum 21:05:38 <nijaba> #topic nijaba to add eglynn to ceilometer drivers on satureday if all goes well 21:05:42 <dhellmann> but I guess I'm going to have to actually learn how this code works :-) 21:05:56 <nijaba> eglynn is now a core dev for ceilometer. congrats! 21:06:00 <dhellmann> welcome! 21:06:01 <eglynn> thanks! 21:06:16 <jd__> \o/ 21:06:19 <asalkeld> go eglynn 21:06:42 <nijaba> asalkeld: you'll likely be next ;) 21:06:51 <dhellmann> I've seen no objections for asalkeld's nomination. I need to go back and look at the date on that email. We wait 5 days, right? 21:07:02 <nijaba> right 21:07:03 <nijaba> t 21:07:09 <nijaba> that should be tomorrow 21:07:15 <dhellmann> ah, good 21:07:34 <nijaba> #topic dhellmann update readthedocs copy of our docs 21:07:43 <dhellmann> I believe that is done 21:08:01 <nijaba> nice, thanks 21:08:06 <zykes-> (c�ear 21:08:18 <nijaba> zykes-: ?? 21:08:31 <nijaba> #topic jd and nijaba to start preparing a video demo of ceilometer 21:08:52 <zykes-> nijaba: nothing :) 21:08:54 <nijaba> we discussed it on monday night, and now have a plan! 21:09:20 <nijaba> jd__ and I are to start a script, but have not started on it yet 21:09:27 <nijaba> so we'll carry it on 21:09:31 <jd__> suggestions welcome :) 21:09:45 <nijaba> #action jd and nijaba to start preparing a video demo of ceilometer 21:09:48 <dhellmann> this is an intro to ceilometer itself, right? not just for developers? 21:09:55 <nijaba> right 21:10:08 <zykes-> using horizon or ? 21:10:10 <harlowja> video demo, nice 21:10:24 <nijaba> we were thinking 5 min intro slides, then short demo 21:10:36 <nijaba> using the den 21:10:58 <nijaba> debug stuff jd__ wrote which is very nice to show activity 21:11:11 <dhellmann> sounds like a good idea 21:12:04 <nijaba> #topic Review priorities as proposed on EfficientMetering/RoadMap 21:12:22 <harlowja> i think timjr is doing some interesting stuff with visualizations 21:12:26 <harlowja> might be interesting also 21:12:40 <nijaba> ok, so I updated the page using the result from our "voting" for priorities 21:12:53 <nijaba> harlowja: that would be welcome 21:12:58 <dhellmann> nijaba: did we really get the sqlalchemy backend as "low" priority? 21:13:16 <nijaba> dhellmann: yep, so I think a few items need adjustement 21:13:34 <dhellmann> indeed, that's a high priority for us at DH 21:13:47 <dhellmann> jtran: what's the status of that driver, I haven't had a chance to look at it in a couple of days 21:13:59 <jtran> sorry, reading back.. 21:14:15 <jtran> oh sqlalchemy, i implemented the API methods for max and sum 21:14:22 <jtran> I don't think there are anything left. 21:14:32 <jtran> at least i didn't see any tickets in that regard 21:14:33 <dhellmann> oh, good 21:14:39 <dhellmann> I'll run some tests with it asap 21:14:45 <nijaba> nice 21:14:57 <timjr> oop, late to the party 21:15:05 <nijaba> jtran: should I mark it as done on http://wiki.openstack.org/EfficientMetering/RoadMap? 21:15:07 <timjr> yeah, so I'm currently screwing around with zipkin 21:15:09 <harlowja> timjr: signed u up for everything 21:15:11 <harlowja> ha 21:15:13 <timjr> drat 21:15:29 <jtran> nijaba: to be safe i'd wait until dhellmann takes a quick test 21:15:52 <timjr> zipkin is a scala implementation of dapper (googles "distributed tracing infrastructure"). it's open source, and it has some d3.js rendering in the front end 21:16:04 <nijaba> jtran: done but not tested is still done, I think ;) 21:16:16 <timjr> I think that's a really nice system for understanding what your openstack cluster is up to... so I'm prototyping with it to see what's required 21:16:17 <jtran> nijaba: in that case, yes ! ;) 21:17:06 <nijaba> timjr: and you are basing it off the data we collect? 21:17:22 <timjr> no 21:17:40 <eglynn> nijaba: did a single vote translate to a "low" priority on the roadmap? 21:18:02 <nijaba> eglynn: yep, that was what we agreed on, but need to tune now 21:18:22 * eglynn thought he'd voted for the 'assess Synaps' task 21:18:40 <dhellmann> timjr: so this work is exploratory? 21:18:48 <timjr> yes 21:19:11 <nijaba> eglynn: ah, right, my mistake there, should hvae been marked 21:19:14 <timjr> whatever I do for monitoring, I don't want to make it impossible to use it for dapper-style tracing 21:19:25 <timjr> so this is an easy way to check :) 21:19:29 <eglynn> nijaba: cool 21:19:34 <nijaba> eglynn: fixed 21:19:39 <eglynn> thanks! 21:19:43 <dhellmann> timjr: makes sense 21:19:46 <nijaba> anyt 21:20:08 <nijaba> anything else on the roadmap that does not make sens before I sort it? 21:20:50 <asalkeld> how long do we have to get features in? 21:20:54 <nijaba> also, if you know the bug # for the bugless tasks, feel free to complete 21:21:03 <dhellmann> nijaba: we should take out the nova-volume item, since we decided not to do it 21:21:33 <nijaba> asalkeld: until G3 for the base implementation 21:21:41 <dhellmann> http://wiki.openstack.org/GrizzlyReleaseSchedule 21:21:49 <dhellmann> g3 is feb 21 21:21:58 <nijaba> dhellmann: I just wanted to keep the decision documented... 21:22:06 <asalkeld> there is the monitoring blueprint 21:22:12 <dhellmann> that's going to be a bit of a challenge with the holiday season at the start of this cycle 21:22:18 <dhellmann> nijaba: ah, ok 21:22:21 <asalkeld> but not sure it could land in time 21:22:27 <asalkeld> https://blueprints.launchpad.net/ceilometer/+spec/monitoring 21:22:30 <asalkeld> lots to do 21:22:57 <dhellmann> asalkeld: the teambox link on that page gives me a 404 21:23:10 <jd__> asalkeld: that should depends on multi-publisher blueprint I think, no? 21:23:10 <asalkeld> yea, me too - I'll sort it 21:23:19 <asalkeld> sure 21:23:35 <jd__> I'll add it then :) 21:24:00 <asalkeld> say, any reason why compute agent is in ceilometer and not in nova? 21:24:27 <asalkeld> just seems to make more sense there IMO 21:24:39 <jd__> because we're not core I'd say 21:24:40 <dhellmann> asalkeld: it depends on ceilometer code that was only in our project at the time, and we were trying to be "self contained" as much as possible for the last cycle 21:24:44 <nijaba> asalkeld: simplicity, but we should push as much as possible to nova now that we are incubated 21:24:54 <asalkeld> k 21:25:09 <asalkeld> just makes that whole db issue go away 21:25:34 <dhellmann> yeah -- it would be nice if there was a way to have nova load extensions that wanted periodic tasks 21:25:49 <eglynn> aren't we moving towards avoiding DB access by using the novaclient? 21:25:52 <dhellmann> then we could release it as a plugin 21:26:15 <eglynn> (to list instances on a host etc.) 21:26:19 <dhellmann> eglynn: yes, but we do still import nova's libvirt wrapper code, and it would be nice to get rid of that dependency, too 21:26:46 <asalkeld> yea, dhellmann we could just have the same agent, but in nova 21:26:53 <jd__> I think we could export the function we need over RPC 21:27:02 <dhellmann> asalkeld: that might make sense 21:27:05 <nijaba> pollster for metering network bandwidth is marked as partially done. Any plan from anyone to complete? 21:27:07 <jd__> that's something that could be accepted 21:27:33 <dhellmann> nijaba: I think that's done 21:27:42 <nijaba> dhellmann: ok, \i'll fix then 21:27:45 <jtran> dhellmann: not external 21:27:48 <dhellmann> the associated bug is marked "fix released" 21:27:50 <jtran> nijaba: not done 21:27:57 <dhellmann> jtran: external traffic? 21:28:07 <jd__> we only have VM vif counters 21:28:09 <jtran> the network bandwidth metering only implemented for internal network banadwidth 21:28:16 <nijaba> jtran: do you have a good solution to distinguis external traffic? 21:28:28 <nijaba> jtran: dhellmann used something totally differetn 21:28:29 <jtran> nijaba: no. i looked into that before using iptables accounting. is not easy 21:28:33 <dhellmann> jtran: I don't think there's any way for us to get external stats 21:28:49 <dhellmann> we're asking our router for those stats (each tenant has a software router) 21:28:51 <jtran> dhellmann: ok, if we are not considering external traffic, then please go ahead and mark it done 21:28:53 <nijaba> jtran: so I think we should mak it done even though we have limitatins 21:29:21 * jd__ agrees 21:29:23 <dhellmann> I agree. Even if we find a better solution, we're likely to need a couple of implementations for different configurations. 21:29:46 <nijaba> updated 21:30:16 <salmon_> I yhon you can get it from openvswitch 21:30:21 <salmon_> *I think 21:30:34 <nijaba> so, If you agree, I'll action myself to sort the list by prio, add bugs if none exist for each item on the list 21:30:45 <jtran> salmon_: i haven't looked at the openvswich/quantum implementation. that's probably likely. 21:31:00 <jd__> nijaba: don't hesitate to use blueprints also for changes/features :) 21:31:03 <nijaba> but I would need someone's help to give t-shirt size to features 21:31:07 <eglynn> backtracking to the ceilo-agent-moves-into-nova idea for a sec ... 21:31:18 <eglynn> so that seems to leak some monitoring-related concerns into nova, frequency of the polling cycle etc. 21:31:30 <eglynn> also, can we rely on the timeliness of periodic tasks within a loaded nova compute agent? 21:31:46 <asalkeld> have as a seperate daemon 21:31:51 <asalkeld> (as now) 21:32:06 <asalkeld> and same/simerlar config options 21:32:07 <eglynn> would that defeat the purpose slightly? 21:32:08 <nijaba> eglynn: and keep it under our responsability to maintain it 21:32:21 <dhellmann> what would be the point of moving it to another git repo, then? 21:32:25 <eglynn> (i.e. to simplify the deployment, one fewer worker etc.) 21:32:43 <asalkeld> eglynn, it's to make accessing the data easier 21:33:04 <asalkeld> not having to import nova stuff from ceilometer 21:33:15 <harlowja> eglynn: if celiometer provides a library, could then we ask the nova people to write hookins to that library, idk 21:33:15 <eglynn> yep, it would allow 'private' APIs to be used freely 21:33:22 <harlowja> more libraries maybe 21:33:30 <asalkeld> yar 21:33:44 <asalkeld> (just an idea) 21:33:44 <jd__> so we make nova import ceilometer stuff instead? 21:33:49 <eglynn> other option though would be for nova to export a stable public API for ceilo to use 21:34:08 <asalkeld> jd__, yes but minimal stats_send() api 21:34:16 <dhellmann> eglynn: I like that better. How practical is it? 21:34:27 <asalkeld> not really 21:34:29 <timjr> if it exposes an API, wouldn't you have to poll? 21:34:40 <asalkeld> we do anyway 21:34:40 <eglynn> timjr: yep, as now 21:34:57 <asalkeld> problem is nova is only one project 21:34:58 <jd__> poll a stable API exported via RPC providing CPU time, IO, etc for all virt supported by nova 21:35:15 <asalkeld> then to do the same for all projects? 21:35:16 <timjr> that sounds reasonable to me 21:35:21 <jd__> that's something looking doable and acceptable for nova 21:35:38 <nijaba> Ok, it seems that we have a good discussion topic here. Should we action someone to think up a proposal to be debated next week? 21:35:40 <harlowja> hmmm, ya, so polling is one way, the monitoring stuff seems like it would be the push part though 21:35:55 <jd__> monitoring stuff? 21:35:59 <nijaba> any volunteer? 21:36:10 <timjr> harlowja: I think it's fine to have a queryable API for system stats like cpu time and so on 21:36:30 <eglynn> nijaba: I can work up a proposal for discussion 21:36:40 <asalkeld> I can help 21:36:46 <jd__> I can comment :p 21:36:47 <eglynn> asalkeld cool 21:36:55 <harlowja> but should nova be doing that, or should it just be broadcasting and letting some other system provide the query ontop of that raw data 21:36:56 <jeffreyb1> timjr: not really so nice polling large clusters 21:37:08 <nijaba> #action eglynn to writup a nova integration proposal to be discussed next week 21:37:11 <timjr> jeffreyb1: we would likely not use it for production monitoring 21:37:17 <timjr> jeffreyb1: but there's no harm having it 21:37:35 <jeffreyb1> timjr: famous last words 21:37:41 <asalkeld> problem is it uses rpc 21:37:42 <timjr> jeffreyb1: could be convenient: hit a little status URL to find out what a node thinks it's doing, instead of going off to your monitoring dashboard 21:37:49 <harlowja> timjr: harm being code confusion 21:38:03 <jeffreyb1> timjr: yup, def convenient but not a good way to go long term IMO 21:38:08 <nijaba> Ok, so could you all please take a few moment today or tomorrow to help me fill the roadmap with the valid links? That would help a lot 21:38:28 <nijaba> and t shirt sizes 21:38:36 <timjr> well, you've got to gather all the stats anyway, putting up the polling API is mostly about keeping a local buffer of stat values 21:38:46 <harlowja> XXXXXXX-small 21:38:51 <jd__> nijaba: how you want to proceed? 21:38:53 <harlowja> timjr: agreed 21:38:56 <jeffreyb1> timjr: those stats are good for r/t monitoring but the polling will get out of hand 21:39:17 <timjr> jeffreyb1: again, I would not use polling for actual monitoring 21:39:19 <harlowja> timjr: simplicity though, start simple no? 21:39:38 <nijaba> I'd suggest each one have a pass at it for the action they care about in the next 24h 21:39:39 <eglynn> jeffreyb1: by out of hand, too frequent? 21:39:40 <timjr> harlowja: I don't plan to implement it at present, but if ceilometer wants it, I don't see any conflict with our needs 21:39:41 <jeffreyb1> timjr: so a different mechanism for monitoring of the same stats? 21:39:41 <harlowja> don't do local buffering, have simple broadcasting, get as far as u can with that, then add in local buffering, polling 21:39:54 <jd__> nijaba: ack 21:39:58 <dhellmann> nijaba: ack 21:40:01 <jeffreyb1> eglynn: thinking of polling large clusters, 1000s of machines, kind of a pain 21:40:06 <timjr> jeffreyb1: yeah. hadoop does that, for example. 21:40:13 <jd__> shall we move on? 21:40:30 <asalkeld> yes 21:40:30 <nijaba> sorry to be a pain, but could we please keep on the agenda until the open discussion? 21:40:35 <jeffreyb1> eglynn: rather see fire and forget, let the collector deal with it 21:40:45 <jeffreyb1> nijaba: sure 21:41:03 <nijaba> ok, I think we are ready to move to the next topic 21:41:04 <eglynn> jeffreyb1: re. scale, a local agent would just be polling the instances local to each compute node 21:41:25 <eglynn> nijaba: k 21:41:32 <nijaba> #topic Review survey prepared by nijaba 21:41:50 <nijaba> if you had the chance to review it, any comments about it? 21:42:07 <nijaba> do you think it is ready to be shared widely? 21:42:17 <nijaba> meaning the opnestack ml 21:42:45 <eglynn> nijaba: do you have a link handy? 21:43:06 <jtran> nijaba: i tried submitting my survey and it says "requires input" ... 21:43:08 <jd__> reviewed 21:43:10 <nijaba> #link http://www.surveymonkey.com/s/SY55BHR 21:43:24 <jtran> even tho i made sure all fields had an order #. 21:43:46 <jtran> 'this question requires an answer' 21:43:51 <nijaba> jtran: really? I did not have this issue... :( 21:44:01 <jtran> i reproduced it right now 21:44:22 <jtran> survey questions numbered 1-16. then i even put something in question #2. click submit and that's what i get. using chrome on osx 21:44:29 <jtran> 1-14 i meant 21:45:34 <nijaba> jtran: yep, I just had the same pb. Did not use to have it. I'll disable the check for now, but will need to figure out what is going on 21:46:35 <nijaba> ok, I removed the restriction 21:46:43 <asalkeld> sorry guys, I need to take kids to school be back in ~15min 21:47:08 <nijaba> asalkeld: we'll be around :) 21:47:50 <dhellmann> what's next? 21:47:58 <eglynn> one general point on the survey, how are we gonna set expectations in terms of being bound by the result? 21:48:01 <nijaba> so anyone against us sharing the survey widely? 21:48:06 <eglynn> (e.g. for guidance only?) 21:48:15 <nijaba> eglynn: just a poll, not commitment 21:48:26 <eglynn> nijaba: sounds fair 21:48:29 <nijaba> it's really to make sure we are not too far off our potential users 21:49:08 <nijaba> dhellmann: since you suggested it, what's your pov? 21:49:44 <dhellmann> we should stress those expectations in the email we send to the list 21:49:52 <dhellmann> in the invitation, I mean 21:49:59 <nijaba> dhellmann: +1 21:50:08 <eglynn> cool 21:50:11 <dhellmann> I'm not sure how to ask for input without asking for input. ;-) 21:50:53 <nijaba> eglynn: asalkeld: do you mind if I remove the qpid and zeromq items from the list. It seems the issues comes from having more than 14 items in the list 21:51:15 <eglynn> nijaba: fair enough 21:51:18 <nijaba> and eglynn I think qpid will be a req for rhat in any case, right? 21:51:29 <dhellmann> nijaba: let's keep those and remove some of the internal architectural stuff 21:51:32 <eglynn> (I think Rh has sufficient interest in qpid to test anyway) 21:51:33 <dhellmann> like removing nova imports 21:51:47 <nijaba> dhellmann: that would work too 21:51:48 * dhellmann can't see the list any more because he submitted answers to the survey 21:52:22 <dhellmann> "remove db access" looks like another "features" users won't care about and that we're going to do anyway 21:52:40 <nijaba> dhellmann: I'll remove the nova import and the sqlalchemy and it should work. thanks 21:52:51 <dhellmann> ok 21:54:36 <nijaba> ok, fixed now 21:55:09 <nijaba> so, I'll action myself to send the email tomorrow, unless someone is against that 21:55:16 <dhellmann> +1 21:55:35 <nijaba> #action nijaba to send an invite to fill t 21:55:40 <zykes-> what's the whole survey stuff ? 21:55:41 <nijaba> #action nijaba to send an invite to fill the survey 21:56:06 <nijaba> #topic Open Discussion 21:56:25 <nijaba> zykes-: not sure I understand your question 21:56:32 <eglynn> did folks get a chance to review sandywalsh's unification write-up? 21:56:35 <eglynn> #link http://wiki.openstack.org/UnifiedInstrumentationMetering 21:56:44 <jtran> yes 21:56:46 <dhellmann> zykes-: we are soliciting input from potential users about what features they consider important 21:56:47 <jtran> good stuff 21:56:57 <dhellmann> unfortunately, no 21:57:14 <jeffreyb1> yes, i read it 21:57:38 <harlowja> it seems complicated though 21:57:53 <harlowja> but i think the right direction, i think we are working on unifying the bottom layer 21:57:58 <harlowja> timjr: mainly 21:58:08 <eglynn> yep, agreed 21:58:16 <jeffreyb1> really struggling with the reliance on rabbit 21:58:17 <eglynn> I wasn't sure tho' about the "Remove the Compute service that Ceilometer uses ..." suggestion 21:58:19 <eglynn> kinda ties in with the earlier discussion on moving stuff into nova 21:58:33 <harlowja> tach is one way, but i don't think the only way 21:58:48 <harlowja> http://wiki.openstack.org/InstrumentationMetricsMonitoring is the other one that is more 'low level' 21:58:49 <timjr> well, I don't mind if people want to use amqp to send around messages, but I would consider that a configuration option 21:58:57 <timjr> the notification system already does 21:58:57 <asalkeld> back 21:59:08 <harlowja> timjr: sure 21:59:57 <eglynn> jeffreyb1: is the reliance on rabbit still a huge problem for you if sufficiently partitioned from the prod message bus? 22:00:26 <eglynn> (e.g. a separate rabbit broker/cluster) 22:00:37 <timjr> eglynn: anything other than a simple point-to-point communication has many of its own failure modes that you would want to monitor 22:00:39 <dhellmann> I thought we already agreed we would support multiple publishing methods. 22:00:42 <jeffreyb1> eglynn: as tim alluded to, so long as it is a config option and pluggable to use something else then it is not a prob 22:01:02 <eglynn> dhellmann: yep 22:01:02 * nijaba let us run overtime as I do not think th 22:01:05 <eglynn> jeffreyb1: cool 22:01:06 <jeffreyb1> btw, vish closed the BP and marked it as 'obsolete' 22:01:13 * nijaba let us run overtime as I do not think there is another meeting after us 22:01:27 <jeffreyb1> he suggested we put it in openstack-common or "external" 22:01:41 <timjr> yeah, i think that means somehow it wasn't clear enough :) 22:01:42 <nijaba> dhellmann: yep, that was acted for me too 22:02:00 <timjr> the functions you call can be in a separate library, but the calls will have to land in nova and other components... 22:02:11 <asalkeld> sure 22:02:50 <asalkeld> seems not everyone wants a single library to emit the stats 22:03:10 <asalkeld> might need to have tracing and metering/monitoring 22:03:13 <timjr> um... well, I guess there's no accounting for taste 22:03:32 <asalkeld> as seperate entities 22:03:39 <asalkeld> I am not fussed 22:03:43 <dhellmann> fwiw, I've been looking at https://github.com/BrightcoveOS/Diamond/ this week and it has some of the stuff we've discussed doing with different polling rates and publishing methods already 22:04:09 <timjr> asalkeld: I would hope that the API is good enough that switching from two libraries to one is a simple matter of refactoring 22:04:11 <asalkeld> cool looking 22:04:30 <dhellmann> we're going to be using it for monitoring here at DH, so I wrote a ceph plugin for it. pretty easy. could use some polish, but maybe we can steal ideas or even collaborate 22:04:40 <timjr> dhellmann: that's an interesting link 22:04:42 <eglynn> dhellmann: interesting ... 22:05:12 <dhellmann> I'm not super happy with the "scan a directory for plugins" approach they took, and the packaging is rough, but all the pieces seem to be there. 22:05:39 <dhellmann> they're focusing on monitoring, of course 22:05:55 <dhellmann> I'm not sure if you can specify that the same data goes to different sources at different rates. 22:06:03 <dhellmann> sorry, different destinations not sources 22:06:08 <asalkeld> yip 22:06:09 * nijaba_ was temporarily disconnected :( 22:06:18 <eglynn> that would be fairly crucial 22:06:25 <dhellmann> eglynn: yeah, definitely 22:06:46 <dhellmann> they've been very welcoming of patches this week, even without me contacting them directly, so that might be worth a go 22:06:48 <asalkeld> class Metric(object): 22:06:48 <asalkeld> def __init__(self, path, value, timestamp=None, precision=0): 22:07:02 <asalkeld> don't see how we can add more info 22:07:13 <asalkeld> user/resource info 22:07:24 <dhellmann> yeah, it's definitely not good enough for billing 22:07:48 <dhellmann> although the publisher pulls data out of the Metric, so if we change that class we could add data that is only used by some publishers 22:08:01 <asalkeld> the just need **kwargs 22:08:08 <nijaba_> dhellmann: and the ncome the transport issue... 22:08:10 <dhellmann> I'm not necessarily suggesting we use their daemon instead of ours, but we might get some ideas about, for example, how to configure things 22:08:33 <eglynn> defo worth a sniff around 22:08:35 <dhellmann> nijaba_: some of that didn't come through, I think, I'm not sure what you mean 22:08:40 <timjr> so would a set of arbitrary ket/value pairs be sufficient for billing purposes? 22:08:44 <timjr> key/value, even 22:08:47 <dhellmann> timjr: no 22:08:54 <timjr> dhellmann: what else do you need? 22:09:06 <dhellmann> we need timestamps, for one 22:09:11 <dhellmann> messages need to be signed for auditing purposes 22:09:11 <timjr> oh, sure 22:09:18 <asalkeld> , timestamp=None 22:09:21 <timjr> that's an interesting one 22:09:25 <asalkeld> they have that 22:09:26 <nijaba> and counters for auditability 22:09:37 <dhellmann> we need the metadata so consumers can compute rates based on properties of the instance 22:09:39 <asalkeld> well we write the handler 22:09:43 <timjr> nijaba: you mean unique message IDs? 22:09:46 <dhellmann> and we need to know the owner 22:09:55 <nijaba> timjr: no, incremental counters 22:10:14 <nijaba> timjr: so that you can dtect missing or inserted messages 22:10:20 <timjr> I see 22:10:29 <jeffreyb1> so that is like a stateful metric? 22:10:39 <dhellmann> nijaba: did counters make it onto the priority list for grizzly? :-) 22:10:44 <asalkeld> sequenced metric 22:11:09 <jeffreyb1> hmm 22:11:14 <nijaba> we don't really care a 22:11:23 <nijaba> about the order 22:11:33 <nijaba> more about tempering 22:11:41 <timjr> nod 22:11:44 <timjr> that makes sense 22:12:22 <asalkeld> well worth a look 22:12:44 <nijaba> should we action something here? 22:12:59 <timjr> I think if tampering were to become an issue, you've got some fundamental access control problems on your openstack cluster 22:13:06 <dhellmann> nijaba: I'm not sure what that action would be. 22:13:07 <timjr> ... but I can see being paranoid where billing is concerned 22:13:48 <nijaba> timjr: yep, that's something people tend to become paranoid about 22:13:52 * dhellmann needs to leave soon 22:13:57 * nijaba too 22:14:08 <asalkeld> "investigate diamond for use to generate stats" 22:14:16 <nijaba> should we end the meeting for now? 22:14:20 <asalkeld> yip 22:14:21 <zykes-> btw 22:14:23 <eglynn> k 22:14:29 <dhellmann> ok 22:14:37 <nijaba> asalkeld: care to take that action? 22:14:49 <asalkeld> sure 22:14:51 <zykes-> for chargeback >> bufunfa uses ceilometer 22:15:01 <zykes-> for people that care 22:15:07 <nijaba> #action asalkeld investigate diamond for use to generate stats 22:15:32 <nijaba> #endmeeting