15:00:18 #startmeeting ceilometer 15:00:19 Meeting started Thu Apr 4 15:00:18 2013 UTC. The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:22 The meeting name has been set to 'ceilometer' 15:00:30 #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda 15:00:44 o/ 15:00:46 o/ 15:00:47 o/ 15:00:51 o/ 15:00:56 o/ 15:01:06 o/ 15:01:21 hi everybody 15:01:35 o/ 15:01:43 #topic asalkeld to release python-ceilometerclient 1.0.0 and document the release process 15:01:53 I imagine asalkeld's sleeping tight 15:02:05 but I didn't see any release unfortunately 15:02:29 #action asalkeld to release python-ceilometerclient 1.0.0 and document the release process 15:02:41 #topic jd__ reassign nova-cell/ceilometer session to nova 15:02:51 done, it has been merged with http://summit.openstack.org/cfp/details/147 15:03:08 oh wait 15:03:13 #topic BREAKING NEWS 15:03:26 we released Grizzly https://launchpad.net/ceilometer/grizzly/2013.1 15:03:39 congrats everyone ) 15:03:46 nice! 15:03:52 wonderful 15:03:56 #info we released Grizzly https://launchpad.net/ceilometer/grizzly/2013.1 15:03:57 awesome. 15:04:02 thanks ttx for the release job :) 15:04:50 one question, what does the 1 in 2013.1 mean? 15:05:05 first of the year 15:05:23 ok, I used to though it was Jan. 15:05:25 (at least that's my understanding) 15:05:38 llu-laptop: no, Havana will be 2013.2 AFAIK :) 15:05:43 right 15:06:07 #topic Preparing for summit 15:06:20 #info Doc team would like for us to review https://wiki.openstack.org/wiki/Blueprint-restructure-documentation and think about how we fit in 15:06:48 ideas on that? 15:06:58 I looked over that earlier this week. I don't see any issue with us fitting in just like the other projects. 15:07:09 The reorg seems to make sense to me, too. 15:07:39 Is this reorg decided? 15:07:54 no, it's under discussion by the doc team 15:08:08 does't shock me either 15:08:49 right, no surprises or issues 15:08:58 dhellmann: should we send a feedback to someone about this? 15:09:05 why moving "reference manual" out of "user manual"? 15:09:25 no, annegentle just asked us to be prepared to talk about our doc needs in terms of that framework 15:09:25 Is it more logical to put the "options" explanation just in user manual? 15:09:38 she is interested in feedback if we have it, but we don't have to reply formally 15:10:15 llu-laptop: you probably want to ask the doc team, not us :-) 15:10:22 dhellmann: ok, cool 15:10:32 dhellmann: there may be a session we need to attend? 15:10:52 jd__: we do have a session in the doc track, let me find the link 15:10:58 ok 15:11:06 o/ sorry for late arrival 15:11:12 I'm having a hard time tracking session since they're not scheduled yet :) 15:11:14 #link restructure documentation session http://summit.openstack.org/cfp/details/129 15:11:24 ack 15:11:28 #link documentation for newly integrated projects http://summit.openstack.org/cfp/details/104 15:11:35 the latter is the one we requested 15:11:48 so we should be there indeed :-> 15:11:57 yes :-) 15:12:29 ok -- anything else about the summit? 15:12:36 when will the detailed schedule be ready? 15:12:54 llu-laptop: by Tuesday 15:12:54 I mean for whole summit 15:13:48 looking forward to seeing the schedule 15:13:58 Thurs is going to be busy 15:14:09 definitely 15:15:05 #topic Open discussion 15:15:15 we're running out of topics :) 15:16:37 that'll all change once we get the CM summit schedule :) 15:16:44 dhellmann: unless I'm mistaken asalkeld did release v1.0.0, though may not of updated docs it was: 15:17:00 git tag -s 1.0.0 15:17:07 git push gerrit 1.0.0 15:17:31 dragondm, did you want to give any updates on the nova changes you've been making around notifications? 15:17:49 esdaniel: you're right 15:17:55 esdaniel: maybe we need a job to build the lib and push it to pypi, then? 15:18:00 oh, no, it's there! 15:18:01 #link https://pypi.python.org/pypi/python-ceilometerclient 15:18:17 yep, it's a little behind after it syncs first with our mirror then pypi i believe 15:18:23 so we didn't get any notification as I though we would, but it's done 15:18:27 fantastic 15:18:37 zigo: https://pypi.python.org/pypi/python-ceilometerclient for you! 15:18:42 Yah, in basic, I've got some changes that should allow nova to publish notifications for all the info that ceiliometer's compute agent emits. 15:18:46 asalkeld did it 5 mins after you asked him :-) 15:18:53 maybe we can make that job post to irc and/or the mailing list 15:18:57 jd__: Tagged? KEWL! :) 15:19:03 dhellmann +1 15:19:08 dragondm: cool 15:19:14 dhellmann: +1 :) 15:19:21 dragondm: under review or merged? 15:19:43 Isn't up in gerrit yet. 15:20:00 Will be sometime this week or early next. 15:20:16 (was waiting for the grizzly branch to cut) 15:20:20 dragondm: add me as a reviewer, when you post it, please? 15:20:26 Will do. 15:20:30 draondm: does that mean we no longer need the ceilometer.compute.nova_notifier? 15:20:43 Yup, that is the idea. 15:21:32 dragondm: good to hear that 15:21:49 Also in the pipeline is a lightweight UDP notification mechanism. 15:22:08 dragondm: nice too :) 15:22:58 does it sound possible that at some point nova can emit Ceilometer meters directly rather than notifications? 15:23:02 or is it still too soon? 15:23:09 would we want that? 15:23:10 That should also be up in oslo shortly. I'm still working on the receiving side for cm. Hope to have that before summit. 15:23:45 dhellmann: I know what I would want that, why wouldn't you want that? ;) 15:23:49 s/what/why/ 15:24:26 jd__ I'm not to sure about that... 15:24:33 jd__: given the amount of trouble we've had tying the two projects together all along, it seems like agreeing on a common format is better than having nova try to use our format 15:25:49 right 15:26:00 by the way, I think that at some point we're going to split the collector 15:26:17 don't know if the subject poped in someone else mind so far 15:26:32 publishing directly to CM isn't really a good idea unless it's going directly into the CM queue. If CM goes down, production will suffer 15:27:16 jd__: yeah, it makes sense to split up the 2 parts of the collector 15:27:35 dhellmann: ok, I may tackle that at some point 15:27:49 Aye. Tho that is part of the impetus for udp notifications. The downside is they get dropped if the receiver isn't there. The upside is they don't overload rabbit in that case. 15:27:54 jd__: I also had the idea of letting the notification handler just write to the database directly, instead of sending all of the data back out (depending on the pipeline configuration, of course) 15:27:57 jd__: Any idea why the Git repo on Alioth has so many tags, like 1.0.1, 1.0.2 and the like? 15:28:06 zigo: url? 15:28:28 dragondm: I imagine it's an operator choice for trade off at this point anywya 15:28:36 yup. 15:28:44 jd__: http://anonscm.debian.org/gitweb/?p=openstack/python-ceilometerclient.git 15:28:50 * zigo don't understand why 15:28:52 dhellmann: depending on the pipeline configuration yeah -- that may be tricky but why not 15:29:21 Gosh, it has *cinder* tags in. 15:29:23 What a mess. 15:29:26 * zigo will fix. 15:30:10 jd__: well, the daemon that handles notifications could have a different pipeline config file from the other daemons (specified on the command line when the service starts) 15:30:35 dhellmann: but that'd work against my split idea 15:30:43 ? 15:30:46 dhellmann, +1 15:31:01 oh, you don't want the notifications handler to touch the database? 15:31:25 dhellmann: yeah, that doesn't sound like a good isolation scheme 15:31:27 yah, also another change I have for oslo is a routing notification driver, that can send notifications to other drivers according to event_type 15:32:36 dhellmann: now you understand why I'd be happy if nova would use ceilometer.pipeline to publish metering 15:32:37 Having a separate store (e.g a mongo db) that you throw the notifications into wouldn't be a bad idea. 15:32:48 dragondm: is that something the deployer should configure? 15:33:16 jd__: we'll have to put it in a separate library for that to work, I think 15:33:24 dhellmann: Yes. Uses a json config file. It's similar to python's logging confs, but with a better syntax. 15:33:38 dhellmann: sure, but would it work (= be accepted) if we do that? 15:33:58 jd__: well, it would just need to work as a notification driver, right? 15:34:00 dragondm: better syntax? doesn't sound like a great challenge to me ;-) 15:34:07 Heh. yah. 15:34:40 dhellmann: no that you tell it, YEAH! :) 15:34:42 s/no/now/ 15:35:03 with dragondm's changes, it could be awesome 15:35:22 and if we can make it a small package, so they don't have to install all of ceilometer on the hypervisor... 15:35:35 nova -> multipublisher -> meters over rpc, udp, whatever -> destination 15:35:36 I will put you folks on as reviewerd when I put those changes up. 15:35:52 dhellmann: we may put pipeline things and drivers in oslo 15:35:57 so rip the publishing stuff out of ceilometer and have both nova and ceilometer use it 15:36:01 yeah 15:36:18 that's the beauty of the notification driver, operators choice 15:36:21 so we totally kill the ceilometer piece doing the notifications -> meters conversion 15:36:25 less round trip 15:36:28 less load on AMQP 15:36:33 more happyness 15:36:47 jd__: yep 15:36:59 Always good (less load on amqp) The current nova-cells is killing rabbit as-is 15:37:08 good to hear 15:37:14 I'll plan out some bp about that 15:37:21 Always in favor of more happyness. 15:37:22 I was just about to suggest that :-) 15:37:48 the downside is that notification drivers don't fit in the exception handling chain (they're a nice-to-have) 15:38:14 by keeping them simple (like a rabbit publish) the complexity is moved to somewhere that that handle it better 15:38:18 sandywalsh: I don't think it's worth than what we have now 15:38:28 (retries, etc) 15:38:37 worst? 15:38:42 worst. 15:38:45 :) 15:39:04 :) 15:39:15 still, I don't think complexity belongs in the nova notification driver 15:39:27 it a dumb animal 15:39:32 it's 15:39:39 :-) 15:40:06 (another beer debate I feel :) 15:40:47 sandywalsh: bah I'll be happy to move more close to nova, but I don't feel like I'm the one that can +2 that ;) 15:42:08 anything else or should I end this madness? 15:42:29 * dhellmann is ready to get off of this crazy train 15:42:30 ot: john o'hara speaking on 18/4 in london if anyone's interested 15:42:35 apologies folks, caught up in another meeting 15:43:10 oops 17/4 my bad 15:43:11 hi eglynn_ 15:43:16 hey 15:43:49 thankfully meetings are logged, I can get caught up ... 15:44:29 eglynn_: it hasn't be too long, but we're closing 15:44:38 eglynn_: something you want to talk about? 15:44:56 nope, I'm good thanks ... 15:45:14 Hi, guys, 15:45:34 jd__: I got something else if you don't mind. 15:45:40 zigo: go ahead 15:45:45 distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('setuptools-git>=0.4') 15:45:49 can I ask you about the gauge on the storage (swift)? 15:45:51 That's in the clean target. 15:45:58 That's really annoying for my cowbuilder. 15:46:11 It would be nice not to have such requirement at clean time. 15:46:32 Enabled ceilometer on swift, 15:46:47 zigo: we only have this listed in test-requires 15:46:55 getting some information back, but could not figure out what these numbers really mean. 15:47:03 zigo: which isn't read by setup.py AFAICT 15:47:20 tongli: which one? 15:47:28 anyone here can help explain how to make sense of these numbers. 15:47:46 @jd__, let me get an example here. 15:48:00 tongli: you may want to ask on #openstack-metering though 15:48:21 yeah, did that yesterday, no response. 15:48:25 I can ask again. 15:48:30 zigo: #openstack-metering ? :) 15:48:33 tongli: we're all there 15:48:40 k 15:48:46 #endmeeting