15:00:44 <jd__> #startmeeting ceilometer
15:00:45 <openstack> Meeting started Thu Sep  5 15:00:44 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:49 <openstack> The meeting name has been set to 'ceilometer'
15:00:52 <thomasm> o/
15:00:53 <dragondm> o/
15:00:57 <terriyu> o/
15:01:03 <eglynn> o/
15:01:16 <dhellmann> o/
15:01:23 <nealph> o/
15:01:32 <gordc> o/
15:01:41 <sileht> o/
15:01:42 <sandywalsh> o/
15:02:10 <jd__> o/
15:02:25 <jd__> #topic Review Havana-3 milestone
15:02:35 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-3
15:02:58 <jd__> if you followed the crazyness these last hours, so havana-3 is going to be out RSN
15:03:10 <jd__> the milestone-proposed branch has been cut
15:03:35 <jd__> all blueprints not completed that missed the deadline have been rescheduled for Icehouse
15:04:21 <jd__> in this great wisdom ttx granted use some FFE for the ongoing work for alarm-service-paritioner and alarming-logical-combination
15:04:22 <eglynn> possible to get a FFE for any of those?
15:04:34 <eglynn> yay!
15:04:36 <jd__> s/use/us/
15:04:48 <jd__> #link https://blueprints.launchpad.net/ceilometer/havana
15:05:01 <sandywalsh> what about the branches still under active review?
15:05:05 <jd__> quite a good score I'd say anyway
15:05:18 <jd__> sandywalsh: that'll go in master, which is now Icehouse
15:05:27 <eglynn> jd__: good negotiating!
15:05:28 <sandywalsh> k
15:06:57 <thomasm> jd__, What's the timeline for the bug fixes?
15:06:58 <ttx> jd__: s/great/infinite/ please
15:07:04 <jd__> :-)
15:07:27 <jd__> thomasm: if we want to get bugfixes in for H3 we have less than 24 hours I guess
15:07:39 <jd__> the rest will be for RC1
15:07:45 <thomasm> jd__, Good to know. Thanks. After this meeting I'll be putting up another review.
15:07:57 <russellb> jd__: btw, i don't think master is icehouse now, right?
15:08:12 <jd__> russellb: what is it?
15:08:15 <russellb> jd__: the current branching was just for a short term branch for havana-3, master is still havana
15:08:20 <russellb> until a stable/havana is cut around RC time
15:08:33 <russellb> ttx: ^ ?
15:08:39 <sandywalsh> that would make sense
15:08:58 <russellb> or at least that's how nova works ... assumed they were all the same model
15:09:01 <ttx> It's still very much havana
15:09:19 <jd__> ok so we have to hold patches for weeks until rc1?
15:09:23 <ttx> at this point, the idea is to come up with a definitive list of release blockers
15:09:30 <ttx> fix them all
15:09:31 <sandywalsh> so, no approvals on non-ffe branches
15:09:32 <russellb> jd__: yeah, and focus on bugs only
15:09:35 <ttx> then you cut your RC1
15:09:45 <jd__> russellb: ah I wish I could order people what to focus on ;)
15:09:47 <ttx> jd__: that can be tomorrow, if you're bug-free
15:09:58 <jd__> ok
15:09:58 <russellb> ttx: ah good point
15:10:15 <ttx> when we have an RC1, icehouse opens
15:10:19 <russellb> jd__: heh, no, but you can block the stuff they really want to work on and annoy them
15:10:28 <ttx> jd__: and if new bugs are uncovered we do a RC2 with backported fixes
15:10:38 <ttx> jd__: it's also to simplify not having to backport
15:10:47 <jd__> ttx: yeah I thought we'd do that right on milestone-proposed actually
15:10:57 <ttx> until you are done with the largest chunck of bugs
15:11:13 <ttx> no, the milestone-proposed branch we have now is just for havana-3
15:11:22 <jd__> k
15:11:27 <ttx> the "real" release branch will be cut just before rC1
15:11:37 <jd__> I'm just thinking about putting -2 on all patches basically now
15:11:46 <ttx> jd__: others do that
15:11:46 <russellb> jd__: that's what i did this morning
15:12:02 <jd__> yeah makes sense, though that seems like a heavy burden especially for nova
15:12:10 <jd__> well I'll do that then
15:12:27 <jd__> not the right time to debate around this anyway :)
15:12:33 <russellb> yeah ... and i'll rely on the patch authors to chase me down to take the -2 off later
15:12:34 <ttx> jd__: if there is a specific feature you want to work on and start landing... we can always do a feature branch. But that's a bit heavy for two weeks
15:12:53 <jd__> ttx: yeah, we won't do that I guess :)
15:13:09 <jd__> questions anyone?
15:13:22 <ttx> jd__: so at this point you should rather come up with an RC1 buglist
15:13:29 <ttx> and spread the load around
15:13:34 <eglynn> so for a patch that's currently merging as we speak
15:13:46 <eglynn> should I backport to milestone-proposed?
15:13:57 <ttx> eglynn: only if it's milestone-critical
15:14:06 <eglynn> ttx: k
15:14:09 <ttx> otherwise just let it live in master
15:14:17 <eglynn> (it's not, so I will ...)
15:14:26 <ttx> it will be included in RC1
15:14:29 <eglynn> cool
15:15:25 <jd__> #topic State of DB2 driver
15:15:37 <jd__> #link https://bugs.launchpad.net/ceilometer/+bug/1208547
15:15:40 <uvirtbot> Launchpad bug 1208547 in ceilometer "resource metadata not reflecting actual state of resource" [Medium,In progress]
15:15:54 <jd__> dhellmann: do you want to introduce this topic?
15:16:20 <dhellmann> we had some issues with the way the drivers were returning resource metadata
15:16:34 <dhellmann> thomasm was working on the fix, but didn't know quite what to do with the db2 driver
15:16:55 <dhellmann> the proposed solution was to raise NotImplementedError in get_resources() to indicate that the results were wrong
15:17:08 <dhellmann> I objected, on the grounds that it made the driver entirely unusable
15:17:53 <dhellmann> we discussed it on IRC for a bit, but I don't think we resolved it, and that's why we wanted to talk about it with the rest of the group
15:18:13 <thomasm> litong submitted a fix for it
15:18:17 <dhellmann> thomasm: did anything happen on that after our chat?
15:18:19 <thomasm> and it's passing the tests
15:18:20 <dhellmann> ok, good
15:18:20 <thomasm> yep
15:18:33 <dhellmann> so the bigger question, then, is what to do for these cases in the future
15:18:34 <thomasm> He said it works for both the mongo test backend and DB2
15:18:36 <dragondm> Crisis averted :>
15:18:43 <sileht> dhellmann, db2 have some exception in test too: https://github.com/openstack/ceilometer/blob/master/tests/storage/test_storage_scenarios.py#L210
15:18:45 <thomasm> dragondm, yep!
15:18:46 <dhellmann> my opinion is it's better to document a bug than to completely break a driver
15:18:47 <gordc> dhellmann: yep, litong is actively looking at any db2 bug that comes up.
15:19:01 <dhellmann> and of course fix them :-)
15:19:12 <litong> @dhellmann, yeah.
15:19:22 <gordc> dhellmann: agreed.
15:19:31 <thomasm> The biggest problem I saw was communication.
15:19:43 <thomasm> I misquoted litong because I misunderstood what he was trying to tell me.
15:20:13 <thomasm> litong, and that caused us to make a decision that we otherwise probably wouldn't have made.
15:20:15 <litong> Thomas and I had a phone conversation and the issue was resolved.
15:20:23 <dhellmann> thomasm: was that regarding the "we're not sure if db2 can do this" statement?
15:20:28 <thomasm> correct
15:20:43 <dhellmann> ok, well, it's good that's resolved :-)
15:21:08 <dhellmann> I like using NotImplementedError for specific sub-cases, like group by or filter queries that are just not implemented yet
15:21:09 <thomasm> When litong had stated that we can't do it, I thought he meant overall we couldn't with the current DB2 features. But what he meant was that we couldn't have aggregate function parity with the mongo driver.
15:21:19 <dhellmann> that lets the caller know, some parts of this API don't work with the backend
15:21:22 <litong> @dhellmann, doug, yeah, as long as we can understand each other, we can always find a solution.
15:21:27 <dhellmann> but I don't like blocking off an entire API call
15:21:48 <dhellmann> so I just wanted to see if the group felt otherwise, or if that's what we'll plan to do in the future?
15:21:57 <eglynn> yep NotImplementedError should be resolved as an initial placeholder in some drivers for a new feature
15:21:58 <litong> @dhellmann, totally agreed.
15:22:13 <dhellmann> eglynn: right, new features are a special case, too
15:22:16 <eglynn> (not to disable an existing partially broken feature)
15:22:19 <eglynn> yep
15:22:21 <dhellmann> so new features, or sub-features of an API
15:22:21 <sandywalsh> we could start thinking about versioning of db drivers
15:22:28 <sileht> I guess we need something to explain limitation/feature implementation of each backend
15:22:33 <dragondm> I'd suggest some way of marking a driver method that is semi-broken.
15:22:37 <dhellmann> sandywalsh: that's probably a good idea for a summit talk for icehouse
15:22:40 <thomasm> dragondm had a great idea for experimental drivers
15:22:41 <eglynn> s/resolved/reserved/
15:23:04 <sandywalsh> dhellmann, are we writing down all these summit talk ideas? :)
15:23:06 <dhellmann> sileht: I have handled that in the past by having the plugin implement a get_features() call that returns a set of enum values
15:23:08 <gordc> a side question, since we have a bunch of backends now, i assume no one is an expert in all of them. should we have a place to find maintainers for backends?
15:23:12 <dhellmann> sandywalsh: not it
15:23:26 <thomasm> Where if we wanted to allow organic growth of an experimental driver in the master branch we'd need something to delineate between stable and not-so-stable drivers.
15:23:29 <dragondm> gordc: yup
15:23:30 <jd__> gordc: I was thinking about a MAINTAINERS file ala oslo
15:23:34 <dhellmann> gordc: yes, definitely a good idea -- a file like -- exactly
15:23:59 <thomasm> gordc, +1
15:24:01 <sileht> +1 for MAINTAINERS file
15:24:07 <sandywalsh> dhellmann, a Facet pattern works well there. Versioning would even be better
15:24:09 <eglynn> would the maintainer be responsible for porting new features to their backend?
15:24:10 <dhellmann> gordc, want to start that?
15:24:14 <sandywalsh> maintainers +1
15:24:17 <llu-laptop> +1 for MAINTINERS file
15:24:23 <dhellmann> eglynn: or at least helping with someone else who wanted to do the work
15:24:27 <gordc> dhellmann: yeah i'll do that. i think it'll be helpful
15:24:32 <eglynn> dhellmann: cool, that's fair
15:24:33 <litong> @jd__, @gordc, for /storage directory.
15:24:48 <sandywalsh> should there be a minimum number of maintainers on a feature?
15:24:57 <dhellmann> sandywalsh: versioning gets us part way, but doesn't let us inspect a given driver to see what it does. I'm not familiar with "Faceting" so I'll have to look that up
15:24:57 <gordc> anyone want to be considered an expert and own a backend? :)
15:24:59 <litong> for any other stuff? publisher, dispatchers?
15:25:10 <dhellmann> #action gordc to create MAINTAINERS file for storage drivers
15:25:22 <jd__> nice play dhellmann
15:25:25 <jd__> :-D
15:25:28 <thomasm> lol
15:25:32 <sandywalsh> events
15:25:37 * dhellmann has learned much about delegation over the last 6 monghts
15:25:39 <sandywalsh> alarms
15:25:40 <eglynn> alarms
15:25:43 <eglynn> snap ;)
15:25:50 <litong> oh, boy,
15:25:51 <sandywalsh> (just listing things that need maintainers)
15:25:58 <dragondm> dhellmann, sandywalsh: I'd suggest an '@experimental' decorator that can flag such.
15:26:10 <sandywalsh> trigger pipeline, meter pipeline
15:26:19 <sandywalsh> http stack
15:26:24 <gordc> sandywalsh: i'll add events to maintainers file and add your name.
15:26:26 <jd__> I think it's fair enough to ask the guys in MAINTAINERS to take a look at a patch and to implement/fix the code like litong did
15:26:26 <sandywalsh> (or would that be oslo)
15:26:34 <dhellmann> gordc: put me down for the API stack
15:26:43 <gordc> dhellmann: will do
15:26:49 <dragondm> I'll be happy to fix events stuff too.
15:27:02 <dhellmann> we can all add ourselves to the file, too, once gordc creates it
15:27:11 <dhellmann> I think that wraps up that topic, jd__
15:27:14 <gordc> dragondm: done.
15:27:21 <jd__> ack
15:27:28 <jd__> #topic Release python-ceilometerclient?
15:27:29 <eglynn> rely on a convention that the appropriate mantainer is always added as a reviewer on paches that touch their area?
15:27:36 <eglynn> (but doesn't get a veto ...)
15:27:41 <jd__> eglynn: yes
15:27:48 <eglynn> cool
15:28:03 <jd__> we need to release ceilometerclient as soon as https://review.openstack.org/#/c/45076/ gets merged
15:28:07 <eglynn> the alarms s/counter_name/meter_name/ patch will need releasing soon
15:28:16 <eglynn> yep
15:28:24 <jd__> I guess I'll do that :)
15:28:31 <sandywalsh> I'd like to see ceilometer lead the way on a self-describing api (kind of like a richer-wsdl) so the client would auto-update.
15:28:46 <jd__> sandywalsh: that'd be awesome
15:28:53 <sandywalsh> the client could be completely data-driven
15:29:11 <eglynn> that would be cool
15:29:11 <jd__> maybe WSME can help us generating WSDL like specs
15:29:18 <jd__> s/maybe/verryyy likely/
15:29:19 <sandywalsh> yep
15:29:23 <eglynn> avoid a lot of boilerplate patches to the client
15:29:43 <jd__> sandywalsh: if guess that makes you up for creating a blueprint to work on that? ;-)
15:29:44 <dragondm> Data driven client would be nice.
15:29:48 <dhellmann> how would a consumer of the client code know what the API is?
15:29:50 <sandywalsh> jd__, np
15:30:04 <sandywalsh> dhellmann, autogenerated docs
15:30:18 <dragondm> (saying 'wsdl' brings back bad memories.. :P)
15:30:22 <dhellmann> let's not re-invent soap
15:30:27 <eglynn> LOL :)
15:30:28 <jd__> next, how do we autogenerate Ceilometer's code from our brains?
15:30:32 <sandywalsh> wsdl won't do it, there are alternatives
15:30:50 <dhellmann> jd__: I have a brain-compute interface called "keyboard" that works pretty well
15:31:03 <sileht> ahah
15:31:37 <jd__> dhellmann: I should try that, these punch cards really slow me down
15:31:40 <sandywalsh> termie did some good work on this scheme in the early nova days
15:31:49 <dhellmann> jd__: indeed
15:32:24 <sandywalsh> bourbon-driven development
15:32:49 <jd__> hmmm
15:32:59 <jd__> #topic Open discussion
15:34:52 * terriyu is looking forward to getting some sleep after havana-3
15:35:38 <dhellmann> :-)
15:37:04 <jd__> so calm
15:37:20 <jd__> I'm almost done -2'ing everything in the queue while you're chatting
15:37:42 <jd__> while I'm at it
15:37:44 <thomasm> fun fun
15:37:49 <terriyu> btw guys, I got a travel grant to go to the Hong Kong Summit!!
15:38:01 <jd__> congrats terriyu :)
15:38:18 <eglynn> terriyu: nice work!
15:38:21 <terriyu> I'll get to meet you and hear your voices, instead of imagining them over IRC :)
15:38:33 <jd__> not sure it's a win? ;)
15:38:48 <llu-laptop> jd__: when will the master be available for accpeting patches again?
15:38:53 <jd__> btw I'm going to continue working on better and more gate jobs; devstack should run now (or in a few hours) on all patches
15:38:58 <jd__> llu-laptop: after rc1
15:39:06 <jd__> llu-laptop: if I got things right :))
15:41:49 <jd__> I don't want to interrupt but I'll close the meeting in a minute
15:42:27 <jd__> #endmeeting