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