16:00:33 <nijaba> #startmeeting ceilometer
16:00:34 <openstack> Meeting started Thu Aug 23 16:00:33 2012 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:36 <openstack> The meeting name has been set to 'ceilometer'
16:00:48 <dhellmann> hi, everyone
16:00:49 <nijaba> #meetingtopic Ceilometer
16:00:49 <nijaba> #chair nijaba
16:00:49 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
16:00:51 <openstack> Current chairs: nijaba
16:01:06 * heckj lurks
16:01:11 <nijaba> Hello everyone!
16:01:17 <gmb> \o
16:01:20 <nijaba> who is here for the meeting?
16:01:22 <nijaba> o/
16:01:51 <dhellmann> o/
16:01:55 <nijaba> #topic actions from previous meeting
16:02:13 <nijaba> #topic jaypipes to create ceilometer cookbook
16:02:20 <nijaba> jaypipes is on vacation in europe
16:02:32 <nijaba> so I guess we'll have to wait a bit more....
16:02:41 <nijaba> #action jaypipes to create ceilometer cookbook
16:02:43 <dhellmann> that sounds like something that will take more than a week. should we change the action to creating a ticket or blueprint?
16:02:58 <nijaba> dhellmann: we could
16:03:08 <dhellmann> let's wait and see what he says next week
16:03:26 <nijaba> I think he should be back then
16:03:31 <nijaba> so let's do that
16:03:44 <nijaba> #topic nijaba to write description of component responsibility
16:04:11 <nijaba> I spent a day and a half at the hospital this week...  so that delayed me on this.  barely had time to start on it :(
16:04:25 <_surya_> o/
16:04:29 <nijaba> I think dhellmann and I finalized the schema though
16:04:36 <dhellmann> ouch, I hope you're doing ok
16:04:47 <dhellmann> yes, the latest version of that diagram looked good
16:05:05 <dhellmann> we just need to export it or otherwise link to it from the main documentation (I'm not sure which is best with google docs)
16:05:09 <nijaba> dhellmann: yes, it was all about making sure I was, which seems confirmed now...
16:05:16 <dhellmann> good
16:05:28 <nijaba> dhellmann: it is already exported.  I will link it in the doc
16:05:44 <nijaba> #action nijaba to link schema in the doc
16:06:24 <nijaba> #link https://docs.google.com/drawings/pub?id=1_cIFir6HS6jSkPw7chrmyu8DGE2ZgXk79Kbj8nw-Hqo&w=960&h=720
16:06:56 <nijaba> #topic dhellmann and nijaba to work on sessions for summit via email
16:07:07 <dhellmann> I've been traveling this week, so completely pushed that off
16:07:08 <nijaba> I think we did not move much on this
16:07:20 <nijaba> should we re action for next week?
16:07:26 <dhellmann> yes, let's do that
16:07:32 <nijaba> #action dhellmann and nijaba to work on sessions for summit via email
16:07:42 <dhellmann> I'll make some notes on the plane tomorrow and email you next week
16:07:48 <nijaba> great
16:08:01 <nijaba> #topic dhellmann to ask jtrans about interest in reviewer status
16:08:11 <nijaba> so jtran confirmed
16:08:20 <nijaba> and he is now a core reviewer
16:08:52 <nijaba> #topic nijaba to give core reviewer rights to gmb
16:08:53 <dhellmann> now we need to go back to making patches to be reviewed :-)
16:09:01 <nijaba> that was done as well!
16:09:15 <gmb> Yep. haven't had time to actually review anything yet as I'm in the thick of the recruitment process.
16:09:39 <dhellmann> right now all of the tests are failing because of a change in the nova test framework
16:09:54 <dhellmann> I'm working on a patch to fix that by mocking out the database, but haven't quite got it working either
16:09:57 * nijaba notes that anyone who want's to join canonical should consider applying to the roles ;)
16:10:11 <dhellmann> I hope to spend more time on it today, but definitely on Monday
16:10:38 <nijaba> cool.  We now have lots of potential reviewers :)
16:10:42 <dhellmann> gmb, I may know some people who would be interested. could you send a me job description and contact info?
16:11:04 <gmb> dhellmann: Sure, I'll send you an email this evening.
16:11:13 <dhellmann> good, thanks!
16:11:33 <nijaba> #topic Open Discussion
16:12:30 <nijaba> so, their was a discussion on the use of duration on the ML
16:12:48 <nijaba> and the conclusion was that it was finall not a needed field
16:13:08 <dhellmann> yes, it looks like we're going to use the timestamps on the events instead
16:13:36 <nijaba> well, what about storage such as swift?
16:14:19 <dhellmann> what we did with instance flavors was create a new meter with a name like "instance:<flavor-id>"
16:14:19 <nijaba> this is going to collect amounts of data, which are not based on events, but on periodical checks
16:15:17 <dhellmann> that's true, but the code doing the polling does not know how long it has been since it has been run
16:15:31 <dhellmann> at least there are cases where it cannot know -- on daemon startup, for instance
16:15:55 <dhellmann> so for polling meters we will consume the results and figure out the times ourselves after the fact
16:16:04 <nijaba> I see...  so the duration will always have to be a calculation based on the delay betweeen to ts?
16:16:15 <nijaba> s/to/two/
16:16:26 <dhellmann> or possibly use some custom meter names like "volume:<size>" but that feels awkward because sizes may vary so much
16:16:30 <dhellmann> yes, that's the idea
16:16:56 <dhellmann> and we might find 5GB for 1 hr followed by 10GB for 1 hr followed by 15 GB for 2 days, etc
16:17:04 <nijaba> I am just a bit afraid that this should be cached if we do not want to spend too much time querying
16:17:24 <nijaba> could we have some logic that does the calculation at the time it is stored?
16:17:31 <dhellmann> at DH we are going to run a query daily and then store the results in our internal billing system
16:17:53 <dhellmann> since we already have code to show usage data from there on bills, etc.
16:18:01 <nijaba> k
16:18:05 <dhellmann> so the ceilometer database is being treated like a cache
16:18:09 <dhellmann> that may not work for every system, of course
16:19:45 <dhellmann> the trouble with updating the db on every write is that it is a somewhat expensive calculation, and concurrent writers may step on the data as it is updated
16:20:11 <dhellmann> but I will give it more thought
16:20:25 <nijaba> ah...  I see
16:20:47 <nijaba> well.  I guess we'll have to see that in the optimization phase then
16:21:13 <dhellmann> the update problem wouldn't be as bad with a transactional db, but we decided to go with mongo to speed initial development along
16:21:22 <nijaba> right
16:21:55 <dhellmann> nijaba, we are probably going to need to adjust the API to assume that queries can use the metadata fields for aggregation
16:22:16 <nijaba> seems likely, yes
16:22:21 <dhellmann> I didn't want to assume that would be possible, but I don't see an easy way to do this more efficient without it
16:22:45 <dhellmann> as we get back to our integration work next week, if that looks like it will help, I will put together a first approach for it
16:24:19 <nijaba> any other topic for today?
16:24:49 <dhellmann> angus salkeld has put together a changeset on github that adds "alarms"
16:24:58 <nijaba> I was wondering if we shouldn't repoll our "community" on the time of the meeting
16:25:06 <dhellmann> I haven't caught up with the mailing list this week, did he bring it up there?
16:25:12 <nijaba> nope
16:25:15 <dhellmann> nijaba: I would be interested in moving the meeting earlier a little
16:25:32 <nijaba> earlier in the week or in the day?
16:25:41 <dhellmann> ok, I'll ask angus to send an email
16:25:44 <dhellmann> in the day
16:26:11 <dhellmann> ah, he did send me this link, but he may just not be ready for broader discussion: http://wiki.openstack.org/AddingAlarmsToCeilometer
16:27:11 <dhellmann> it is related to the "monitoring vs. metering" discussion, but I haven't had a chance to read that wiki page fully
16:27:17 <nijaba> well, again, my main issue is that this is more of a monitoring thant metering function
16:27:30 <nijaba> and to do it well, we would need to work with shorter periods
16:27:39 <dhellmann> nijaba: yeah, I'm not sure we're going to have the resolution fo data needed to produce some of those alerts
16:27:46 <dhellmann> we only measure cpu every 10 minutes or so
16:28:08 <nijaba> yes.  but I think that is the same question we got from heat
16:28:16 <dhellmann> right
16:28:35 <nijaba> and we could twitch the agents to server 2 purposes, and feed two separate backends
16:28:59 <nijaba> I think we should add that to the ODS discussion we were planning to have with heat
16:29:04 <dhellmann> we did talk at one point about allowing different periodic rates for different meters
16:29:24 <dhellmann> ok, I think this code was meant to be part of that discussion, so I  may be jumping the gun bringing it up now
16:29:34 <nijaba> yes, but here it would need to have multiple periods for the same meter for different backends
16:30:11 <dhellmann> I'm neutral on the idea, at this point. I don't think I need this sort of monitoring but as long as it doesn't cause trouble with the billing we could include it
16:30:26 <dhellmann> nijaba: true
16:31:14 <dhellmann> maybe the pollsters could be reused and send messages to different queues, as you said earlier
16:31:27 <nijaba> right
16:31:55 <nijaba> anyway, I am going to propose that we store this until the ODS discussion
16:32:16 <nijaba> as I think we should first target to finish a first version in // with folsom release
16:32:42 <dhellmann> +1
16:33:31 <nijaba> so, regarding the meeting time, should we start a thread on the ML?
16:33:41 <dhellmann> yes, that seems appropriate
16:33:58 <nijaba> I may do another doodle, but limiting the vote that counts to contributors
16:34:26 <nijaba> #action nijaba to start a thread on meeting time
16:34:51 <nijaba> any other subjects?
16:35:06 <dhellmann> that's all I had
16:35:12 <nijaba> same here
16:35:29 <nijaba> I guess that's a wrap then!
16:35:40 <nijaba> #endmeeting