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