21:00:23 <jd__> #startmeeting ceilometer
21:00:23 <radix> thanks guys
21:00:24 <openstack> Meeting started Wed Sep 11 21:00:23 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:28 <openstack> The meeting name has been set to 'ceilometer'
21:00:44 <dhellmann> o/
21:00:48 <eglynn> o/
21:00:48 <thomasm> o/
21:01:10 <terriyu> o/
21:01:36 <jd__> #link https://wiki.openstack.org/wiki/Meetings/MeteringAgenda
21:01:38 <jd__> hi everyone
21:02:18 <sileht> o/
21:02:19 <jd__> #topic Review Havana RC1 milestone
21:02:25 <jd__> #link https://launchpad.net/ceilometer/+milestone/havana-rc1
21:02:53 <jd__> we still have 2 blueprints to merge
21:03:00 <jd__> that have been granted FFE
21:03:06 <eglynn> I'll have another iteration on the alarm service partioner tmrw or Friday
21:03:22 <eglynn> (busy this week so far with RDO testdays)
21:03:22 <jd__> the deadline has been set to next week to be /merged/ so that means everything should be submitted by the end of the week
21:03:32 <eglynn> k, understood
21:03:45 <dhellmann> I have time for reviews, but I've been going slow so I don't approve something against the feature freeze -- do we have a list of changesets that are OK to go in? is everything that's part of the freeze marked -2?
21:04:12 <jd__> dhellmann: if you're not sure just don't click on Approve
21:04:16 <dhellmann> k
21:04:18 <thomasm> I can do reviews as well
21:04:19 <sileht> jd__, I have restarted to work on the meta-alarm today I hope to send a new review of the api change tomorow
21:04:36 <jd__> dhellmann: otherwise if I see a bug number and that's a bug, I allow merge, otherwise, no
21:04:42 <jd__> sileht: cool
21:04:45 <dhellmann> makes sense
21:04:58 <eglynn> dhellmann: this one should be OK https://review.openstack.org/45244 to go ahead with
21:05:04 <jd__> we also need to go through the bug list and target the ones we want to fix by rc1 with the rc1 milestone in LP
21:05:11 <jd__> I might do that tomorrow if time allows
21:05:15 <dragondm> o/
21:06:47 <jd__> dhellmann: https://bugs.launchpad.net/ceilometer/+bug/1208365 is targeted at RC1 though you were not sure it was ok, if you've time, it'd be cool you check if we can merge the patch or not, and if we can't, remove the target on this bug
21:06:49 <uvirtbot> Launchpad bug 1208365 in ceilometer "Instance:<flavor> meter should be removed" [Low,In progress]
21:07:23 <jd__> and I think that's it for RC1
21:07:26 <jd__> questions anyone ?
21:07:37 <dhellmann> jd__: I'll take a look at that one
21:07:53 <jd__> dhellmann: thanks :)
21:07:55 <jd__> #topic Nova notifier plugin breaking devstack gate?
21:08:00 <dhellmann> I think we need that reset_on patch for the mongo driver
21:08:10 <jd__> #undo
21:08:11 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x321ad50>
21:08:22 <dragondm> bot fail.
21:08:27 <jd__> :-)
21:08:29 <thomasm> That's some helpful info ^^
21:08:31 <thomasm> =]
21:08:47 <jd__> dhellmann: oh you mean for the bug?
21:09:03 <jd__> dhellmann: I don't think so, but I'll let you dig into that
21:09:07 * dhellmann reaches for notes
21:09:13 <dhellmann> jog0 reported an issue with devstack gate for nova erroring out, possibly because of a timing issue introduced by the notifier plugin
21:09:18 <dhellmann> "It looks like nova-conductor stops receiving the 'conductor.service_update' command from nova-compute at some point, after which point nova-compute's heartbeat doesn't write to the DB"
21:09:24 <jd__> #topic Nova notifier plugin breaking devstack gate?
21:09:28 <dhellmann> #link https://bugs.launchpad.net/nova/+bug/1221987
21:09:31 <uvirtbot> Launchpad bug 1221987 in nova "compute node heartbeat out of sync causing scheduler to fail in devstack:  VMs fail to spawn" [Critical,Confirmed]
21:09:34 <dhellmann> we've scheduled a summit session to talk about the notifier in general
21:09:37 <dhellmann> #link http://summit.openstack.org/cfp/details/73
21:09:51 <jd__> cool
21:09:53 <dhellmann> jog0 wants to disable the notifier in the devstack gate
21:09:58 <jd__> not cool
21:10:03 <dhellmann> it seems like the problem is intermittent?
21:10:17 <dhellmann> it's not clear what's going on, the process just seems to stop logging or sending data for some reason
21:10:34 <sandywalsh> o/
21:11:15 <jd__> anyway I don't mind if it's removed from the gate, we'll dig up a solution to remove it entirely
21:11:35 <dhellmann> yeah, that's part of what that summit session will be about
21:11:51 <gordc> dhellmann: is this the reason some of the devstack tests fail occasionally?
21:11:52 <dhellmann> so should I tell jog0 to go ahead and remove the plugin from the devstack config in the gate?
21:11:57 <dragondm> looks like we jjust need a new notification in Nova.
21:12:10 <dhellmann> gordc: it seems to be related to one of many reasons, but no one can say for sure
21:12:19 <jd__> dhellmann: yes, we still have our unit tests anyway, that's all we had for a while anyway
21:12:25 <gordc> dhellmann: i see.
21:12:30 <dhellmann> jd__: ok
21:13:00 <jd__> anything else on that topic?
21:13:22 <jd__> #topic Release python-ceilometerclient?
21:13:25 <eglynn> hmmm, should we be removing the notification_driver from the config emitted by the puppet-ceilometer module also I wonder?
21:13:39 <jd__> haha, always one sec too soon
21:13:41 <jd__> #undo
21:13:42 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x332f1d0>
21:13:49 <eglynn> (or is the expectation that this is a transient issue that'll be fixed?)
21:13:58 <jd__> eglynn: I think it's a bug that should be fixed
21:14:04 <eglynn> jd__: cool
21:14:05 <jd__> if you want to be accurate about sampling, it's needed
21:14:13 <eglynn> yep, agreed
21:14:20 <sandywalsh> dragondm, +1 to a new notification
21:14:31 <jd__> we can't afford to block the entire dev process for this, so it's better to not bother everybody and disable it in the gate for now
21:14:42 <eglynn> +1
21:14:45 <dragondm> +1
21:14:58 <dragondm> we can fix later.
21:15:12 <thomasm> +1
21:15:24 <jd__> yes, though if we want to ship Havana bug free we should fix soon :-)
21:15:54 <jd__> anything else on that topic?
21:15:58 * jd__ waits 1 entire minute
21:16:19 * dragondm humms "jepordy" theme
21:16:21 <dhellmann> my vote would be to rewrite it to use the REST API now that we have one for publishing samples
21:16:42 <eglynn> dhellmann: hmmm, that's an idea
21:17:16 <dhellmann> that doesn't solve the "two versions of openstack common" problem, though
21:17:27 <eglynn> true
21:17:27 <jd__> that doesn't solve enough of the problem to me honestly
21:17:30 <dhellmann> so we may actually need to put the thing in its own package
21:17:38 <dhellmann> so it can be written by us, but just use nova code
21:17:47 <jd__> but I don't think I want to brainstorm right now about this neither
21:18:03 <dhellmann> yep
21:18:10 <eglynn> fair nuff
21:19:03 <jd__> #topic Release python-ceilometerclient?
21:19:14 <jd__> we still need to do this, but the needed patch has not been merged
21:19:19 <jd__> it seems we need more eyes
21:19:49 <dragondm> what's the patch?
21:19:53 <gordc> https://review.openstack.org/#/c/45076/
21:20:04 <gordc> i'm guessing...
21:20:17 * eglynn will have another look 1st thing tmrw
21:20:37 <gordc> really just choosing that one so i can pat myself on the back for reviewing it. :)
21:20:47 <sileht> jd__, after I have made change for this: https://wiki.openstack.org/wiki/Ceilometer/blueprints/alarm-api
21:21:06 <sileht> jd__, this meter_name field will be completly removed
21:21:21 <jd__> ah
21:21:46 <jd__> sileht: well we'll release after you/someone send a patch to ceilometerclient then?
21:22:48 <eglynn> may as well throw in the alarm history support in the client also in that case ...
21:22:50 <sileht> jd__, has you want, if we want have a ceilometerclient version that match the current API, we can release this now
21:23:04 <jd__> I don't really care
21:23:20 <dhellmann> if we know we're not going to release with that API, we probably shouldn't release a client that expects it
21:23:23 <jd__> we could almost push a release upon each merge
21:23:42 <jd__> dhellmann: I think h3 has been release with that API
21:23:45 <jd__> +d
21:24:02 <jd__> so if this patch got merge, we can release a client for h3
21:24:04 <dhellmann> does that mean we need to keep the argument in the client?
21:24:07 <jd__> then release a client for rc1
21:24:21 <jd__> dhellmann: why not, mapped to a no-op
21:24:34 <dhellmann> well, mapped to something that adds the appropriate value to the query list
21:25:18 <dhellmann> we need to maintain API compatibility between client releases, right?
21:25:27 <dhellmann> of the client's API, not just the server
21:25:44 <jd__> I thought sileht meant it was no useless, but whatever works
21:26:08 <sileht> sorry guys I need to go
21:26:09 <dhellmann> the argument is being removed as a stand-alone argument, with the expectation that the caller will pass it as part of the query
21:26:30 <jd__> hf sileht
21:26:35 <dhellmann> that makes the alarm query work more like the statistics and sample queries
21:26:35 <sileht> dhellmann, I think is not too hard to keep compatibility
21:26:38 <sileht> jd__, ^
21:26:47 <dhellmann> sileht: agreed, I just want to make sure that's what we do :-)
21:26:59 <jd__> fine with me :)
21:27:04 <sileht> I have already done same kind of code to convert old alarm in mongo
21:27:09 <dhellmann> ok
21:27:30 <sileht> bye see you later @all
21:27:38 <dhellmann> later, sileht!
21:28:07 <eglynn> sileht: 'night
21:28:25 <jd__> #topic Open discussion
21:28:58 <dhellmann> nick has a doc change that looks like it's got a few minor comments on it -- does anyone feel strongly that it can't merge as-is and have those changes come in a new changeset?
21:28:59 <dhellmann> #link https://review.openstack.org/#/c/44774/3
21:29:14 <dhellmann> gordc, I think the -1 is yours
21:29:16 <gordc> dhellmann: i'm fine with merging what stands.
21:29:58 <gordc> comments i made aren't showstoppers.
21:30:04 <dhellmann> ok, approved, thanks
21:30:20 <gordc> dhellmann: cool cool.
21:30:27 <nealph> other comments were mine...that's fine.
21:31:12 <eglynn> FYI decent enough validation of the havana-3 packaging of ceilo for Fedora & derivatives during the recent RDO testdays
21:31:22 <eglynn> #link http://openstack.redhat.com/RDO_Test_Day_September_2013
21:31:29 <dhellmann> eglynn: excellent!
21:31:33 <eglynn> funnily enough main niggles were with mongo
21:32:01 <eglynn> inordinately slow "service mongod start" on small resource-constrained installs
21:32:16 <eglynn> presumably because of the eager journal file prealloaction
21:32:34 <eglynn> either way, caused systemd timeouts for some users
21:32:35 <dhellmann> seems likely
21:32:41 <dhellmann> :-/
21:32:49 <eglynn> other than that, all goodness
21:33:12 <jd__> mongodb :/
21:34:03 <eglynn> my feelings precisely ... ;)
21:35:28 <jd__> closing in one minute :)
21:36:46 <jd__> #endmeeting