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