15:00:31 <nijaba> #startmeeting Ceilometer
15:00:31 <nijaba> #meetingtopic Ceilometer
15:00:31 <nijaba> #chair nijaba
15:00:31 <nijaba> #link http://wiki.openstack.org/Meetings/MeteringAgenda
15:00:31 <nijaba> ATTENTION: please keep discussion focused on topic until we reach the open discussion topic
15:00:32 <openstack> Meeting started Thu Feb 21 15:00:31 2013 UTC.  The chair is nijaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <openstack> The meeting name has been set to 'ceilometer'
15:00:37 <openstack> Current chairs: nijaba
15:00:43 <nijaba> Hello everyone! Show of hands, who is around for the ceilometer meeting?
15:00:43 <nijaba> o/
15:00:45 <dhellmann> o/
15:00:47 <eglynn> o1
15:00:48 <yjiang5> o/
15:00:50 <llu-laptop> o/
15:00:51 <eglynn> o/
15:00:51 <n0ano> o/
15:01:07 <jd__> o/
15:01:22 <nijaba> good to see everyone!
15:01:27 <nijaba> #topic actions from previous meeting
15:01:37 <nijaba> #topic dhellman to update documentation based on http://wiki.openstack.org/Ceilometer/Units
15:01:44 <nijaba> I know this was done and mergedm, thanks dhellmann!
15:01:44 <nijaba> #info done
15:02:00 <nijaba> anything to add on the topic?
15:02:03 <dhellmann> nope
15:02:12 <nijaba> That was it for last week's action, then
15:02:19 <nijaba> #topic graduatiion status
15:02:27 <nijaba> So the TC graduated heat last week, and started on Ceilometer but did not have time to complete.  So the vote will be next week.
15:02:27 <nijaba> Comments?
15:02:31 <eglynn> #link http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-02-19-20.02.log.html
15:02:47 <jd__> no comment
15:03:15 <eglynn> I wasn't too impressed with the "I'm ready to vote now" comment TBH
15:03:15 <nijaba> do you think we need to change something in what we prepared so far?
15:03:19 <dhellmann> eglynn did a great job answering questions as our point man during the meeting
15:03:25 <sandywalsh> o/
15:03:32 <nijaba> thanks eglynn for taking the lead on this
15:03:33 <Pete_> o/
15:03:35 <eglynn> np!
15:03:39 <jd__> yeah good job eglynn
15:03:57 <eglynn> so I was chatting a bit with asalkeld on the phone yesterday about this
15:04:17 <sandywalsh> I think the meeting went fine and they just ran out of time.
15:04:31 <eglynn> he had the idea that we should brainstorm a FAQ for likely questions that may come up in the next meeting
15:04:36 <nijaba> sandywalsh: that was my feeling reading the backlog
15:04:40 <dhellmann> sandywalsh: yeah, we expedted as much because they shifted to going serial
15:04:59 <dhellmann> eglynn, asalkeld: good idea
15:05:10 <dhellmann> OTOH, some of those questions seemed to come out of left field
15:05:12 <jd__> eglynn: why not, though I'm not sure we're going to have a lot of question now
15:05:26 <eglynn> jd__: yep fair point
15:05:30 <nijaba> so let's start an faq on the same wiki page we used so far?
15:05:33 <sandywalsh> dhellmann, the "a little bird told me" re: billing seemed a little out of place
15:05:45 <eglynn> +1
15:05:47 <dhellmann> sandywalsh: ?
15:06:04 <sandywalsh> there was some comment about applicability to billing
15:06:13 <dhellmann> ah, yeah
15:06:18 <dhellmann> there did seem to be some confusion there
15:06:26 <nijaba> #link https://wiki.openstack.org/wiki/Ceilometer/Graduation
15:06:40 <eglynn> so one other thing is the approach of linking to a wiki with a fair bit of dense text
15:07:07 <dhellmann> I get the idea most of the TC hasn't actually been paying super close attention to our project. Which is fair enough, they have their own, projects. But we need to make sure our message is clear on what we've built and what it's for.
15:07:20 * eglynn suspects some of TC members doidn't have time to read it all in tandem with participating in the discussion
15:07:28 <nijaba> dhellmann: agreed
15:07:30 <eglynn> it all == the graduation wiki
15:07:32 <sandywalsh> dhellmann, eglynn +1
15:07:35 <jd__> dhellmann, eglynn +1
15:07:44 <jd__> that's what I think this process is kind of weird, but eh…
15:07:45 <nijaba> eglynn: last time I copy/pasted the texte into the irc chan
15:07:47 <jd__> s/what/why/
15:07:52 <dhellmann> eglynn: indeed. perhaps we can translated it into some bumper-sticker sized statements?
15:07:59 <russellb> perhaps an email with the graduation wiki early in the day of the meeting would be good
15:08:09 <russellb> that'd remind me to go read it and be fresh ahead of the meeting and discussion
15:08:13 <nijaba> russellb: nice idea too
15:08:38 <llu-laptop> dhellmann: +1 for bumper-sticker sized statements
15:09:02 <nijaba> you know how I love for people to take #action :)
15:09:04 <eglynn> dhellmann: yep that would make sense ... also add an easily disgestible (future) architecture diagram that can taken in at a glance
15:09:07 <maksimov> what date is the next TC?
15:09:09 <dhellmann> russellb: +1
15:09:17 <nijaba> who want to have a go at the FAQ?
15:09:30 <nijaba> at he bumber sticker statements?
15:09:30 <eglynn> I can do it
15:09:45 <russellb> maksimov: Tuesday
15:09:45 <sandywalsh> eglynn, I think that's a better approach. A quick overview of architecture, highlighting where the major design discussions are talking place.
15:09:55 <maksimov> russellb: ty
15:09:55 <nijaba> eglynn: is that the FAQ
15:10:08 <eglynn> well both I guess
15:10:09 <sandywalsh> and, I'm a big fan of visuals/video
15:10:16 <eglynn> if we're agreed that's the way to go ...
15:10:19 <dhellmann> I have a new architecture diagram that I'm using in my pycon presentation, I'll add it to the wiki
15:10:25 <eglynn> cool
15:10:29 <jd__> is it me or I don't have the impression Heat did so much effort to convince :)
15:10:33 <dhellmann> #action dhellmann add new architecture diagram to wiki
15:10:34 <nijaba> dhellmann: neat
15:11:00 <eglynn> #action eglynn add bumper-sticker statements to wiki
15:11:13 <sandywalsh> I think we may be over thinking this and reading more into the delay than is really there. It was just due to time constraints. I think we're well on track.
15:11:20 <dhellmann> jd__: as eglynn pointed out, at least one member seems predisposed against us.
15:11:27 <jd__> sandywalsh: I agree
15:11:34 <jd__> that's my impression too as I hear you all! :)
15:11:49 <nijaba> jd__: +1
15:11:58 <jd__> dhellmann: that's the one that voted against Heat too, that doesn't surprise me
15:12:04 <dhellmann> jd__: right
15:12:12 <eglynn> yeap
15:12:13 <jd__> we aren't going to win this vote, let's move on ;)
15:12:19 <jd__> s/this/his/ :)
15:12:21 <sandywalsh> what's his objection?
15:12:23 <nijaba> jd__: I think he'd vote no to anything anyway
15:12:25 * russellb also thinks you're well on track fwiw :)
15:12:34 <jd__> nijaba: ya read my mind
15:12:39 <dhellmann> russellb: thanks!
15:13:14 * nijaba notes to write check to russellb ;)
15:13:19 <jd__> so let's not panic, enhance and polish things a bit and we're in :)
15:13:25 <jd__> nijaba: shhhht!
15:13:36 <dhellmann> jd__: +1
15:13:48 <eglynn> so beyond the improvements to the wiki discussed, any other prep we need to do prior to the TC meeting next week?
15:14:05 <jd__> push-ups?
15:14:22 <nijaba> #action nijaba to send a graduation email to the tc ml a few hours before the meeting, inviting to read the wiki
15:14:35 <sandywalsh> Perhaps ensure the BP's are on track for the release and the bug count is manageable
15:14:44 <sandywalsh> clean up any cruft in the pipe
15:14:59 <nijaba> #action jd__ to do 50 push-ups before the tc meeting
15:14:59 <eglynn> makes sense
15:15:02 <sandywalsh> underpromise overdeliver ... nice solide release
15:15:02 <dhellmann> sandywalsh: good ideas
15:15:08 <sandywalsh> *solid
15:15:10 <dhellmann> nijaba: how *are* we doing with blueprints?
15:15:17 <nijaba> dhellmann: next topic ;)
15:15:18 <notmyname> sandywalsh: his objection is that he's read claims that the metering is for billing info but the design seems to be for monitoring data. design-wise, you can't do billing usage info unless is can be recreated at a later arbitrary date from authoritative data (ie, you can't replay requests)
15:15:35 * dhellmann waits patiently
15:16:18 <sandywalsh> notmyname, gotcha ... we're adding all the stuff needed for SEC-compliant billing. It's a must have for us. Including double-entry accounting (which would include replay)
15:16:19 <nijaba> notmyname: thanks for the insight
15:17:00 <sandywalsh> notmyname, we do it now in stacktach and need to move all that functionality to CM
15:17:34 <nealph> notmyname: not sure if that equals a comment on underlying design or the robustness of implementation...
15:17:36 <notmyname> I don't know what double-entry accounting in the context of API requests is, but my general point is that 6 month's from now when I contest my bill, you can't reply all my 5GB PUTs to swift in order to get usage info
15:17:48 <nijaba> sandywalsh: non repudiation has been part of the req for ceilometer since day1, and transport is somewhat secured
15:18:22 <notmyname> also, emitting events to the network in the request flow seems frail (likely to lose events) as opposed to looking at log messages
15:19:00 <jd__> notmyname: I'll be able to tell you exactly when, what and where you PUT things with what size as it is implemented now
15:19:13 <sandywalsh> notmyname, very true, swift is certainly the elephant in the room. We're working with some of the logging-as-a-service guys to find a way to merge the two.
15:19:50 <eglynn> notmyname: is there a specific AMQP message-loss scenario you're concerned with?
15:20:09 <notmyname> sandywalsh: and of course swift is the part I'm thinking about most :-)
15:20:13 <sandywalsh> notmyname, we're hoping to use some of the UDP broadcasts as the secondary validation, but logging is the prime source. Not all those notifications will go directly into CM (i don't think)
15:21:04 <sandywalsh> notmyname, absolutely, it's the largest scale component of the problem. Chuck schooled us on the volumes you're dealing with.  :)
15:21:56 <nijaba> ok, I guess the point is well noted now. Shall we move on?
15:22:08 <dhellmann> +1
15:22:18 <jd__> let's go
15:22:21 <nijaba> #topic preparing for rc1
15:22:21 <notmyname> :-)
15:22:32 <nijaba> o today the g3 milestone proposed branch was created by ttx. He will turn it into grizzly-3 at the end of the day unless we push a bug to the grizzly-3 buglist. (let's hope not)
15:22:32 <nijaba> I had to push back on 3 blueprints though.  One of them being mostly a test (qpid) I automatically granted it an exception for rc1
15:22:32 <nijaba> We now have to vote on the other 2 for a Feature Freeze exception.  Emails were sent earlier for both on the Mailing list.
15:22:44 <nijaba> bp #1: hbase backend
15:22:44 <nijaba> #link http://lists.openstack.org/pipermail/openstack-dev/2013-February/005911.html
15:22:51 <sandywalsh> notmyname, would love to chat with you more about this ... it's a very important aspect of the solution.
15:23:12 <eglynn> I'm currently working on the qpid testing task
15:23:20 <nijaba> so, it looks to me like we are really close to a merge here, so I think it would be fair to grant an ffe for rc1
15:23:36 <maksimov> can i vote? :-)
15:23:48 <nijaba> anyone would like to have a formal vote?
15:24:05 <nijaba> or should we just grant the exception?
15:24:06 <eglynn> any need, are there objections?
15:24:06 <jd__> I don't mind
15:24:26 <jd__> I didn't review the code but since it's just an optional backend storage, I see no reason to refuse it
15:24:30 <llu-laptop> no objection.
15:24:31 <nijaba> waitaing 20 second
15:24:42 <eglynn> yea by acclamation!
15:25:00 <llu-laptop> b.t.w. Is maksimov and Minjie Shen(BP asignee) the same person?
15:25:14 <nijaba> #agreed ffe granted for hbase backend to be delivered in rc1
15:25:14 <maksimov> Shengjie Min :-)
15:25:16 <maksimov> nope
15:25:19 <nijaba> llu-laptop: good question ;)
15:25:19 <maksimov> two people
15:25:25 <jd__> llu-laptop: /whois :)
15:25:26 <nijaba> working together?
15:25:30 <maksimov> yep
15:25:36 <nijaba> sounded like it
15:25:56 <nijaba> moving on to next bp
15:25:59 <nijaba> bp #2 : publisher counters frequency
15:25:59 <nijaba> #link http://lists.openstack.org/pipermail/openstack-dev/2013-February/005912.html
15:26:01 <maksimov> woohoo
15:26:12 <nijaba> same status, afaict
15:26:24 <nijaba> any objections to the exception?
15:26:37 <eglynn> nope
15:26:45 <llu-laptop> nope either
15:26:50 <jd__> nop
15:26:53 <dhellmann> no objection to an exception
15:27:11 <dhellmann> although I opened 3 blueprints with ideas for cleaning things up after that change lands
15:27:33 <nijaba> #agreed ffe granted for publisher counters fequency to be delivered in rc1
15:27:41 <dhellmann> one would be a backwards-incompatible change to the plugin api, so we need to spend time thinking about how long we are going to support plugin apis like that
15:27:51 <dhellmann> we can do that later -- I expect we'll treat it like any other api
15:29:00 <nijaba> fyi, here is what we are delivering in g3:
15:29:03 <nijaba> #link https://launchpad.net/ceilometer/+milestone/grizzly-3
15:29:13 <nijaba> great job everyone!
15:29:26 <dhellmann> nice list!
15:30:13 <nijaba> here is what's in store for rc1:
15:30:18 <nijaba> #link https://launchpad.net/ceilometer/+milestone/grizzly-rc1
15:30:47 <nijaba> I hope weĺl all do a lot of testing on g3 to make sure we have a rock solid rc1
15:30:54 <eglynn> our second bug squashing day is coming up soon, right?
15:31:08 <dhellmann> yes, we should also look hard at our test coverage
15:31:09 <nijaba> march 4th.
15:31:16 <yjiang5> nijaba: when will the tree open for the ffe patches?
15:31:43 <nijaba> err, march 5th
15:32:05 <dhellmann> #info bug squash day scheduled for March 5th
15:32:09 <nijaba> yjiang5: it stays open as trunk.  we just branched of g3
15:32:20 <yjiang5> nijaba: got it.
15:33:11 <yjiang5> dhellmann: Possibly we need enable the code coverage?
15:33:24 <nijaba> note that core dev should STOP accepting any new feature for which an exception has not been granted.  we should be in bug fix only mode now
15:33:32 <dhellmann> yjiang5: I think there is a tox configuration for it, but jenkins is not using it
15:33:46 <nijaba> #info core dev should STOP accepting any new feature for which an exception has not been granted. we should be in bug fix only mode now
15:33:52 <dhellmann> nijaba: that's for trunk?
15:34:00 <yjiang5> dhellmann: ok, so that's same for all openstack project, right?
15:34:04 <dhellmann> or the pre-release branch?
15:34:11 <nijaba> dhellmann: I believe so, yes
15:34:13 <dhellmann> yjiang5: I'm not sure
15:34:17 <dhellmann> nijaba: ok, thanks for clarifying
15:34:20 <yjiang5> dhellmann: I remember the truck is freeze till RC1?
15:34:40 <nijaba> ttx: around to clarify?
15:34:40 <eglynn> the pre-release branch == milestone-proposed ?
15:34:54 <dhellmann> eglynn: yeah, that's what I meant
15:34:57 * ttx reads
15:35:20 <dhellmann> I wasn't sure if we'd branched to milestone-proposed for the release, or if trunk was going to become the release and we had to be more careful there.
15:35:21 <eglynn> IIRC milestone-proposed is usually cut just days before the upcoming release
15:35:23 <ttx> yeah, feature freeze applies until rc1 is produced
15:35:27 <dhellmann> ok
15:35:35 <ttx> at which point master branch opens for havana development
15:35:43 <ttx> and we pray that we don't need an rc2
15:35:49 <nijaba> thanks ttx!!
15:35:50 <ttx> (and fail)
15:35:50 <dhellmann> got it, thanks ttx
15:36:04 * nijaba prays the gods of free and open bits
15:36:12 <ttx> https://wiki.openstack.org/wiki/Release_Cycle
15:36:53 <eglynn> what's the approx date for RC1?
15:36:55 <nijaba> I think dhellmann wanted to bring something else up on the rc1 topic, but can't remmeber what
15:37:16 <nijaba> eglynn: march 14th
15:37:21 <dhellmann> nijaba: the nova notifier bug, but there's a solution for that in process now
15:37:41 <nijaba> see https://wiki.openstack.org/wiki/Ceilometer#Project agenda
15:38:03 <nijaba> #link https://wiki.openstack.org/wiki/Ceilometer#Project_Agenda
15:38:23 <nijaba> ok, anything else on the rc1 topic?
15:38:35 <dhellmann> not here
15:38:39 <yjiang5> Is it possible to add test case in rc1?
15:38:52 <nijaba> yjiang5: I think so, yes
15:38:59 <yjiang5> according to the Release_Cycle URL, only bug fixing allowed  :)
15:38:59 <dhellmann> yjiang5: yes, we need to improve our test coverage
15:39:00 <llu-laptop> yjiang5: unittest case?
15:39:02 <jd__> more tests? sure
15:39:08 <dhellmann> tests aren't production code
15:39:12 <jd__> but passing tests only!
15:39:18 <nijaba> jd__: lol
15:39:22 <maksimov> :)
15:39:23 <yjiang5> jd__: : )
15:39:23 <dhellmann> jd__: also useful tests only ;-)
15:39:29 <llu-laptop> yjiang5: or tempest?
15:39:31 <jd__> right :)
15:39:46 <yjiang5> llu-laptop: Yes, posslble tempest
15:39:59 <jd__> would be great
15:39:59 <eglynn> so the lack of tempest coverage was brought up at the first TC meeting
15:40:22 <eglynn> (1st meeting to consider graduation that is ...)
15:40:34 <eglynn> so yeah, that would be good
15:40:57 <dhellmann> yes, it would help protect us against incompatible changes in the parts of other projects we depend on
15:41:04 <nijaba> hehe
15:41:20 <dhellmann> notification formats, rpc serialization changes, etc.
15:41:45 <eglynn> a couple of reverts today on the RPC side
15:41:58 <nijaba> yup
15:41:59 <dhellmann> oh?
15:41:59 <eglynn> eagle-eyes from markmc ...
15:42:27 <eglynn> reverted first in olso, but we'd already sync'd up with the change
15:43:01 <llu-laptop> patch 22543 and 22544, but don't know the story behind the revert.
15:43:27 <eglynn> risky changes to the RPC envelope format IIRC
15:43:35 <dhellmann> eglynn: thanks for pointing those out, I'll revert them in our code, too
15:44:03 <ttx> nijaba: unless you place a bug on the grizzly-3 list in the next 5 hours, i'll go on and publish g3 as-is.
15:44:06 <eglynn> already done
15:44:15 <dhellmann> ah, ok
15:44:21 * dhellmann is behind on email
15:44:22 <eglynn> (by markmc)
15:44:38 <nijaba> ttx: ack
15:44:43 <jd__> tictac
15:45:19 <nijaba> ok, looks like we are done on this topic
15:45:27 <nijaba> #topic Open Discussion
15:45:38 <nijaba> anything, anyone?
15:46:14 <nijaba> tired?
15:46:15 <yjiang5> I possibly have not much network access and development access in next one and half weeks
15:46:35 <nijaba> yjiang5: going sailing?
15:46:36 <eglynn> new year?
15:47:01 <yjiang5> no, I'm relocating, and my development machine will be packaged and shift.
15:47:21 <nijaba> yjiang5: where to, if thatś not a secret?
15:47:26 <eglynn> 'course new year that was a few weeks ago ...
15:47:28 <llu-laptop> dhellman: yjiang5 would be in the same tz with yuu
15:47:30 <yjiang5> eglynn: We just finished chinese new year. CNY.
15:47:44 <llu-laptop> s/yuu/you/
15:47:50 <yjiang5> yes, I will go to california, and same tz with dhellmann.
15:47:59 <nijaba> yjiang5: going to portland or sc?
15:48:00 <dhellmann> yjiang5: no, I'm on the east coast
15:48:01 <dhellmann> closer though
15:48:08 <yjiang5> sc
15:48:19 <nijaba> yjiang5: nice!!
15:48:24 <dhellmann> dreamhost is in LA, but I'm remote
15:48:29 <dhellmann> Georgia
15:48:36 <yjiang5> dhellmann: got it.
15:48:45 <dhellmann> still, closer! :-)
15:49:28 <dhellmann> so about the backwards-incompatible change to the plugins…how do people feel about that? is that a rc1 change or havana?
15:49:43 <dhellmann> it's not really a new feature, but it would be a big change
15:49:48 <yjiang5> dhellmann: you mean the one of 1counter 1 pollster?
15:49:50 <dhellmann> yes
15:49:57 <jd__> I am pretty sure almost nobody wrote external plugins, so I don't care that much about compat at this point
15:49:57 * nijaba would tend to think havanah...
15:50:15 <eglynn> are there any "external" plugins in existence?
15:50:21 <eglynn> (that we know of ...)
15:50:21 <dhellmann> jd__: that's what I was thinking. If we wait for havana, we have to support the api. if we change it now can we get away with not doing that?
15:50:29 <dhellmann> eglynn: I have one here at dreamhost, but I can change it
15:50:30 <nijaba> yolanda was writing one, I think
15:50:33 <yjiang5> I'm not sure if we really need take that way, can we have more discussion on it?
15:50:54 <nijaba> yjiang5: discussion is ALWAYS welcome
15:50:55 <jd__> dhellmann: if the API wasn't released with Folsom, I think we can do whatever we want from my point of view
15:51:05 <dhellmann> yjiang5: we can, but we do need to get rid of that O(n^3) configuration loop and I think further simplifying the API gives us part of that along with some other nice benefits.
15:51:35 <dhellmann> jd__: we did have pollsters, but I don't think we were very formal about supporting that API. I wasn't sure if our incubation status changed the rules on that.
15:51:36 <yjiang5> but also lose some flexibility.
15:51:58 <dhellmann> yjiang5: I don't think we lose anything that we can't achieve in another way.
15:52:18 <jd__> dhellmann: I'm waiting to see people with that API used
15:52:21 <dhellmann> the abstraction is wrong right now, because I thought we would want to turn off sets of counters, not individual counters
15:52:47 <dhellmann> jd__: yeah, it's better to change it early and let it settle
15:52:58 <eglynn> if we're sure it needs to be changed, seems best to do that before G is tied down
15:53:15 <dhellmann> I'm sure. I guess I still need to convince yjiang5 :-)
15:53:22 <eglynn> no point in creating legacy issues for ourselves ...
15:53:46 <yjiang5> dhellmann: agree if we want to change API, ealier is better. But for this one, yes, I want more discussion :)
15:54:21 <dhellmann> yjiang5: ok. in the blueprint?
15:54:36 <yjiang5> sure. or IRC later.
15:54:57 <dhellmann> ok, today may be bad for sync communication for me since I'm actually in the office (a bit distracting)
15:55:14 <dhellmann> let's see, though, and move to the blueprint if it doesn't work
15:55:15 <yjiang5> ok. So I will comments on the blueprint.
15:55:17 <dhellmann> ok
15:55:58 <yjiang5> btw, any more comments to the publisher interval patch?
15:56:12 <dhellmann> yjiang5: I'm going to finish reviewing the latest version after our meeting
15:56:20 <yjiang5> dhellmann: thanks!
15:56:32 <dhellmann> I got about 1/2 way through before we started
15:57:07 <nijaba> anything else befvore I close the meeting?
15:57:12 <dhellmann> nope
15:57:33 <nijaba> Thanks everyone for another great meeting
15:57:42 <nijaba> #endmeeting