21:00:48 <nijaba> #startmeeting Ceilometer
21:00:48 <nijaba> #meetingtopic Ceilometer
21:00:48 <nijaba> #chair nijaba
21:00:48 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
21:00:48 <nijaba> ATTENTION: please keep discussion focused on topic until we reach the open discussion topic
21:00:49 <openstack> Meeting started Wed Feb 13 21:00:48 2013 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:52 <openstack> The meeting name has been set to 'ceilometer'
21:00:54 <openstack> Current chairs: nijaba
21:00:58 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting?
21:00:58 <nijaba> o/
21:01:00 <dhellmann> o/
21:01:04 <n0ano> o/
21:01:11 <eglynn> o/
21:01:18 * dragondm waves
21:01:21 <dragondm> o/
21:01:22 <jd__> o/
21:01:46 <nijaba> nice to see everyone!
21:01:52 <nijaba> #topic actions from previous meeting
21:01:52 <nijaba> #topic dhellman to update documentation based on http://wiki.openstack.org/Ceilometer/Units
21:02:01 <nijaba> dhellmann: update?
21:02:02 <dhellmann> no work on that, sorry
21:02:08 <nijaba> reaction?
21:02:11 <dhellmann> repeat for next week
21:02:12 <dhellmann> yeah
21:02:26 <dhellmann> #action dhellmann to update documentation based on http://wiki.openstack.org/Ceilometer/Units
21:02:32 <nijaba> thanks
21:02:40 <nijaba> #topic eglynn, jd, sandywalsh, spn, nijaba, dhellmann to help on http://wiki.openstack.org/Ceilometer/Graduation
21:02:40 <nijaba> #info done
21:02:40 <nijaba> There is a topic for the graduation process
21:02:59 <nijaba> #topic nijaba to write an email explaining how to propose a topic for the H summit
21:02:59 <nijaba> #info done
21:03:08 <nijaba> We do need some clarification between the session tool and the bp process though.  There is a topic for that too
21:03:38 <nijaba> that's it for last week's actions
21:03:48 <nijaba> #topic G3 blueprints review
21:03:48 <nijaba> #link https://launchpad.net/ceilometer/+milestone/grizzly-3
21:04:00 <nijaba> anything that should be updated in the bp status?  We have one week left before feature freeze!
21:04:49 <sandywalsh> o/
21:04:49 <asalkeld> sorry late
21:04:52 <dhellmann> I've been working on the notification subscription api for oslo
21:05:08 * jd__ all green
21:05:20 <asalkeld> nijaba, I need to add v2 support to the client
21:05:21 <dhellmann> it's not far enough along to submit there, but I'm not blocked on anything other than the number of hours in  a day
21:05:29 <nijaba> dhellmann: yep, I saw that.  I updated the status of the bp to "good progress"
21:05:30 <eglynn> I'll slot the qpid testing in early next week, so will be done for g3
21:05:44 <dragondm> dhellmann: nice.
21:05:53 <nijaba> eglynn: great!
21:05:59 <jd__> nijaba: if bps are Implemented now but not targetting anything in Grizzly, should we set a target or milestone to something to indicate the release it's implemented in?
21:06:17 <nijaba> jd__: please, retarget indeed!
21:06:19 <dhellmann> jd__: that seems like a good idea
21:06:19 <jd__> asalkeld: I've started that I think there's a review for that
21:06:40 <jd__> nijaba, dhellmann ok, i'll have some work then :-] I think i've a few!
21:06:53 <nijaba> jd__: this is what I call good surprises :)
21:07:02 * dhellmann notes that jd__ has been a coding machine lately
21:07:11 <asalkeld> well done jd
21:07:12 <jd__> :)
21:07:22 <jd__> thanks guys
21:07:57 <nijaba> anything else on that topic?
21:08:27 <nijaba> guess not...
21:08:37 <nijaba> #Graduating from incubation update
21:08:43 <dhellmann> well, any update on https://blueprints.launchpad.net/ceilometer/+spec/publisher-counters-frequency?
21:08:47 <nijaba> meeting one of 3 or 4 went well I think. Thanks to everyone's contribution
21:08:47 <nijaba> It was focused on why we think we are ready.
21:09:04 <dhellmann> #topic Graduating from incubation update
21:09:13 <dhellmann> hmm, guess I can't tell the bot what to do
21:09:14 <nijaba> dhellmann: thanks :)
21:09:31 <nijaba> #topic Graduating from incubation update
21:09:37 <eglynn> yeah I think it went relatively well
21:09:41 <eglynn> (so far ...)
21:09:52 <nijaba> Next week we'll be discussing our architecture stability.  Same time, same place.  Unfortunately, I have another commitment that evening, so I would appreciate if someone else could take the lead.  Volunteer?
21:10:07 <eglynn> will all 3/4 meeting be considering Heat and Ceilo in parallel?
21:10:08 <dhellmann> are the logs for that meeting available?
21:10:13 <nijaba> I think the prep work is all done
21:10:21 <eglynn> I can do it
21:10:38 <jd__> i'll be there too
21:10:49 <dhellmann> I should be able to attend, too
21:11:01 <eglynn> #link http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.log.html
21:11:21 <eglynn> dhellmann ^^^ logs for the last meeting
21:11:26 <dhellmann> excellent
21:11:45 <dhellmann> Tuesdays are turning into "go to the doctor" days, so I may be a little late next week
21:11:46 <nijaba> eglynn: yep
21:12:03 * nijaba 's connection dropped for a while, sorry
21:12:22 <eglynn> dhellmann, jd__: lets huddle before next week's TC meeting to talk startegy, do any prep required etc.
21:12:34 <jd__> eglynn: sounds like a good plan!
21:12:40 <nijaba> thanks to the volunteers
21:12:53 <dhellmann> eglynn: yes, definitely -- Monday?
21:12:55 <asalkeld> not a good time for me
21:13:04 <nijaba> eglynn: the prep on the arch is already started on the wiki page
21:13:06 <eglynn> dhellmann: Monday works for me
21:13:11 <eglynn> nijaba: cool
21:13:32 <jd__> Monday works for me too
21:13:35 <dhellmann> eglynn: maybe we should try to pick a time when we can get asalkeld's input, too, if he won't be able to attend Tuesday
21:13:49 <eglynn> great idea
21:14:11 <nijaba> or we could continue to use the wiki as an async tool to put our brains together?
21:14:18 <asalkeld> sure
21:14:19 <dhellmann> nijaba: yeah, that, too
21:15:00 <eglynn> lets do a short huddle as well, say Monday at this timeslot?
21:15:16 <jd__> fine with me
21:15:27 <dhellmann> eglynn: ok
21:15:31 <nijaba> eglynn: +1, I'll do my best to join
21:15:34 <eglynn> cool
21:16:40 <dhellmann> eglynn: in our metering room (unless this room is available?)
21:16:44 <nijaba> #info prep meeting for next tc meeting monday at 21UTC in #openstack-metering
21:16:47 <eglynn> sounds like a plan
21:17:04 <nijaba> we do not need a bot, so our chan seems fine
21:17:17 <dhellmann> sounds good
21:17:37 <jd__> like we would wander on IRC without finding each others :)
21:17:46 <nijaba> ok, let's move on
21:17:51 <nijaba> jd__:  hehe
21:17:56 <nijaba> #topic Should we deprecate the V1 API? - dhellmann
21:17:58 <dhellmann> jd__: packets passing in the night
21:18:08 <dhellmann> ah, yes
21:18:11 <nijaba> dhellmann: go ahead and defend your proposal!
21:18:13 <jd__> this is a bold topic
21:18:15 <nijaba> ;)
21:18:21 <eglynn> deprecate == continue to support for 1 more release cycle?
21:18:30 <dhellmann> yes, start the process of deprecation
21:18:45 <jd__> I am not confortable doing that for G
21:18:47 <dhellmann> the v2 api is much better, and if it isn't complete yet it will be very early in h
21:18:49 <nijaba> why?
21:18:50 <jd__> v2 isn't really finished yet
21:19:06 <dhellmann> so I think *after H* we should drop v1
21:19:15 <sandywalsh> +1
21:19:22 <eglynn> does anyone recall the mechanics of the nova v1 API deprecation?
21:19:23 <jd__> releasing G with "you can use v1 but it's deprecated, so use v2 but it's not finished" isn't really friendly
21:19:26 <dhellmann> or at least start the process of dropping it, following whatever the usual support path is
21:19:27 <eglynn> (before my time)
21:19:48 * eglynn wondering how long a released API should be kept around for ...
21:19:49 <nijaba> We have multiple people starting to dev for v1.  I have a hard time convincing them to use the api rather than hitting the db directly. if we deprecate the api, there is no point in using the api at all
21:19:55 <dhellmann> jd__: yep, that's why I'm suggesting for with or after h
21:20:14 <sandywalsh> I think dropping it before incubation ends might be the only factor there :)
21:20:14 <jd__> dhellmann: you suggest deprecate for H or remove for H?
21:20:28 <dhellmann> jd__: deprecating
21:20:40 <dhellmann> so it would come out in, what, I or J? I'm not sure of the rules.
21:20:42 <jd__> dhellmann: in that case I agree :)
21:20:53 <nijaba> I am personally NOT in favor of removing it before J at least
21:20:56 <eglynn> make a clear statement its on the deprecation path, but keep support in place for H, right?
21:21:03 <jd__> nijaba: I think that's acceptable
21:21:03 <dhellmann> basically, I want to start the process as part of the plans for H, but I don't want to consume an entire summit session to have the conversation about it
21:21:06 <sandywalsh> dhellmann, seems reasonable ... is it a fork-lift change? (rewrite of client usage required)?
21:21:22 <nijaba> sandywalsh: yes :(
21:21:33 <sandywalsh> hmm
21:21:38 <dhellmann> sandywalsh: good question, I'm not sure. I suspect so, but we might be able to put a shim into the client to ease the transition.
21:21:38 <jd__> sandywalsh: yes, but it isn't like a big conceptual change neither
21:21:46 <dhellmann> right
21:22:03 <jd__> we just simplified things, etc, it's not like we were changing paradigm(s) entirely
21:22:09 <dhellmann> this isn't something we need to decide during this meeting, I just wanted to start people thinking about it.
21:22:21 <jd__> ack :)
21:22:24 <dhellmann> Like I said, I don't think we need a summit session on the subject, but it's something to be deciding as we go into H.
21:22:30 <eglynn> my main concern is that we go to pains to follow "best community practice" on the deprecation
21:22:35 <nijaba> but still, the point of having people use an API is to shield them from underlying changes.  I do not see why we could not maintain v1 andv2
21:22:43 <eglynn> (so that it doesn';t become an issue in the graduation assessment ...)
21:22:44 <dhellmann> eglynn: yes, absolutely (I just don't know what those are, yet.)
21:22:53 <asalkeld> perhaps a statement in the dosc would be good
21:22:58 <sandywalsh> that's what nova did ... the keystone default endpoint just changed to /v2
21:23:04 <jd__> nijaba: we probably can for I, maybe after it'd be a burden
21:23:14 <sandywalsh> /v1 still works, but it's essentially frozen
21:23:20 <dhellmann> nijaba: the problem is maintaining support for both in the storage drivers, if we have to change the storage formats
21:23:20 <eglynn> dhellmann: me neither, anyone familiar with how the nova v1 API deprecation was handled?
21:23:40 <sandywalsh> eglynn, ^
21:23:57 <dhellmann> sandywalsh: so the nova v1 api is still there?
21:24:04 <sandywalsh> it was several milestones later that it was physically removed
21:24:20 * sandywalsh double checks it *was* actually removed
21:24:22 <eglynn> sandywalsh: a-ha, I didn't realize that ... thanks for the info
21:24:41 <asalkeld> dhellmann, re the db, you optimise for the new api and just make the old api function
21:25:09 <asalkeld> so make the old api ugly, not the new api
21:25:24 <dhellmann> asalkeld: makes sense
21:25:31 <nijaba> asalkeld: that would be somewhat more acceptable
21:25:44 <sandywalsh> nova v1 is now physically removed
21:25:52 <dhellmann> FTR, I'm OK with keeping it, too, if we decide we want to go that route. I just wanted to bring it up, since v2 is nearing feature-completeness
21:26:11 <nealph> would like to have time with v2 to kick the tires and provide feedback while v1 is still functional...
21:26:16 <dhellmann> how about if I table this until after the ODS?
21:26:22 <eglynn> another datapoint is how the glance v1/v2 API transition is being handled ... using config options to selectively enable/disable the two APIs independently
21:26:25 <nijaba> over time
21:26:34 <eglynn> dhellmann: that might be wise
21:26:48 <asalkeld> what are the missing gaps in the v2 api?
21:26:54 <asalkeld> post api
21:26:54 <nijaba> dhellmann: yes please!
21:27:00 <dhellmann> #info motion tabled
21:27:09 <dhellmann> asalkeld: I need to be able to query against projects that have updates
21:27:09 <jd__> :)
21:27:25 <nijaba> #topic We need more people doing active code reviews. - dhellmann
21:27:30 <sandywalsh> my bad ... /v1.1 now maps to /v2
21:27:34 * eglynn hangs head in shame
21:27:43 <dhellmann> we have, I think, 15 pending changesets
21:27:45 <nijaba> I think the plea is clear
21:27:47 <eglynn> (about lack of time fore reviewing ...)
21:27:56 <dhellmann> so either jd__ needs to slow down, or we need to pick up the pace on reviews
21:27:59 <sandywalsh> dhellmann, I'll try and get some more done
21:28:05 * jd__ can't slow down
21:28:16 <eglynn> at one point nova had this concept of a rotating "review day"
21:28:17 <nijaba> it does not help that it is a holliday week in china
21:28:21 <asalkeld> it's jd__ fault he works too fast
21:28:25 <jd__> but i'll be on vacation in a few weeks ;)
21:28:34 <sandywalsh> jd__, I'm usually on early (nova scotia time) ... ping me if you have something you need looked at urgently. Can't help on the +2's though :)
21:28:44 <eglynn> so one core reviewer was the designated primary each working day
21:28:52 <nijaba> I could do some reviews...  but I tried to get away from that as we we getting more core devs
21:28:58 <dhellmann> eglynn: that's an interesting idea
21:29:06 <eglynn> and committed to dedicating a significant of their time to the backlog
21:29:06 <jd__> sandywalsh: well +1 helps too :)
21:29:09 <nijaba> feel free to ping me if I can help
21:29:20 <sandywalsh> eglynn, we dropped core review days in nova. It was restrictive
21:29:32 <eglynn> sandywalsh: k
21:29:36 <dhellmann> is everyone subscribed to the ceilometer updates from gerrit, so you're notified of new changes automatically?
21:29:52 <jd__> honestly, compare to other projects I'm not sure we are that slow
21:29:54 * eglynn thought it might have legs with a smaller group of core devs ...
21:30:04 <jd__> I've much more trouble getting patches approved on keystoneclient for example…
21:30:22 <dhellmann> jd__: feel free to add me as a reviewer to anything, and I'll look at it
21:30:25 <jd__> to the point some patches have +1 and +2 and expire…
21:30:31 <jd__> dhellmann: thanks :)
21:30:42 <nijaba> jd__: same here
21:31:08 * jd__ is going to spam dhellmann and nijaba
21:31:12 <nijaba> hehe
21:31:21 * dhellmann knows how to set up mail filters
21:31:22 <eglynn> on glance, direct harassment on IRC to scare up reviewers is common, and isn't resented too much ...
21:31:37 <jd__> https://review.openstack.org/#/c/20817/ is really useful for Ceilometer, and still waiting like, for ever
21:32:03 * dhellmann makes a note to look at that tomorrow morning
21:32:04 <nijaba> I'll do that one today then
21:32:04 <sandywalsh> eglynn, +1, that's a best practice :)
21:32:38 <dhellmann> anyway, if you're a reviewer, please take a look at our current backlog when you have time
21:32:40 <jd__> nijaba, dhellmann I've just added you to 4 or 5 reviews on keystoneclient :)
21:32:50 <nijaba> jd__: ah, that 's in keystone, I won't help much there
21:32:56 <dhellmann> I'm probably going to be adjusting my schedule to mostly do reviews on thursdays, with less emphasis the rest of the week
21:33:01 <nijaba> or not as much
21:33:13 <jd__> nijaba: nevermind :)
21:33:55 <nijaba> anything else on that topic?
21:34:09 <dhellmann> no
21:34:16 <nijaba> #topic Ceilometer summit session process
21:34:28 <nijaba> So, I did sent my email about how to propose a bp for discussion at the summit
21:34:28 <nijaba> ttx replied to my email saying we could use the summit tool too
21:34:28 <nijaba> I personally think that we should use a mix of both, and propose that for any session proposing a technical change or addition, a bp MUST be linked so that we have a place to prepare the session.  What do you guys think?
21:34:53 <dhellmann> +1
21:34:57 <jd__> sounds good +1
21:34:59 <sandywalsh> +1
21:35:01 <eglynn> yep
21:35:04 <asalkeld> k
21:35:24 <nealph> is the summit tool gated on the Feb-15th deadline?
21:35:43 <sandywalsh> I'm still a little confused how best for us all to meet and pound out the topics like metadata and aggregation ... informal or separate session talks?
21:35:43 <nijaba> ok, so the reviewer of summit.o.c will have the role to enforce that
21:35:47 <nijaba> nealph: no
21:36:07 <nijaba> sandywalsh: separate sessions
21:36:20 <sandywalsh> nijaba, cool ... and will you guys be registering those?
21:36:25 <asalkeld> sandywalsh, last time we had one day for ceilometer
21:36:26 <nijaba> nealph: we have until the week before the summit to adjust the schedule I think
21:36:36 * sandywalsh doesn't want to cause duplication
21:36:38 <asalkeld> then the rest of the days to meet up
21:36:48 <asalkeld> we could do both
21:36:53 <nijaba> sandywalsh: I am for sure a reviewer at this time.  next ptl will be too
21:37:02 <dhellmann> sandywalsh: in the past, I've had PTLs propose merging sessions to avoid dupes
21:37:09 * dhellmann would rather merge dupes than miss an important topic
21:37:12 <nealph> nijaba:thx
21:37:18 <nijaba> dhellmann: same here
21:37:20 <nealph> *working bp's for discussions
21:37:23 <sandywalsh> ok, I'll submit and we can merge if needed
21:37:34 <nijaba> sandywalsh: thanks
21:37:37 <sandywalsh> nealph, +1
21:37:54 <dhellmann> can I also suggest that folks email the list with topics they propose, for those of us who are not reviewers and not seeing email notifications from the summit planning tool?
21:38:10 <sandywalsh> good idea
21:38:21 <nijaba> #agreed session should link to bp if a change is proposed
21:38:26 <dhellmann> that will also give us a chance to subscribe to the blueprints, wiki pages, etc.
21:38:30 <asalkeld> eglynn, are you going to talk about synaps stuff?
21:38:49 <asalkeld> arch etc..
21:38:50 <eglynn> asalkeld: yep, I'm planning to propose
21:38:55 <asalkeld> k
21:39:03 <eglynn> at least one session
21:39:16 <asalkeld> nijaba, do we have any input on timing
21:39:16 <eglynn> just to clarify the Feb-15th deadline mentioned above
21:39:25 <eglynn> that's for the conference track only, right?
21:39:42 <asalkeld> last year we had ceilometer and heat at the same time
21:39:43 * dhellmann has to drop off in a few minutes
21:39:50 * eglynn too
21:40:17 * dhellmann bbiab
21:40:52 <nijaba> asalkeld: we should have our own rooms this year
21:41:09 <nijaba> asalkeld: and as much time as we ask for
21:41:20 <nijaba> withing the summit dates, of course
21:41:21 <asalkeld> hopefully not overlapping
21:41:22 <eglynn> nijaba: different days would be good too
21:41:41 <nijaba> asalkeld: ack
21:42:24 <nijaba> anything else for this topic?
21:42:30 <asalkeld> nope
21:42:40 <nijaba> #topic Open discussion
21:42:45 <dragondm> sounds fine.
21:43:18 <nijaba> is the bot dead, or is it my connexion?
21:43:29 <jd__> nijaba: you put a space in front of #topic
21:43:38 <nijaba> #topic Open discussion
21:43:42 <jd__> it's picky
21:43:45 <nijaba> jd__: thanks
21:43:48 <sandywalsh> so, I've spent the last two days working on a summary report in StackTach (we needed internally) ... I'd like for people to think about how we could get such a report from CM :)
21:43:55 <sandywalsh> snip: https://gist.github.com/SandyWalsh/4946226
21:44:31 <sandywalsh> (I'll be thinking about it too :)
21:45:12 <sandywalsh> it's the PHB report
21:45:54 <nijaba> jd__: my connection is so bad, can I #chair you for the end of the meeting?
21:46:00 <jd__> nijaba: sure
21:46:13 <eglynn> sandywalsh: p90 +/- 5% == the range p85..p95?
21:46:18 <nijaba> #chair jd__
21:46:18 <openstack> Current chairs: jd__ nijaba
21:46:24 <sandywalsh> eglynn, p90
21:46:32 <nijaba> jd__: thanks
21:46:47 <eglynn> sandywalsh: can you explain the "(+/-5.0% cut)"
21:46:51 <sandywalsh> eglynn, sorry lowest 5% and top 5% dropped
21:47:36 <sandywalsh> 5% of the sorted populated
21:47:46 <sandywalsh> population
21:47:53 <eglynn> sandywalsh: the lowest & highest 5% in the 90th percentile bucket, or overall?
21:48:06 <asalkeld> so this doesn't seem tooo far from the statistics query we have
21:48:12 <sandywalsh> eglynn, overall
21:48:15 <eglynn> k
21:48:47 <sandywalsh> asalkeld, I'd love to see how you generate it ... this was quite a treat
21:49:20 <sandywalsh> (and failures can be operations that took too long)
21:49:39 <asalkeld> well there is some missing bits, we don't have all the notification info atm
21:49:50 <asalkeld> operation/failures
21:49:52 <sandywalsh> right
21:49:53 <asalkeld> timing
21:49:57 <sandywalsh> heh
21:50:07 <sandywalsh> (that's the whole report :)
21:50:09 <asalkeld> Min* |   Max* |  Avg* | Requests
21:50:12 <jd__> yes, that'd be new meters to add
21:50:14 <asalkeld> we have that ^
21:50:49 <sandywalsh> asalkeld, how, request_id isn't tracked is it?
21:51:02 <asalkeld> don't think so
21:51:21 <asalkeld> but our query api so quite powerful
21:51:25 <sandywalsh> you need that to compute duration
21:52:00 <asalkeld> something like groupby request_id
21:52:02 <sandywalsh> anyway ... something to consider
21:52:13 <jd__> sure
21:52:14 <asalkeld> yip
21:52:31 <jd__> anything else before I close the meeting?
21:52:59 <nijaba> nope
21:53:01 <nijaba> :)
21:53:19 <asalkeld> later guys
21:53:28 <sandywalsh> later!
21:53:28 <nijaba> thanks everyone!
21:53:57 <jd__> thanks guys
21:54:02 <jd__> #endmeeting