16:02:40 <jd___> #startmeeting
16:02:40 <jd___> #meetingname ceilometer
16:02:40 <jd___> #link https://lists.launchpad.net/openstack/msg12501.html
16:02:40 <openstack> Meeting started Thu May 31 16:02:40 2012 UTC.  The chair is jd___. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:40 <jd___> 
16:02:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:42 <openstack> The meeting name has been set to 'ceilometer'
16:03:00 <jd___> #chair nijaba dachary
16:03:01 <openstack> Current chairs: dachary jd___ nijaba
16:03:09 <jd___> #topic actions from previous meetings
16:03:21 <jd___> #info jd___ and dhellmann opened a bunch of bugs on Launchpad to track things https://bugs.launchpad.net/ceilometer
16:03:49 <jd___> I don't think they were any other actions planned
16:04:04 <jd___> but if someone wants to add something, please say so
16:04:06 <nijaba> Thanks for your great work on the testing framework, dhellmann & jd___
16:04:17 <jd___> thanks nijaba :)
16:04:26 <dhellmann> that caught me a little off guard, but I'm glad we have that going now
16:04:58 <jd___> dhellmann: that's part of the fun ;)
16:05:01 <nijaba> I am very happy that we are laying the ground nicely for a stable and reliable project
16:05:16 <dhellmann> jd___, I told my manager "If it was easy, anyone could do it."
16:05:40 <jd___> :-)
16:05:52 <dhellmann> I have a demo later this afternoon showing ceilometer as part of DreamHost's alpha 1 milestone. I appreciate the help everyone has provided in making it possible to do that. :-)
16:06:10 <nijaba> dhellmann: amazing!
16:06:19 <jd___> nice
16:06:35 <dhellmann> it's a small, internal demo, as part of our sprint process, but a HUGE milestone for me (and us)
16:07:21 <jd___> you'll have to tell the result ;)
16:07:30 <dhellmann> I'll definitely let you know how it goes
16:07:44 <dhellmann> #action dhellmann to report on outcome of demo at DreamHost
16:07:49 <jd___> :-)
16:07:58 <jd___> #action dhellmann to report on outcome of demo at DreamHost
16:08:10 <jd___> (not sure it works otherwise)
16:08:21 <jd___> ok so let's move on
16:08:24 <jd___> #topic API message format
16:08:40 <dhellmann> I have a gist prepared with the existing message format: https://gist.github.com/2844410
16:08:55 <dhellmann> this is based on the work done so far, and is how the agent sends messages to the collector
16:09:17 <dhellmann> it's there for reference, but there are definitely things I want to change about it before we call it "done"
16:09:44 <nijaba> dhellmann: based on the ml discussion, I think we should add something to cast the meter (delta, gauge,...)
16:09:45 <dhellmann> the first being the RPC wrapper, since the metering messages feel a lot more like notifications than RPC calls
16:09:53 <dhellmann> yes, good point
16:10:07 <dhellmann> I'll open a ticket for that
16:10:24 <flacoste> nijaba, dhellmann: isn't it part of the event_type field?
16:10:25 <flacoste> 'event_type': '%s.%s' % (cfg.CONF.metering_topic,
16:10:27 <flacoste> counter.type)
16:10:34 <flacoste> counter.type?
16:10:50 <dhellmann> heh, there's already a bug open for that
16:10:59 <nijaba> dhellmann: should we also have something that identify the emiting host, or is this part of the envelope?
16:11:02 <dhellmann> the existing counter.type value is the id or name from the table in the wiki
16:11:12 <dhellmann> bug #1006425 talks about changing that
16:11:14 <uvirtbot> Launchpad bug 1006425 in ceilometer "add counter type field" [Undecided,New] https://launchpad.net/bugs/1006425
16:11:43 <dhellmann> hey, nice bot action!
16:12:10 <dhellmann> nijaba, yes, I think the emitting host is in there somewhere as part of the event metadata, but we should add an explicit field
16:12:55 <dhellmann> see bug #1006989
16:12:56 <uvirtbot> Launchpad bug 1006989 in ceilometer "add emitting host field to meter messages" [Undecided,New] https://launchpad.net/bugs/1006989
16:12:58 <nijaba> dhellmann: nice.  we can also add something on the collector that does anti spoofing then
16:13:49 <jd___> we can rely on signature for that if we have a key for each host
16:13:51 <dhellmann> see bug #1006990
16:13:53 <uvirtbot> Launchpad bug 1006990 in ceilometer "the collector should verify the signature of incoming metering data" [Undecided,New] https://launchpad.net/bugs/1006990
16:14:21 <dhellmann> jd___ the way the signature works now is a single shared secret value. do you mean to have a separate secret for each host?
16:14:45 <jd___> dhellmann: that would be the best way to do anti spoofing on a per-host basis if we want that
16:14:46 <nijaba> dhellmann: I will add a comment on the bug to check host field with envelop as well, as private keys can be eventually stolen
16:14:54 <jd___> I don't think I want that but maybe nijaba wants
16:15:05 <dhellmann> ok, I can see that
16:15:28 <nijaba> #action nijaba to comment on bug 1006990 for anti spoofing of messages
16:15:29 <uvirtbot> Launchpad bug 1006990 in ceilometer "the collector should verify the signature of incoming metering data" [Undecided,New] https://launchpad.net/bugs/1006990
16:15:43 <dhellmann> we will need to figure out how to share those configuration values with the collector and the agent, but it's possible
16:16:23 <jd___> maybe for now a unique key for everyone is enough
16:16:51 <dhellmann> I think that satisfies my needs, but I'm sure we can implement it in a way that hosts can have their own keys, too
16:16:59 <jd___> sure
16:17:10 <nijaba> I would vote for a key per agent
16:17:24 <nijaba> to maintain indepence of agents
16:17:32 <zykes-> ceilometer ?
16:17:34 <dhellmann> nijaba, do you want to open a ticket or blueprint to work out how to implement it?
16:17:47 <nijaba> dhellmann: I take the action
16:17:55 <jd___> zykes-: yes
16:18:10 <nijaba> #action nijaba to define a configuration mechanism on a per agent basis
16:19:55 <jd___> dhellmann: so event_type will be removed IIUC ?
16:19:58 <zykes-> will there be a basic folsom integration?
16:20:29 <nijaba> zykes-: we are targeting folsom for 1st delivery
16:20:46 <dhellmann> jd___ we have some redundant information now, with event_type appearing as a top-level item and as part of the metadata added by the instance counter. so one copy can go away
16:21:08 <jd___> dhellmann: that's what I though, ok
16:21:19 <jd___> if it's only needed by the rpc mechanism, it'll go away
16:21:55 <dhellmann> well, it's not needed by the rpc mechanism. I added it because tools/notificationclient.py was expecting to find it :-)
16:22:07 <jd___> oh ok
16:22:08 <dhellmann> but it can probably still go away
16:22:13 <jd___> yeah :)
16:22:37 <dhellmann> the current format is a bit of a mixup of notification and rpc
16:22:49 <dhellmann> I expected to clean it up when we get to the point of actually storing the data
16:23:00 <jd___> fair enough
16:23:50 <dhellmann> see bug #1006995
16:23:51 <uvirtbot> Launchpad bug 1006995 in ceilometer "clean up redundant metering message fields" [Undecided,New] https://launchpad.net/bugs/1006995
16:24:18 <nijaba> are we still in agreement that these messages will go through a separate queue from the nova queue, while still using the openstack common queue functions?
16:25:01 <jd___> I think so
16:25:06 <dhellmann> I think so. Each message is going to 2 queues right now: "metering" and "metering.type" where type is "instance", "disk", "floatingip", etc.
16:25:18 <nijaba> nice
16:26:15 <dhellmann> I want to keep the names, but use something closer to the nofiy() function instead of cast() to send the messages
16:26:38 <dhellmann> that will mean creating a new type of consumer in the rpc library, though :-/
16:27:05 <nijaba> would that be a problem?
16:27:19 <dhellmann> no, I just need to do the work.
16:27:44 <dhellmann> they are pretty close to having that code ready to move out of nova into openstack-common, so it might make sense to wait a iittle while
16:27:55 <nijaba> dhellmann: let's hope that flacoste will soon have a team to supplement you and jd___ here
16:28:01 <dhellmann> unless they're not as close as I think
16:28:19 <flacoste> nijaba: we are still a few weeks away from that unfortunately :-(
16:28:21 <dhellmann> it would be good to have a few more hands :-)
16:28:30 <jd___> anyway we already need the consumer type dhellmann, if it can be compatible with nova notifications
16:28:34 <dhellmann> ah, well, we'll still have plenty of work for them to do then
16:28:50 <nijaba> flacoste: should we send CVs to you?
16:28:52 <dhellmann> exactly, jd___
16:29:04 <flacoste> nijaba: please do actually!
16:29:32 <nijaba> I will!
16:31:51 <dhellmann> is there any other feedback on the message format or contents?
16:32:15 <jd___> not from my point
16:32:46 <nijaba> nor here
16:33:02 <flacoste> neither here
16:33:50 <dhellmann> good. I'm sure we will find other things to change as we go along, but this should work for now.
16:34:10 <dhellmann> next week is the "storage backend" discussion, right?
16:35:14 <nijaba> dhellmann: yes
16:35:25 <jd___> yep
16:35:40 <nijaba> should we mark your proposal as agreed, pending the discussed changes?
16:35:42 <dhellmann> I am looking forward to reading the proposals for that on the mailing list. :-)
16:36:13 <dhellmann> if everyone is comfortable with it, I am
16:36:28 <nijaba> dhellmann: same here.  Sound like a mongoDB vs Riak vs ... flamewar to start
16:36:52 <nijaba> jd___: vote maybe?
16:36:55 <nijaba> just to check?
16:36:56 <flacoste> what, nobody is considering PostgreSQL? :-)
16:37:05 <dhellmann> nijaba, I think we'll probably have another plugin point for storage backends :-)
16:37:30 <nijaba> dhellmann: true, but not SQLAlchemy!
16:38:16 <dhellmann> I will leave that up to the implementer. :-)
16:38:38 <nijaba> hehe
16:38:50 <jd___> if you want :)
16:40:38 <nijaba> so, should we vote on the API message format or just mark it as agreed?
16:41:25 <dhellmann> let's do the vote and make it official
16:41:50 <nijaba> jd___: go ahead and open the vote then :)
16:42:35 <jd___> anything else?
16:43:21 <dhellmann> not from me
16:43:41 <nijaba> nor here (apart from the vote)
16:45:05 <nijaba> ok, I'll open the vote then
16:45:29 <jd___> go ahead
16:45:58 <nijaba> #vote agreement on the proposal from dhellmann https://gist.github.com/2844410 for API messaging format, pending the 2 modifications discussed during the meeting
16:46:06 <nijaba> +1
16:46:07 <flacoste> +1
16:46:12 <dhellmann> +1
16:46:18 <dachary> +1
16:46:41 <jd___> +1
16:46:58 <nijaba> ok, I guess we can mark this as agreed then
16:47:10 <nijaba> #agreed on the proposal from dhellmann https://gist.github.com/2844410 for API messaging format, pending the 2 modifications discussed during the meeting
16:47:43 <dhellmann> good
16:48:43 <dhellmann> if we're done, it's time for some lunch here
16:49:05 <nijaba> #topic other topics
16:49:12 <nijaba> anyone?
16:49:15 <flacoste> dhellmann: +1
16:49:49 <nijaba> ok, I guess some bellys need to get filled :)
16:50:02 <nijaba> bellies maybe?
16:50:14 <nijaba> anyway... thanks everyone!
16:50:23 <dhellmann> thanks!
16:50:27 <flacoste> thanks!
16:50:29 <dachary> nijaba: thanks !
16:50:36 <nijaba> #endmeeting