15:03:28 <jd__> #startmeeting ceilometer
15:03:29 <openstack> Meeting started Thu Jul 25 15:03:28 2013 UTC.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:32 <openstack> The meeting name has been set to 'ceilometer'
15:03:45 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
15:03:55 <jd__> hi everyone
15:04:05 <llu-laptop> o/
15:04:06 <eglynn> o/
15:04:13 <apmelton> o/
15:04:26 <gordc> o/
15:04:29 <terriyu> o/
15:04:48 <jd__> dhellmann is excused
15:05:13 <nealph> 0/
15:05:21 <jd__> #topic nealph to finish looking into tempest QA efforts
15:06:15 <jd__> nealph: any update? :)
15:06:27 <nealph> had some time to look ad this and recruit some help from tempest experts.
15:06:39 <nealph> will start work on test design this week.
15:06:42 <eglynn> great!
15:07:02 <jd__> awesome
15:07:10 <sileht> o/
15:07:19 <eglynn> note https://review.openstack.org/36367
15:07:28 <eglynn> tempest addition for heat autoscaling
15:07:30 <nealph> so, I'll just keep updating the bp with progress
15:07:39 <jd__> nealph: so feel free to keep us in touch and to add this as a meeting topic whenever you want to keep us informed on the progress or whatever!
15:07:48 <nealph> will do. thx.
15:08:23 <eglynn> (in the commit msg: "Due to the nature of this test, it takes about 10 minutes to run locally")
15:08:47 <eglynn> I had thought that adding lots of extra time to a test run was problematic
15:09:04 <eglynn> but maybe with parallelization, not so much any more ...
15:09:16 <jd__> probably less a problem that no test at all
15:09:26 <eglynn> jd__: true that!
15:09:40 <jd__> eglynn: so that's autoscaling based on the old code w/o Ceilometer IIUC?
15:10:11 <eglynn> jd__: yep the old approach for now
15:10:24 <eglynn> jd__: IIUC, but soon to be updated to the new
15:10:43 <nealph> interesting. I'll review that offline...not sure of the implications just yet.
15:11:00 <jd__> ok cool
15:11:05 <jd__> nealph: probably not much yet
15:11:19 <eglynn> nealph: might be interesting/informative to compare notes with sbaker
15:11:37 <eglynn> (as he's doing most of the heat tempestification work it seems)
15:11:37 <nealph> planning on it, absolutely.
15:11:40 <eglynn> cool
15:12:34 <jd__> #topic eglynn release python-ceilometerclient as soon as https://review.openstack.org/#/c/37410/ gets in and unblock https://review.openstack.org/#/c/36905/
15:12:53 <eglynn> jd__: got in before me with cutting the new client
15:13:10 <jd__> yeah sdague kept complaining :)
15:13:16 <sdague> :)
15:13:25 <eglynn> yep, it's all good :)
15:13:32 <jd__> https://review.openstack.org/#/c/36905/ doesn't work but that requires code adjustement, I'll look into that
15:13:50 <sdague> jd__: yeh, I was about to ask about that
15:14:05 <sdague> that's the last piece of the puzzle to uncap the clients in the gate
15:14:58 <jd__> ack, I'll try to fix it ASAP
15:15:08 <jd__> #topic Add logging to our IRC channel? - dhellmann
15:15:53 <eglynn> were we going to take a vote on it?
15:16:06 <eglynn> (or defer again if we don't have quorum today)
15:16:20 <apmelton> so is there any downside to having logging?
15:16:46 <apmelton> other than most people are probably doing it locally?
15:16:46 <jd__> not really IMHO
15:16:47 <eglynn> folks being more guarded in what they say I guess
15:17:02 <jd__> I'll keep doing my bad jokes ya know
15:17:28 <nealph> eglynn: haven't decided if that's a bad thing yet. :)
15:17:41 <eglynn> me neither :)
15:17:55 <jd__> so, is anybody against this anyway?
15:18:13 <gordc> jd__, asalkeld was against if i remember.
15:18:27 <eglynn> yep he was
15:18:31 <jd__> I seem to remember that
15:18:33 <llu-laptop> what his concerns?
15:19:07 <eglynn> llu-laptop: http://eavesdrop.openstack.org/meetings/ceilometer/2013/ceilometer.2013-07-17-21.00.log.html
15:19:42 <gordc> llu-laptop, i think when we're asleep out here in the 'west', he does secret things.
15:19:43 <eglynn> indefinite retention etc.
15:20:02 <jd__> gordc: lol
15:20:46 <jd__> well I propose we #action dhellmann to set up a wiki page or something so we can vote
15:21:01 <eglynn> sounds reasonable
15:21:01 <jd__> since we aren't going to have a meeting with everyone anyway
15:21:23 <gordc> yep. sounds good.
15:21:24 <jd__> yeah it's always reasonable to #action away people :D
15:22:01 <jd__> #action dhellmann to set-up a vote (via a wiki page or smthg) on the #openstack-metering logging
15:22:19 <jd__> #topic Review Havana-3 milestone
15:22:31 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-3
15:22:50 <jd__> we've a bunch of stuff not started yet, you should think about starting soon now
15:22:55 <jd__> the sooner the better
15:23:03 <jd__> there's no havana-4, we don't postpone anymore :)
15:24:03 <eglynn> yep, I've another block of dedicated development time ringfenced off
15:24:05 <jd__> (havana 3 is early september)
15:24:11 <jd__> eglynn: cool
15:24:33 <jd__> eglynn: if you've anything you want help or you want to drop entirely, don't hesitate because sileht is bored
15:24:43 <eglynn> cool ;)
15:24:47 <sileht> :D
15:25:02 <BrooklynChen> jd__: the ceilomter-plugin for horizon is not completed yet and it's for havana-3.
15:25:14 <jd__> BrooklynChen: ok!
15:25:16 <litong> @jd__, we have a specific date for H3?
15:25:32 <eglynn> yeah I was gonna ask about horizon too
15:25:42 <eglynn> #link https://blueprints.launchpad.net/horizon/+spec/ceilometer
15:25:49 <jd__> litong: 6th September
15:26:05 <litong> k. thx.
15:26:29 <BrooklynChen> now the problem for horizon is that the usage summary table takes a lot of time loading the data
15:27:04 <eglynn> BrooklynChen: is the usage summary timestamp-constrained?
15:27:21 <eglynn> BrooklynChen: e.g. last day/week/month
15:27:50 <BrooklynChen> eglynn: the issue is, we don't have a group-by api in ceilometer and the grouping is done by horizon. that needs a lot of time
15:28:08 <eglynn> BrooklynChen: a-ha I see
15:28:19 <eglynn> BrooklynChen: but there is broup-by on the cards for h3
15:28:42 <eglynn> #link https://blueprints.launchpad.net/ceilometer/+spec/api-group-by
15:28:53 <jd__> yeah we're working on group-by
15:29:05 <jd__> I know this is the main pain point
15:29:18 <jd__> terriyu is working on that :)
15:29:31 <terriyu> yes, sorry everyone I've been slow getting started
15:30:09 <BrooklynChen> terriyu:  we may need to talk about this. that helps if it's added to ceilometer-api
15:31:24 <terriyu> BrooklynChen: sure, we can talk.  I'm new, so I don't really know anything about Horizon
15:32:09 <BrooklynChen> jd__:  sorry about the email and I will check the statistic with period= parameter
15:32:25 <BrooklynChen> terriyu:  great
15:32:43 <jd__> BrooklynChen: ok cool!
15:33:07 <jd__> BrooklynChen: we'll be happy to enhance the API, we just need a little help on how to improve the existing :)
15:33:46 <apmelton> so, I was wonering if anyone has looked at my event body blueprint, I was hoping to have it slated for H3?
15:33:55 <apmelton> #link https://blueprints.launchpad.net/ceilometer/+spec/event-body
15:34:39 <apmelton> this is part of sandy's stacktach integration group of blueprints
15:35:29 <jd__> apmelton: you can just put it to the h3 milestone I guess
15:35:42 <jd__> apmelton: couldn't that work apply to implement metadata matching on our current meters?
15:37:00 <apmelton> jd__: I'm pretty new to ceilometer so I'm still catching up on everything, do we want every event associated with each meter it's involved with?
15:37:54 <jd__> apmelton: basically we have the same problem currently, we store a JSON of the event in a column, and we want to query it
15:38:11 <apmelton> jd__: then this could definitely be used there as well
15:38:13 <jd__> apmelton: and that's not implemented in the SQL driver because of reasons you describe in this bp
15:38:26 <jd__> apmelton: ok that'd be awesome
15:38:43 <gordc> sweet. this resolves sql metadata query?
15:38:48 <jd__> gordc: yes
15:39:12 <gordc> this will be awesome.
15:39:34 <jd__> apmelton: if you've time I'd love you to take a look and tell us if you think your bp could help in this regard
15:40:04 <apmelton> jd__: I'll poke around with meter metadata and see how I can tweak this BP
15:40:24 <jd__> apmelton: thanks :)
15:40:31 <jd__> #topic Splitting CADF support out of Ceilometer
15:40:36 <jd__> #link https://review.openstack.org/#/c/31969
15:41:21 <jd__> so this is dhellmann topic but I'll speak for him
15:41:53 <jd__> he would like to go ahead and move this outside Ceilometer right away
15:42:29 <jd__> so this could build a pycadf library used by Ceilometer and others
15:42:55 <gordc> jd__, how difficult is it to add it back as a requirement? especially if its not used anywhere except for a single audit filter?
15:42:58 <jd__> dhellmann is willing to help setting up the project on StackForge
15:43:05 <jd__> gordc: not difficult
15:43:18 <litong> @jd__, so pycadf is a ceilometer dependency?
15:43:32 <jd__> litong: would be, yes
15:43:47 <gordc> one reason we started it here is because we'd like it to start in ceilometer as a base and have one proven example.
15:44:03 <eglynn> so the motivation is to allow easy re-use outside ceilometer?
15:44:10 <jd__> eglynn: yes
15:44:17 <gordc> then when other projects (specifically keystone) see its use they can adopt it and we can move it out.
15:44:27 <jd__> gordc: the upside would be that you could develop faster pycadf if it's outside Ceilometer, you won't need our approval
15:44:48 <jd__> gordc: we would move out only the CADF implementation, not everything
15:44:54 <gordc> jd__, that'd be good :P
15:45:29 <gordc> jd__, my main concern for moving it out so soon is that it'll get lost since it barely has traction here
15:45:49 <jd__> why would it get lost if it's used by Ceilometer?
15:47:07 <gordc> maybe unwarranted concern. just worried that the single audit api filter is not a strong enough sell for others to adopt.
15:47:46 <gordc> i think another item is about license? is there anything special needed to be done if we move this code to stackforge?
15:48:07 <jd__> you need to pick a license
15:48:19 <jd__> but you can pick the same as OpenStack
15:48:30 <jd__> you're not force to the CLA OTOH
15:48:55 <jd__> gordc: well the fact that the code is inside or outside but a dependency doesn't matter in term of attrictivness
15:49:09 <jd__> attractiveness
15:49:53 <gordc> for me i'd like to show some keystone folk the working filter and then once we can sell them that, branch out.
15:50:21 <jd__> gordc: actually you'll sell better if you already have something called pycadf they can add to requirements.txt
15:50:38 <jd__> "look at how unintrusive it is!"
15:50:39 <gordc> i guess the time to set up stackforge project and add requirement would be another concern.
15:51:15 <jd__> it's better than "look at how we polluted the Ceilometer project with a bunch of stuff we're going to have to extract painfully now!"
15:51:19 <jd__> :-)
15:51:34 <jd__> gordc: well dhellmann's willing to do that in a snap
15:51:49 <jd__> we are both used to that so it's going to be faster than you think
15:51:51 <gordc> :) well i thought we did a good job keeping it separate
15:52:30 <jd__> gordc: agreed, but from an external PoV, it's not that obvious :)
15:52:41 <jd__> gordc: do you have concerns you want to tackle internally about this?
15:52:45 <jd__> (licensing or others)
15:52:58 <jd__> or can I #action dhellmann right away?
15:53:06 <gordc> let me speak with Matt, he's working on the spec... i think he'll be concern especially with the time to pull this out.
15:53:30 <gordc> maybe i can speak with dhellmann later. i'm not familiar with the setting up external projects so maybe its not a huge concern
15:53:30 <litong> @jd__, @gordc, if it is done as a middleware, it may not even need to be a dependency.
15:53:55 <jd__> litong: well except if we ship the middleware
15:54:06 <jd__> gordc: no problem, don't worry about the infra, we can handle this
15:54:31 <litong> @jd__, right, if we do that.
15:54:51 <gordc> jd__, ok, we can talk more about this after meeting so you can alleviate concerns.
15:55:59 <jd__> ack
15:56:09 <jd__> #topic SQL migration testing with data
15:56:16 <jd__> #link http://openstack.stillhq.com/ci
15:56:39 <jd__> so I've been discussing with mikal recently about how they do SQL tests migration for nova
15:56:44 <jd__> they're willing to do the same for Ceilometer
15:57:13 <jd__> if anyone's interested on working on this, you should obviously get in touch with him :)
15:57:26 <jd__> for now I think the biggest blocker is that they need real data from an SQL instance
15:57:45 <jd__> (data that can be anonymized and never published FWIW)
15:58:24 <gordc> this stuff is dependent on all the migration patches we have currently?
15:58:36 <jd__> gordc: no
15:58:59 <jd__> not AFAIK at least :)
15:59:25 <gordc> k.there's no blueprint for this right?
15:59:41 <gordc> seems interesting though.
16:00:39 <jd__> no bp indeed
16:00:43 <jd__> more a side thing
16:00:47 <jd__> and time's out guy!
16:00:56 <jd__> #endmeeting