15:00:25 <jd__> #startmeeting ceilometer
15:00:26 <openstack> Meeting started Thu Mar 21 15:00:25 2013 UTC.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:29 <openstack> The meeting name has been set to 'ceilometer'
15:00:38 <jd__> hi everyone
15:00:44 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
15:01:12 <yjiang5> o/
15:01:16 <eglynn> o/
15:01:17 <graflu0> o/
15:01:19 <llu-laptop> o/
15:01:20 <fnaval> o/
15:01:22 <apmelton> o/
15:01:23 <zehndton> o/
15:01:25 <nealph> o/
15:01:26 <DanD> o/
15:01:37 <maksimov> o/
15:01:47 <jd__> that's a lot of people!
15:02:01 <shengjie_> o/
15:02:13 <jd__> nijaba around?
15:02:29 <danspraggins> o/
15:02:34 <jd__> dhellmann might be sick fwiw
15:02:41 <jd__> #topic dhellmann investigate the process for releasing a client library
15:02:56 <jd__> so I'm going to re-action this
15:03:03 <jd__> #action dhellmann investigate the process for releasing a client library
15:03:07 <dragondm> o/ hello
15:03:21 <pvo> o/
15:03:28 <jd__> #topic Summit sessions http://summit.openstack.org/
15:03:39 <jd__> We should have ~11 sessions planned on the end of week. I've asked if
15:03:39 <jd__> possible to not overlap with Heat so we can share the people between the
15:03:39 <jd__> two sessions if needed.
15:04:04 <jd__> Also I've started to do the planning, didn't finish yet, but every session should fit, with some merge, so far
15:04:19 <eglynn> jd__: were we allocated a definite day for the ceilo track?
15:04:26 * eglynn heard Thursday
15:04:30 <jd__> eglynn: Thursday indeed
15:04:37 <jd__> and a bit of Wednesday end-of-afternoon
15:04:39 <llu-laptop> when can we see the initial schedule?
15:04:50 <jd__> llu-laptop: soon I think
15:05:00 <eglynn> kinda the graveyard shift
15:05:15 <eglynn> (the later slots on Thurs afternoon)
15:05:16 <jd__> eglynn: if you've more insight about which alarming session could be merged, that would be great
15:05:44 <jd__> eglynn: ah? because everybody left?
15:06:00 <eglynn> jd__: yep
15:06:04 <eglynn> jd__: and yep as well
15:06:12 <eglynn> jd__: I've 5 sessions proposed ... if there a target number I should aim for?
15:06:40 <jd__> eglynn: 3 would be perfect, I can maybe make 4 -- there's 5 from you and one from Nick too
15:07:17 <eglynn> jd__: cool, I'll take another pass at them and aim for amalgemating to 3
15:07:44 <jd__> eglynn: perfect, ping me when you do or will have done that so I can finish my scheduling
15:07:53 <eglynn> jd__: will do
15:08:03 <jd__> cool
15:08:20 <jd__> that's all for me about this, anybody else wants to add something?
15:08:21 <eglynn> #action eglynn amalgemate summit alarming proposals from 5 sessions to 3
15:08:51 <jd__> ah yes, I need to ask Nova folks about the Cell session
15:08:58 * eglynn can't spell amalgamate ...
15:08:59 <jd__> nijaba proposed a session about that, but I feel that it's useless
15:09:13 <eglynn> one other idea on summit sessions
15:09:15 <llu-laptop> also about the nova scheduler?
15:09:16 <jd__> maybe I'm wrong, so I'll ask nova
15:09:36 <eglynn> if we're really stuck for slots, we could move some sessions out to the "unconference track"
15:09:41 <jd__> llu-laptop: I plan to use a session on this, your thoughts?
15:09:43 <eglynn> (or whatever that's called ...)
15:10:03 <jd__> eglynn: good idea
15:10:16 <yjiang5> jd__: +1 for nova scheduler. But we need nova guys on the session also, right?
15:10:20 <jd__> eglynn: I'll drop the low prio session to this ultimately if I've too :)
15:10:27 <llu-laptop> jd__: i'm wondering if there are some nova guys attend that session?
15:10:28 <eglynn> jd__: cool
15:10:29 <jd__> yjiang5: yes but nova is booked for 4 days so…
15:10:56 <eglynn> we may need to actively grab nova folks if we want them to attend
15:11:00 <jd__> as said, I've managed to move Heat away so it is not during our sessions so we can enjoy them
15:11:05 <jd__> but for nova that's impossible :)
15:11:19 <jd__> maybe we should propose the nova-scheduler/ceilmoeter session into nova schedule?
15:11:24 <dragondm> Some of us involved in both will be bopping back & forth as possible...
15:11:37 <jd__> dragondm: sounds like sport! ;)
15:11:44 <dragondm> Pretty much.
15:11:57 <yjiang5> jd__:  +1 for into nova scheduler.
15:12:14 <eglynn> jd__: yep, we certainly could ... russellb already put out a call for early nova proposals on the ML
15:12:15 <dragondm> Basic law of conferences: everything you want to attend is schedualed at the same time.
15:12:28 <jd__> hehehe
15:12:46 <eglynn> (so the earlier we re-assign to nova, the better ...)
15:13:16 <jd__> #action jd__ Ask Nova team is a session talking about Ceilometer/Cell is worth it
15:13:23 <eglynn> BTW the session proposer can't re-assign topic, only the track "owner"
15:13:34 <jd__> #action jd__ Propose a session into Nova timeslots about Ceilometer being use by nova-scheduler
15:13:58 <jd__> eglynn: ah right
15:14:01 <jd__> I can do that right now
15:14:06 <eglynn> cool
15:14:44 <jd__> http://summit.openstack.org/cfp/details/64 done
15:14:53 <eglynn> IIRC from the last summit, some of the yahoo! folks had an interest in the nova scheduler consuming & doing analytics on metering data
15:15:01 <jd__> if it's not approved we'll bring to the unconference I guess?
15:15:18 <eglynn> yep, makes sense
15:15:52 * jd__ moves his little organization papers
15:16:00 <jd__> more slot for alarming and stuff then :)
15:16:09 <eglynn> coolness
15:16:32 <hanney> o?
15:17:20 <jd__> anything else?
15:17:47 <eglynn> now that the party schedule is out, any ideas on a good night for a team dinner?
15:18:27 <jd__> maybe Wednesday between our sessions?
15:18:53 <eglynn> #link http://openstacksummitapril2013.sched.org/
15:19:03 <eglynn> Wednesday's good
15:20:00 <shengjie_> +1 Wednesday
15:20:06 <jd__> well I suggest we ask others next meeting too but that could work
15:20:12 * jd__ is flexible anyway
15:20:32 * jd__ 's schedule is flexible anyway (hm)
15:20:40 * eglynn flexible too, except for Monday evening ... (Red Hat party)
15:20:59 <jd__> eglynn: ok
15:21:20 <jd__> #topic DIY stable/grizzly maintenance (since the stable-maint team won't be supporting the newly integrated projects until post-havana)
15:21:33 <jd__> eglynn: we're listening :)
15:21:35 <eglynn> OK so the motivation for this topic was a conversation on openstack-stable-maint ML ysterday
15:21:44 <eglynn> the subject was membership of the stable-maint team for grizzly
15:21:55 <eglynn> (core PTLs and active back-porting developers are normally included)
15:22:05 <eglynn> folks with a hand in downstream distros etc.
15:22:15 <eglynn> so I suggested also including the incoming PTLs for ceilo & heat
15:22:36 <eglynn> turns out that the stable-maint team is *not* going to be supporting ceilo & heat for the upcoming cycle
15:22:48 <eglynn> (since the project wasn't actually integrated for the grizzly cycle)
15:22:59 <eglynn> so the short story is ... if we want it done, we'll have to support it ourselves
15:23:27 <eglynn> I, for one, would be in favour of investing (as a project) in stable branch maintainence
15:23:31 <jd__> we can do that, but it'd be cool to do this close the actual stable-maint team
15:23:39 <eglynn> yep
15:23:41 <jd__> like if we were integrated
15:24:12 <llu-laptop> what kind of work it involves?
15:24:12 <eglynn> its a good way of supporting non-trunk-chasing users *and* developing good team practices for the I cycle
15:24:13 <jd__> the fact that they don't want to be responsible for it, I can understand, but if we can at least just do the job for them without setting up a different process, it'd be great
15:24:30 <jd__> and llu-laptop is already volunteering!
15:24:37 <eglynn> here's what I think would we'd need to do ...
15:24:39 * jd__ hides
15:24:54 <eglynn> (a) familiarize ourselves with the current policy
15:25:02 <eglynn> #link https://wiki.openstack.org/wiki/StableBranch
15:25:09 <eglynn> note especially https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes
15:25:14 <eglynn> that's the key IMO
15:25:25 <eglynn> (b) get the remote stable/gizzly branch cut
15:25:35 <eglynn> not sure what level of karma is required to get that done?
15:25:53 <eglynn> (c) commit to watching out for and backporting *appropriate* fixes
15:26:01 <eglynn> that's an on-going "collective responsibility" task
15:26:18 <eglynn> translation: it'll fall thru' the cracks unless we all do it ;)
15:26:29 <eglynn> made more tractable with tagging ... https://wiki.openstack.org/wiki/StableBranch#Bug_Tags
15:26:35 <jd__> but will we able to do 'git review stable/grizzly'?
15:26:46 <jd__> that's (b)?
15:26:54 <eglynn> and of course considering your own patches as a matter of course makes it easier
15:27:11 <eglynn> git review just requires the branch exists upstream?
15:27:19 <eglynn> or something more?
15:28:27 * eglynn is old-skool, doesn't usually use git-review ...
15:28:29 <jd__> eglynn: I think so yeah
15:28:48 <eglynn> k, so I'll follow up on what's needed there
15:28:51 <jd__> so that might be tight to (b)
15:28:56 <eglynn> yep
15:28:57 <jd__> thanks eglynn
15:29:18 <eglynn> and finally (d) manage the stable releases
15:29:21 <jd__> I think (c) will be visible in our Gerrit dashboard, so I am not too much afraid of us forgetting it
15:29:33 <jd__> for the part submitted I mean
15:29:49 <eglynn> yep, so the key separating the sheep from the goats ;)
15:29:57 <jd__> :)
15:30:19 <eglynn> i.e. deciding which bugs are suitable for backporting, tagging in LP kinda helps there
15:30:31 <jd__> eglynn: yeah, I was wondering if LP could help about this
15:30:48 <jd__> but I'm not sure reporters can say in which version they found the bug, at least via a special field
15:31:14 <llu-laptop> eglynn: that requires every gerrit patch should have a LP bug/blueprint, I guess?
15:31:29 <eglynn> the stable-maint team will be using tags like "grizzly-backport-potential"
15:31:34 <shengjie_> eglynn: does that decision of what bugs get ported made by the LP or there is a triage process?
15:32:13 <jd__> eglynn: well that requires to know that the bug reported is not from havana version :/
15:32:18 <eglynn> shengjie_: LP just allows anyone (the original fixes, or an interested core dev) to mark as bug as a good candidate for backporting
15:32:27 <eglynn> s/fixes/fixer/
15:32:40 <shengjie_> then the decision is gonna be made by LP
15:32:48 <shengjie_> porting it or not
15:32:54 <shengjie_> ?
15:33:05 <eglynn> well ... s/made by LP/recorded in LP/
15:33:24 <eglynn> the decision point is usually not when the bug is originally reported in LP
15:33:36 <eglynn> as the invasiveness of the fix is unknown at that point
15:33:43 <jd__> (we all agree that LP is Launchpad, right? :)
15:33:47 <eglynn> yep
15:34:06 <jd__> I was just under the impression shengjie_ was understanding something else :)
15:34:22 <eglynn> the decision point is usually when the fix is proposed to or lands on master
15:34:42 <eglynn> then it's usually clear whether it too risky or appropriate for the stable branch
15:34:43 <jd__> eglynn: that seems like a very fragile process but it's probably the best we can have for now
15:35:05 <eglynn> jd__: yep, it takes vigilence to ensure nothing falls thru the cracks
15:35:52 <eglynn> so first step would be everyone proposing fixes, to take a few minutes to think about whether the patch is suitable for stable
15:36:01 <eglynn> and then record that info in LP via the tag
15:36:15 <eglynn> you don't necessarily need to do the backport yourself
15:36:20 <eglynn> though that would be good
15:36:28 <eglynn> (as you'd be most familiar with the fix ...)
15:36:35 <shengjie_> who does the cherrypicking then?
15:36:56 <jd__> eglynn: and the usual process (for H) will be stable-maint to watch for us what should be backported?
15:37:08 <eglynn> shengjie_: if not the original proposer, then someone else on core will have to step up to the plare
15:37:12 <jd__> not sure what job we'll do in place of stable-maint
15:37:22 <eglynn> jd__: yes, that would be the process during the I cycle
15:37:28 <eglynn> s/plare/plate/
15:37:32 <jd__> eglynn: k
15:38:09 <eglynn> but note that stable-maint won't do all the heavy lifting for us, even in the I cycle
15:38:25 <jd__> that's clear to me, eglynn, #action some stuff if you think you need to
15:38:42 <jd__> eglynn: yeah I though so :)
15:38:53 <eglynn> #action eglynn get ceilo:stable/grizzly branch set up
15:39:07 <eglynn> one other thing to think about is the cadence of stable releases
15:39:20 <eglynn> nova etc. usually aim for every 8-10 weeks
15:39:44 <eglynn> we could line up with that, or aim for less frequent if appropriate ...
15:40:33 <eglynn> that's all I got on the topic ...
15:40:56 <jd__> that's a good start!
15:41:02 <jd__> to be continued
15:41:05 <eglynn> cool
15:41:13 <jd__> #topic Open discussion
15:41:31 <jd__> can I have more reviews on my old patches laying around?
15:41:33 <llu-laptop> one question, how many stable version should we keep? Say we'in I, do we have stable/g and stable/h both?
15:41:55 <jd__> llu-laptop: I think we'll follow others on that
15:42:17 <eglynn> llu-laptop: rule is one cycle back for normal fixes
15:42:30 <eglynn> llu-laptop: longer than that, security vulnerabilities only
15:43:34 <eglynn> (so after grizzly goes out, stable/folsom will usually only get security fixes as a matter of course, though the distro folks will probably support it for longer ...)
15:44:00 <zul> rc1 is giong to be out when for ceilometer?
15:44:50 <eglynn> #link https://launchpad.net/ceilometer/+milestone/grizzly-rc1
15:45:03 <zul> cool thanks
15:45:49 * ttx waves
15:45:52 <jd__> not sure when exactly
15:46:06 <ttx> jd__: would be great to close those last blockers
15:46:15 <jd__> ttx: we can do that
15:46:30 <ttx> jd__: everyone else will have their rc1 done this week
15:46:39 <jd__> ttx: we close everything and I ping you back?
15:47:07 <ttx> You fix everything on the list, then when you're happy with it... just push a 2013.2 version change in setup.py and pingme
15:47:17 <ttx> I'll cut the grizzly release branch from the previous commit
15:47:33 <ttx> jd__: but that means you truly believe that it's good enough to release
15:47:50 <ttx> jd__: i.e. pending the discovery of new bugs, it will be your release
15:47:58 <jd__> ttx: ok!
15:48:09 <ttx> (that said, incubated projects have less constraints)
15:48:16 <ttx> (like, you don't HAVE TO release on April 4)
15:48:25 <jd__> but we'd like to! ;)
15:48:30 <ttx> just makes you look good :)
15:48:37 <jd__> we like that
15:48:46 <eglynn> yep, lets aim to line up with the train
15:49:02 <jd__> ok so tomorrow I'll spend my day on that
15:49:08 <jd__> that means we need more reviews too
15:49:46 * dragondm is happy to do a few...
15:49:51 <llu-laptop> I'll do the review tomorrow.
15:50:16 <jd__> thanks llu
15:50:23 <gordc> jd__ if i can understand it, i'll review it (ceilometer newbie) :)
15:50:36 * eglynn will focus also on bug fixing & reviewing for the rest of the week ...
15:53:12 <llu-laptop> Are we required to resolve bug 1093625 in RC1?
15:53:14 <jd__> thanks guys
15:53:14 <jd__> anything else or should I close this meeting?
15:53:14 <uvirtbot> Launchpad bug 1093625 in ceilometer "no metaquery implementation in sqlalchemy DB backends" [Medium,Confirmed] https://launchpad.net/bugs/1093625
15:53:15 <jd__> #endmeeting