15:00:50 #startmeeting ceilometer 15:00:51 Meeting started Thu Jul 3 15:00:50 2014 UTC and is due to finish in 60 minutes. The chair is eglynn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:54 The meeting name has been set to 'ceilometer' 15:01:10 * cdent gets comfy 15:01:25 we're mostly at mid-cycle this week so this is gonna be a short meeting I guess 15:01:32 o/ 15:02:01 #topic Juno-2 status 15:02:33 so one change is that the javelin2 work is now slightly downgraded in terms of priority 15:03:09 javelin2 == "new resource-survivability-across-upgrades piece of the grenade harness" 15:03:34 eglynn: just about to ask what javelin2 :) 15:03:50 eglynn: cdent and I will work on it together next week. 15:03:53 llu-laptop: so cdent has found some incompleteness in it, and the os-qa have indicated that it's still should be considered WIP 15:04:35 but once we shake out the bugs/incompleteness in javelin2 itself, it'll still be a valuable thing 15:05:02 The main issue at this point is that though it is checked in, it is not actually being used in any official capacity yet. 15:05:09 So the fact it is otherwise broken is hidden. 15:05:17 (i.e. to allow for assertions that we have metric collection and ceilo-api queries spanning upgrades) 15:05:54 cdent: so we'll organize a g+ hangout / vline thingy next week with EmilienM to talk thru' the issues in detail 15:06:03 yup 15:06:09 any other changes for juno-2? 15:06:16 (that anyone wants to call out?) 15:06:39 how about https://review.openstack.org/#/c/102713/ 15:06:42 #topic "Spec proposal & acceptance deadlines are approaching" 15:07:52 so main thing here is the deadlines on spec proposal/approval for juno 15:07:54 see http://lists.openstack.org/pipermail/openstack-dev/2014-July/039201.html 15:08:08 proposal is to follow the neutron deadlines 15:08:21 I still miss the ceilometer/gnocchi spec I think (hint ildikov_) 15:08:27 hello :-) 15:08:37 so June 10 for proposal, Jun 20 for landing the spec for juno 15:08:40 jd__: challenge accepted ;) 15:08:48 eglynn: s/June/July/ I hope 15:08:56 jd__: yeap! 15:09:09 so Jul 10 for proposal, Jul 20 for landing the spec for juno 15:09:09 hehe, it'll be too cruel otherwise :D 15:09:20 "June for Juno" would have made sense though 15:09:25 could be a nice song 15:09:45 after that I guess just propose specs in a new k* directory? 15:10:04 k is still unnamed then? 15:10:15 my money is on kepler 15:10:18 cdent: ^^^^ 15:10:48 ok, so that's all from me ... end of monologue :) 15:11:00 #topic "open discussion" 15:11:16 oh I thought we were at that topic already 15:11:20 :D 15:11:21 Hi. I'm writing scenario test for events and I have a questions. 15:11:27 1. Events are disabled in ceilometer by default, is it better to enable them in ceilometer config or in devstack? 15:11:27 2. Making one action from some service is enough for event testing. But additionally I can test notification from different services by testing event from this service. Which is the best way? 15:12:15 asvechnikov: yep, events would have to be enabled ... however it would be best to delay landing that test until events are supported in mongodb 15:13:19 Hi. I found that "cpu time used" meter will be set to zero after VM restart, and that doesn't seem make sense to me. Is it designed so? 15:13:21 asvechnikov: so I guess you'll need to assert that the event is persisted *and* the expected traits also? 15:13:31 events are almost in mongodb https://review.openstack.org/#/c/101558/ 15:13:35 KurtRao: that's a "feature" of libvirt 15:13:43 idegtiarov: on my list :) 15:13:58 which means vsphere doesn't have this problem, right? 15:14:12 no idea 15:14:20 KurtRao: the cumulative CPU time is not a monotonic sequeunce in as reported libvirt, dunno about vSphere 15:14:39 KurtRao: can you test that and report back? 15:15:08 eglynn, yes traits too. 15:15:14 Sure. Actually I asked this because I cannot obtain a vSphere environment right now, but yes, I'll try :) 15:15:43 asvechnikov: cool, thanks! ... hopefully we'll get the mongodb patch landed soon also to unblock the tempest test 15:16:07 KurtRao: thank you sir! (... /me doesn't have access to a vsphere deployment either) 15:16:39 KurtRao: we can just try the mailing list :) first 15:17:02 KurtRao: there might be someone with some vsphere exp 15:17:07 ^_^ 15:17:08 shengjiemin: who not just reach out to the folks who wrote the vsphere inspector? 15:17:16 sure 15:17:22 shengjiemin: ... the git log knows all :) 15:17:39 eglynn: ^_^ 15:17:51 right 15:18:01 cool :) 15:18:17 shengjiemin: we were talking about your Zabbix patch earlier 15:18:34 shengjiemin: ... can you clarify one point? 15:18:38 eglynn: sure 15:18:50 shengjiemin: ... does Zabbix have a native store for metrics? 15:18:55 eglynn: sry being late today 15:19:12 eglynn: Is better to enable events in default ceilometer.conf? 15:19:12 shengjiemin: ... or is it all based on in-memory thresholding? 15:19:32 eglynn: yeah, it has a mysql db, it's meant for shor term real-time H/W monitoring 15:19:40 asvechnikov: we will probably do so when we switch to v3/gnocchi 15:20:08 shengjiemin: so "short-term" == "short retention of metric data"? 15:20:12 eglynn, and now to have all events tests passing? 15:20:20 eglynn: it's designed to wipe out the older data periodically 15:20:24 DinaBelova: are they failing now? 15:20:26 do we need to switch this on in the devstack? 15:20:33 well, they are not turned on :) 15:20:34 :D 15:20:40 DinaBelova: we will if there are tests requiring it 15:20:52 DinaBelova: ... but the default can still be to disable 15:20:58 asvechnikov is inplementing events tests 15:21:01 eglynn: yes to your question 15:21:03 scenario ones 15:21:18 so to test them we need them to be enabled in the testing env 15:21:31 shengjiemin: so the main point of your proposal is to gain longer-term retention? 15:21:43 eglynn - by default in ceilo config or in the devstack.. 15:21:59 DinaBelova: sure, that tempest test config can override the default config though, right? 15:22:23 asvechnikov, can it? ^_^ ^^^^ 15:23:03 eglynn: well, it's one part, it's more to get the existing zabbix metics not wasted there. Using Ceilo as the centralized place to store all the metrics 15:23:18 shengjiemin: so just to give you a flavour of some of the discussion on Zabbix ... the question of why burden the central agent with this additional polling was raised 15:23:35 shengjiemin: ... when the ceilometer central agent is still a SPoF 15:23:51 shengjiemin: (... i.e. can't be scaled out horizontally) 15:24:22 shengjiemin: ... anyhoo, probably best to continue the discussion on gerrit for posterity 15:24:31 eglynn: got your point, it doesn't need to go through central agent, does it? any suggestions? 15:24:59 shengjiemin: ... some of the folks here at mid-cyclewill leave further questions etc. on the review 15:25:25 eglynn: sure, i will take a look 15:26:01 shengjiemin: any suggestions ==> well you could just write a new custom agent specifically for this polling (that doesn't necesssarily need to live in-tree in the ceilometer repo) 15:26:11 but yeah, let's continue on gerrit 15:26:24 any other topics for open discussion? 15:26:47 * eglynn 's finger hovers over the endmeeting button ;) 15:27:42 right-o, thanks as always for the productive meeting ... 15:27:43 #endmeeting ceilometer