16:00:33 #startmeeting ceilometer 16:00:34 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:36 The meeting name has been set to 'ceilometer' 16:00:48 hi, everyone 16:00:49 #meetingtopic Ceilometer 16:00:49 #chair nijaba 16:00:49 #link http://wiki.openstack.org/Meetings/MeteringAgenda 16:00:51 Current chairs: nijaba 16:01:06 * heckj lurks 16:01:11 Hello everyone! 16:01:17 \o 16:01:20 who is here for the meeting? 16:01:22 o/ 16:01:51 o/ 16:01:55 #topic actions from previous meeting 16:02:13 #topic jaypipes to create ceilometer cookbook 16:02:20 jaypipes is on vacation in europe 16:02:32 so I guess we'll have to wait a bit more.... 16:02:41 #action jaypipes to create ceilometer cookbook 16:02:43 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 dhellmann: we could 16:03:08 let's wait and see what he says next week 16:03:26 I think he should be back then 16:03:31 so let's do that 16:03:44 #topic nijaba to write description of component responsibility 16:04:11 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 I think dhellmann and I finalized the schema though 16:04:36 ouch, I hope you're doing ok 16:04:47 yes, the latest version of that diagram looked good 16:05:05 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 dhellmann: yes, it was all about making sure I was, which seems confirmed now... 16:05:16 good 16:05:28 dhellmann: it is already exported. I will link it in the doc 16:05:44 #action nijaba to link schema in the doc 16:06:24 #link https://docs.google.com/drawings/pub?id=1_cIFir6HS6jSkPw7chrmyu8DGE2ZgXk79Kbj8nw-Hqo&w=960&h=720 16:06:56 #topic dhellmann and nijaba to work on sessions for summit via email 16:07:07 I've been traveling this week, so completely pushed that off 16:07:08 I think we did not move much on this 16:07:20 should we re action for next week? 16:07:26 yes, let's do that 16:07:32 #action dhellmann and nijaba to work on sessions for summit via email 16:07:42 I'll make some notes on the plane tomorrow and email you next week 16:07:48 great 16:08:01 #topic dhellmann to ask jtrans about interest in reviewer status 16:08:11 so jtran confirmed 16:08:20 and he is now a core reviewer 16:08:52 #topic nijaba to give core reviewer rights to gmb 16:08:53 now we need to go back to making patches to be reviewed :-) 16:09:01 that was done as well! 16:09:15 Yep. haven't had time to actually review anything yet as I'm in the thick of the recruitment process. 16:09:39 right now all of the tests are failing because of a change in the nova test framework 16:09:54 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 I hope to spend more time on it today, but definitely on Monday 16:10:38 cool. We now have lots of potential reviewers :) 16:10:42 gmb, I may know some people who would be interested. could you send a me job description and contact info? 16:11:04 dhellmann: Sure, I'll send you an email this evening. 16:11:13 good, thanks! 16:11:33 #topic Open Discussion 16:12:30 so, their was a discussion on the use of duration on the ML 16:12:48 and the conclusion was that it was finall not a needed field 16:13:08 yes, it looks like we're going to use the timestamps on the events instead 16:13:36 well, what about storage such as swift? 16:14:19 what we did with instance flavors was create a new meter with a name like "instance:" 16:14:19 this is going to collect amounts of data, which are not based on events, but on periodical checks 16:15:17 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 at least there are cases where it cannot know -- on daemon startup, for instance 16:15:55 so for polling meters we will consume the results and figure out the times ourselves after the fact 16:16:04 I see... so the duration will always have to be a calculation based on the delay betweeen to ts? 16:16:15 s/to/two/ 16:16:26 or possibly use some custom meter names like "volume:" but that feels awkward because sizes may vary so much 16:16:30 yes, that's the idea 16:16:56 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 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 could we have some logic that does the calculation at the time it is stored? 16:17:31 at DH we are going to run a query daily and then store the results in our internal billing system 16:17:53 since we already have code to show usage data from there on bills, etc. 16:18:01 k 16:18:05 so the ceilometer database is being treated like a cache 16:18:09 that may not work for every system, of course 16:19:45 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 but I will give it more thought 16:20:25 ah... I see 16:20:47 well. I guess we'll have to see that in the optimization phase then 16:21:13 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 right 16:21:55 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 seems likely, yes 16:22:21 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 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 any other topic for today? 16:24:49 angus salkeld has put together a changeset on github that adds "alarms" 16:24:58 I was wondering if we shouldn't repoll our "community" on the time of the meeting 16:25:06 I haven't caught up with the mailing list this week, did he bring it up there? 16:25:12 nope 16:25:15 nijaba: I would be interested in moving the meeting earlier a little 16:25:32 earlier in the week or in the day? 16:25:41 ok, I'll ask angus to send an email 16:25:44 in the day 16:26:11 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 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 well, again, my main issue is that this is more of a monitoring thant metering function 16:27:30 and to do it well, we would need to work with shorter periods 16:27:39 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 we only measure cpu every 10 minutes or so 16:28:08 yes. but I think that is the same question we got from heat 16:28:16 right 16:28:35 and we could twitch the agents to server 2 purposes, and feed two separate backends 16:28:59 I think we should add that to the ODS discussion we were planning to have with heat 16:29:04 we did talk at one point about allowing different periodic rates for different meters 16:29:24 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 yes, but here it would need to have multiple periods for the same meter for different backends 16:30:11 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 nijaba: true 16:31:14 maybe the pollsters could be reused and send messages to different queues, as you said earlier 16:31:27 right 16:31:55 anyway, I am going to propose that we store this until the ODS discussion 16:32:16 as I think we should first target to finish a first version in // with folsom release 16:32:42 +1 16:33:31 so, regarding the meeting time, should we start a thread on the ML? 16:33:41 yes, that seems appropriate 16:33:58 I may do another doodle, but limiting the vote that counts to contributors 16:34:26 #action nijaba to start a thread on meeting time 16:34:51 any other subjects? 16:35:06 that's all I had 16:35:12 same here 16:35:29 I guess that's a wrap then! 16:35:40 #endmeeting