Tuesday, 2014-05-06

boris-42ildikov ping00:02
*** _cjones_ has quit IRC00:27
*** fnaval has joined #openstack-ceilometer00:39
*** liusheng has quit IRC01:01
*** shakamunyi has joined #openstack-ceilometer01:05
*** shakayumi has joined #openstack-ceilometer01:16
*** shakamunyi has quit IRC01:18
*** liusheng has joined #openstack-ceilometer01:19
*** thomasem has quit IRC01:24
*** thomasem has joined #openstack-ceilometer01:59
*** julim has joined #openstack-ceilometer02:08
*** yjiang5 is now known as yjiang5_away02:15
*** julim has quit IRC02:25
*** fabio has quit IRC02:26
*** shakayumi has quit IRC02:58
*** Qiming has joined #openstack-ceilometer03:13
*** fnaval has quit IRC04:56
*** ildikov has quit IRC05:03
*** ildikov has joined #openstack-ceilometer05:17
*** Qiming has quit IRC05:46
openstackgerritA change was merged to openstack/ceilometer: Removed StorageEngine class and it's hierarchy  https://review.openstack.org/8781205:56
openstackgerritOpenStack Proposal Bot proposed a change to openstack/ceilometer: Imported Translations from Transifex  https://review.openstack.org/8850606:03
*** Qiming has joined #openstack-ceilometer06:12
*** alexpilotti has quit IRC06:28
*** sileht has quit IRC06:30
*** _nadya_ has joined #openstack-ceilometer06:30
*** sileht has joined #openstack-ceilometer06:34
*** _nadya_ has quit IRC07:02
*** ildikov has quit IRC07:05
*** _nadya_ has joined #openstack-ceilometer07:05
*** ildikov has joined #openstack-ceilometer07:07
*** aswadrangnekar has joined #openstack-ceilometer07:17
*** piyushmasrani has quit IRC07:22
*** flwang has joined #openstack-ceilometer07:26
*** vigneshvar_ has joined #openstack-ceilometer07:30
vigneshvar_i have query on alarms07:32
vigneshvar_i have set up an alarm for cpu_util < 95% just to test the alarm but when i do alarm list , it shows me "insufficient data'07:33
vigneshvar_what could be the possible reason and how can i figure out the problem07:33
*** ihrachyshka has joined #openstack-ceilometer07:34
vigneshvar_an help would be great07:35
liushengyour ceilometer and ceilometerclient is latest?07:41
*** nacim has joined #openstack-ceilometer07:45
vigneshvar_yes it is latest08:10
vigneshvar_used the master branch as on may 308:10
*** eglynn has joined #openstack-ceilometer08:19
*** renlt has joined #openstack-ceilometer08:28
aswadrangnekarOn line 48 auth_token is fetched from the dictionary which according to me is a string, and on line 137 it is a treated as a callable - is this a bug?08:29
*** ekarlso has quit IRC08:29
*** ekarlso has joined #openstack-ceilometer08:29
*** flwang has quit IRC08:32
*** ildikov has quit IRC08:35
*** ildikov_ has joined #openstack-ceilometer08:35
scroiset_aswadrangnekar: hi, see https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/client.py#L65 and L87 .. seems the token provided is always a callable.08:39
*** flwang has joined #openstack-ceilometer08:40
aswadrangnekarscroiset_: thanks! it solves my query09:02
*** flwang has quit IRC09:24
*** ihrachyshka has quit IRC09:29
*** renlt has quit IRC09:40
*** Qiming has quit IRC09:41
*** aviau has quit IRC09:50
*** eoutin has joined #openstack-ceilometer09:57
*** AMike has joined #openstack-ceilometer10:02
*** AMike has joined #openstack-ceilometer10:02
aswadrangnekarscroiset_: ping10:04
scroiset_aswadrangnekar: pong10:05
aswadrangnekarscroiset_: I did not understand one point though - why is it required that token is callable?10:06
aswadrangnekarI checked in nova python client it does not have it callable10:07
aswadrangnekarany clues?10:08
scroiset_aswadrangnekar: *thinking10:08
aswadrangnekarscroiset_: ok10:08
scroiset_so initially .. seems to be a lazy pattern to authenticate against keystone when the token is really needed.10:16
scroiset_when a raw token is passed, the same mechanism is use with a lambda .. to be compatible with the first case10:17
aswadrangnekarscroiset_: ok thanks!10:19
*** ihrachyshka has joined #openstack-ceilometer10:29
*** aswadrangnekar has left #openstack-ceilometer10:31
*** ihrachyshka has quit IRC10:35
*** DuncanT has joined #openstack-ceilometer10:59
DuncanTHi. Quick question: I'm thinking of adding api request timing to cinder for every request. Is this the sort of info ceilometer can easily consume? (I've not run ceilometer, though I'm written a few things that consume the same event stream)11:00
vigneshvar_hi, i have problem with ceilometer not trig 14gering an alarm . I am using the master branch as on may11:04
vigneshvar_hi, i have problem with ceilometer not triggering an alarm . I am using the master branch as on may 1411:04
eglynnDuncanT: ... the swift middleware for ceilometer currently intercepts incoming API calls in a way that could be re-moulded for your purpose11:05
eglynnDuncanT: ... https://github.com/openstack/ceilometer/blob/master/ceilometer/objectstore/swift_middleware.py11:05
eglynnDuncanT: ... however you might want to consider batching up the timings, as opposed to emitting a sample for every single API request-response cycle11:06
DuncanTeglynn: Thanks, I'll take a look at that code11:06
DuncanTI can certainly look at batching up the timings11:07
eglynnDuncanT: cool11:07
DuncanTI just wanted to check that a ceilometer event was a sensible place to send the results11:07
eglynnDuncanT: yeah, it could certainly be, especially if the aggregation exposed by the ceilo statistics API is sufficient for your purpose11:08
eglynnvigneshvar_: "not triggering" == "alarm state unexpectedly does not transition to alarm"11:08
eglynnvigneshvar_: or "not triggering" == "alarm state stuck in insufficient data"11:08
eglynnvigneshvar_: "not triggering" == "alarm state transitions, but no action is seen"11:09
DuncanTeglynn: I've not looked at the ceilometer stats API yet, I've got a devstack install of ceilometer so I'll go learn something about it now :-)11:09
eglynnDuncanT: ... the ceilo API allows simple aggregation (min, max, average, sum, count, stddev, cardinality) over variable-length periods11:10
eglynnDuncanT: ... but doesn't yet support calculation of things like percentiles11:10
*** _nadya_ has quit IRC11:10
DuncanTeglynn: That sounds like it will do what I want for now... and the 'yet support' bit gives me a good sign that adding anything missing would, in principle, be welcome11:11
eglynnDuncanT: cool enough, yeah we added some addition aggregation functions in icehouse, more to come possibley in juno11:12
*** flwang has joined #openstack-ceilometer11:12
eglynnDuncanT: ... reason I mentioned percentiles is that these are often used to look at API responsiveness11:13
eglynnDuncanT: (i.e. more concerned when p90 or p99 spikes, as opposed to the average)11:13
DuncanTeglynn: Yeah, I'm not yet sure how to alert on the data, step one is to collect it and analyse it during incidents11:14
eglynnDuncanT: cool11:14
DuncanTeglynn: I'm quite convinced that analysing stats is the future of monitoring, and I thing there are some smart algorithms for spotting issues, I've never had the the time or the data sets to really play. I have a fundamental allergy to statistical methods from my uni days (a badly taught set of modules) that I *really* need to shake11:15
vigneshvar_eglynn: alarm state stuck in insufficient data11:16
eglynnDuncanT: yeah, I guess the question is how sophisticated we should go with the analytics supported *directly* by ceilo11:17
eglynnDuncanT: ... remember you can always grab the raw datapoints and analyse off-line11:18
eglynnvigneshvar_: what statistic is the alarm based on?11:19
DuncanTeglynn: I suspect the way forward is to develop offline analysis, prove the general usefulness then talk about how to get them directly integrated with ceilo11:19
eglynnvigneshvar_: check the period of the alarm against the configured interval for the agent collecting that metric11:19
eglynnDuncanT: ... yeap could be11:20
eglynnDuncanT: ... we're also discussing at summit much more aggressive pre-aggregation/roll-up of incoming metrics11:20
eglynnDuncanT: ... which would point towards more exotic aggregation being done off-line11:20
*** Qiming has joined #openstack-ceilometer11:21
DuncanTeglynn: Please make pre-aggregation configurable, or certain analyses become impossible11:21
eglynnvigneshvar_: ... also check the query condition in the alarm rule, whether this would yield any data if applied to a corresponding statistics query11:21
vigneshvar_alarm is set for cpu_util11:22
vigneshvar_eglynn: alarm is set for cpu_util11:22
eglynnDuncanT: ... yep, noted!11:22
eglynnDuncanT: ... I think it would have to be heavily configurable, beyond the cheapest/simplest aggregates (i.e. avg, min, max etc.)11:23
eglynnvigneshvar_: period?11:23
vigneshvar_eglynn: for testing i have set the condition to cpu_util < 95.0. i will just check the period and send you11:23
eglynnvigneshvar_: $ ceilometer alarm-show -a $ALARM_ID11:23
vigneshvar_eglynn: period: during 1 x 600s11:24
vigneshvar_eglynn:   period                    | 60011:25
eglynnvigneshvar_: what interval is defined for the cpu source in the /etc/ceilometer/pipeline.yaml on the compute node?11:25
eglynnvigneshvar_: what query is set for the alarm?11:26
vigneshvar_eglynn: just a min will check11:26
vigneshvar_eglynn: cpu_source - interval:60011:27
eglynnvigneshvar_: right that's ok11:28
vigneshvar_egynn: metadata.user_metadata.stack == 44837952-3f1f-4497-8e59-fb314a3ea337 AND project_id == 24ba4f14daa74fc18e4a6a1d1c8689e911:28
vigneshvar_egynn: thats the query11:28
*** _nadya_ has joined #openstack-ceilometer11:29
vigneshvar_egynn : stack and project ids are correct11:29
eglynnvigneshvar_: one sec11:30
eglynnvigneshvar_: sorry back11:32
eglynnvigneshvar_: so how are the traget instances created?11:32
eglynnvigneshvar_: are you manually spinning up those instances?11:33
vigneshvar_i used the autoscaling.yaml file from hot templates11:33
vigneshvar_egylnn: i used the autoscaling.yaml file from hot templates11:33
eglynnvigneshvar_: what user metadata *exactly* is set on the instances?11:33
eglynnvigneshvar_: is it {"metering.stack": "44837952-3f1f-4497-8e59-fb314a3ea337"}11:34
eglynnvigneshvar_: or just: {"stack": "44837952-3f1f-4497-8e59-fb314a3ea337"}11:34
eglynnvigneshvar_: $ nova show INSTANCE_NAME11:34
vigneshvar_eglynn: Just a min just checking it11:35
vigneshvar_eglynn: it is metering.stack11:35
eglynnvigneshvar_: k ... reason I asked is that ceilometer will only persist user metadata in the resource metadata if the user metadata is prefixed with 'metering.'11:36
eglynnvigneshvar_: k, so next thing to look at is the project ID constraint11:37
vigneshvar_eglynn: what must be checked11:37
eglynnvigneshvar_: $ keystone tenant-list | grep 24ba4f14daa74fc18e4a6a1d1c8689e911:38
eglynnvigneshvar_: ... is that the *same* tenant as owns the instance?11:39
*** nacim has quit IRC11:39
vigneshvar_eglynn: give me a minute11:40
eglynnvigneshvar_: take all the time that you need11:41
eglynnvigneshvar_: the fact that the "project_id == 24ba4f14daa74fc18e4a6a1d1c8689e9" constraint is included in the alarm rule implies that this is not an alarm created with admin privilege11:41
eglynnvigneshvar_: ... so the stats for a resource owned by *another* tenant would not be visible when the alarm is evaluated11:42
vigneshvar_eglynn: yes the alarm is created by a user called demo11:43
vigneshvar_eglynn:  demo - 24ba4f14daa74fc18e4a6a1d1c8689e911:43
eglynnvigneshvar_: ... and the instance, owned by?11:43
vigneshvar_eglynn: and the instance is owned by demo11:43
eglynnvigneshvar_: ... $ nova show INSTANCE_NAME | grep tenant11:43
vigneshvar_eglynn: tenant_id                            | 24ba4f14daa74fc18e4a6a1d1c8689e911:44
eglynnvigneshvar_: k, that looks correct also11:45
eglynnvigneshvar_: hmmm11:47
eglynnvigneshvar_: k try running this directly:11:47
eglynnvigneshvar_: $ ceilometer sample-list -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9"11:47
eglynnvigneshvar_: (as the demo user/tenant)11:47
eglynnvigneshvar_: check with ... $ echo $OS_USERNAME $OS_TENANT_NAME11:48
vigneshvar_eglynn: user and tenant are demo11:49
vigneshvar_eglynn: Output of sample list is quite big11:49
vigneshvar_eglynn: It shows lot of value from 1 to 8511:50
eglynnvigneshvar_: sorry I meant to say to use statistics ...11:51
eglynnvigneshvar_: $ ceilometer statistics -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9"11:51
eglynnvigneshvar_: (as opposed to sample-list)11:51
vigneshvar_eglynn: yap got it.11:51
vigneshvar_eglynn: you want me to paste the whole line here or any specific values11:52
eglynnvigneshvar_: no just checking that the query returns sane values11:53
ekarlsoeglynn: is ceilo gonan be a timeseries serivce ? :p11:53
eglynnvigneshvar_: ... i.e. that the same query as used by the alarm evaluator can be run directly11:53
eglynnekarlso: are you going to summit?11:53
ekarlsoeglynn: nope sadly11:54
eglynnekarlso: we'll be discussing some related ideas here http://junodesignsummit.sched.org/event/22cb077a1722e710955b78aaef700ba7#.U2jKhoqPXQI11:54
eglynnvigneshvar_: ... have a look at your alarm evaluator log11:55
*** nacim has joined #openstack-ceilometer11:55
vigneshvar_eglynn: ok i will check that11:55
eglynnvigneshvar_: are you running devstack?11:55
eglynnvigneshvar_: ... or an actual install?11:55
vigneshvar_eglynn: devstack11:55
eglynnvigneshvar_: k, screen -r, then look at the ceilometer-alarm-evaluator screen11:56
vigneshvar_eglynn: just checking it11:56
eglynnvigneshvar_: you should see period statistics queries in the logs (one for each alarm)11:57
*** _nadya_ has quit IRC11:58
vigneshvar_eglynn: i dont find ceilometer-alarm-evaluator......... only ceilometer-acompute,ceilometer-acentral,ceilometer-collector, ceilometer-api11:59
vigneshvar_eglynn: only those are present11:59
eglynnvigneshvar_: that's your problem right there methinks11:59
eglynnvigneshvar_: grep enable ~/devstack/localrc11:59
eglynnvigneshvar_: http://docs.openstack.org/developer/ceilometer/install/development.html12:00
eglynnvigneshvar_: note: "enable_service ceilometer-alarm-evaluator,ceilometer-alarm-notifier"12:00
vigneshvar_eglynn: ENABLED_SERVICES+=,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api12:01
vigneshvar_eglynn: ENABLED_SERVICES+=,ceilometer-alarm-notify,ceilometer-alarm-eval12:01
vigneshvar_both are already enabled and stack had no errors12:01
eglynnvigneshvar_: s/ceilometer-alarm-eval/ceilometer-alarm-evaluator/12:02
eglynnvigneshvar_: s/ceilometer-alarm-notify/ceilometer-alarm-notifier/12:02
vigneshvar_eglynn: i will change it and rerun the stack and try it once again12:02
eglynnvigneshvar_: ... k12:03
vigneshvar_eglynn: thanks a lot. I will get back with you once i am done with it12:07
eglynnvigneshvar_: np!12:07
vigneshvar_eglynn: Is there a way to update only these two services without actually disturbing the devstack setup12:08
eglynnvigneshvar_: well easiest would be simply to run these services manually12:09
vigneshvar_eglynn: ok i will do that. thanks12:10
eglynnvigneshvar_: ... e.g. ceilometer-alarm-evaluator --config-file /etc/ceilometer/ceilometer.conf ... etc.12:10
*** fnaval has joined #openstack-ceilometer12:16
*** thomasem has quit IRC12:24
*** thomasem has joined #openstack-ceilometer12:25
*** ildikov_ has quit IRC12:27
*** ildikov has joined #openstack-ceilometer12:27
*** promulo has quit IRC12:30
*** eoutin has quit IRC12:52
*** aviau has joined #openstack-ceilometer12:55
vigneshvar_eglynn: I have enabled the services12:58
vigneshvar_eglynn: and i can see the logs12:58
eglynnvigneshvar_: and what's the alarm state now?12:58
vigneshvar_eglynn: But it is just the same12:58
eglynnvigneshvar_: are you seeing the statistics queries in the alarm evaluator logs?12:59
vigneshvar_eglynn: Yes i can query stats13:00
*** kun_huang has joined #openstack-ceilometer13:02
eglynnvigneshvar_: ... you can see the query? ... what's the response? ... is it non-empty?13:03
eglynnvigneshvar_: ... in a functioning case, the relevant log output would look something like http://paste.openstack.org/show/79158/13:04
*** nacim has quit IRC13:05
*** nacim has joined #openstack-ceilometer13:06
*** eoutin has joined #openstack-ceilometer13:06
*** zul has joined #openstack-ceilometer13:07
*** gordc has joined #openstack-ceilometer13:08
vigneshvar_eglynn: http://paste.openstack.org/show/79159/13:08
vigneshvar_eglynn: no output13:09
vigneshvar_eglynn: shows []13:09
eglynnvigneshvar_: ... didn't you say earlier that the alarm period was 600s?13:10
vigneshvar_eglynn: i think it is another alarm13:11
eglynnvigneshvar_: the bound timestamps are 2014-05-03T19:39:22 and 2014-05-03T19:41:2213:11
vigneshvar_eglynn: there are two alarms. one for scale up and scale down13:11
vigneshvar_eglynn: that machine has current time "Sat May  3 19:44:24 GMT 2014"13:12
eglynnvigneshvar_: the bounding timestamps are only 2 minutes apart, with period=60s13:12
eglynnvigneshvar_: ... that indicates an eval window of 120s, not 600s13:12
eglynnvigneshvar_: ... whereas the interval that the metric is gathered over is 600s, right?13:13
vigneshvar_eglynn: yes you are right13:15
eglynnvigneshvar_: ... so you must either:13:15
eglynnvigneshvar_: ... (a) change the interval for the cpu source to 60s and restart the compute agent13:15
eglynnvigneshvar_: ... or:13:15
eglynnvigneshvar_: ... (b) chage the alarm period to be 600s13:15
openstackgerritKoert van der Veer proposed a change to openstack/ceilometer: Implemented metering for cinder's snapshots  https://review.openstack.org/9236513:18
vigneshvar_eglynn: there were two alarms. one alarm is 60s and other 600s13:18
vigneshvar_eglynn: i think one i pasted is 60s one13:19
eglynnvigneshvar_: are both still in insufficient_data?13:19
eglynnvigneshvar_: $ ceilometer alarm-list13:19
vigneshvar_eglynn: yes13:19
vigneshvar_eglinn: both insufficient data13:20
eglynnvigneshvar_: can you post the log excerpt for the 600s alarm?13:20
vigneshvar_eglynn: sure just a min13:20
*** erecio has quit IRC13:21
*** erecio has joined #openstack-ceilometer13:22
vigneshvar_eglynn: http://paste.openstack.org/show/79161/13:23
*** changbl has quit IRC13:24
*** julim has joined #openstack-ceilometer13:25
eglynnvigneshvar_: ... what user are you running the ceilometer-alarm-evaluator under?13:25
vigneshvar_eglynn: the user which i used to run stack.sh (username: openstack)13:26
vigneshvar_i run it in the screen which is already created by devstack13:26
eglynnvigneshvar_: ... I mean the OS_USERNAME etc.13:27
vigneshvar_eglynn: demo13:27
eglynnvigneshvar_: surely that should be admin?13:28
eglynnvigneshvar_: nah ignore that13:29
eglynnvigneshvar_: ... determined by the service_credentials in the ceilometer.conf13:29
vigneshvar_eglynn: give me a min13:30
flwanggordc: ping13:31
gordcflwang: whatup?13:31
flwanggordc: do you know is there any company are using Ceilometer in production environment? thanks13:32
*** _nadya_ has joined #openstack-ceilometer13:32
*** nacim has quit IRC13:33
gordceglynn: you guys use it? ^13:33
eglynnvigneshvar_: ... I'm presuming the service_credentials in the ceilometer.conf are correct13:33
eglynnvigneshvar_: ... otherwise it would not be possible for say the compute agent to query nova-api to discover the local instances13:33
gordcflwang: i assume enovance and dreamhost use it to some extent.13:33
flwanggordc: cool, thanks13:34
eglynngordc: ... well Red Hat isn't operating a public cloud, but we do use it for some smaller scale internal labs13:34
eglynngordc, flwang: ... yeah AFAIK DreamHost13:34
flwanggordc: as for eNovance and Dreamhost, I'm curious is there a billing system13:34
gordcflwang: i think Dreamhose uses it for billing... dhellmann would be able to answer that (or direct you to someone who could)13:35
eglynnflwang: ... ask dhellmann, IIRC there is called "The Dude" or something similar13:35
dhellmanneglynn, flwang, gordc : we've actually moved to a quota-based flat billing structure13:36
flwangeglynn: gordc: got it. thanks a lot13:36
flwangdhellmann: ah, you're here :)13:36
dhellmannthe dude code is still around, but uses the v1 API13:36
flwangdhellmann: Dude is a code name for the billing system, right?13:36
*** rdmcnair has joined #openstack-ceilometer13:36
dhellmannDude is a "bacronym" for "Dreamhost Usage Data Exporter"13:37
gordcdhellmann: was just about to ask...13:37
dhellmannit is the tool we used to move data out of ceilometer, into our existing billing system13:37
dhellmannwe built a lot of this stuff after going on a Big Lebowski kick, so we have another tool called Rug that ties our network systems together :-)13:38
flwangdhellmann: ah, so it's most like an adapter between CM and your existed billing system, right?13:38
dhellmannflwang: yes, that's right13:38
dhellmannit ran queries in ceilomter, and recorded the results in the billing system13:38
openstackgerritLadislav Smola proposed a change to openstack/ceilometer: Automatic discovery of TripleO Overcloud hardware  https://review.openstack.org/9237013:38
flwangdhellmann: got it. may I get your thoughts about why there is no billing components for OpenStack?13:39
*** Qlawy has left #openstack-ceilometer13:40
flwangdhellmann: is it too customized to get a common one?13:40
vigneshvar_eglynn: os_username = ceilometer inside ceilometer.conf13:41
eglynnvigneshvar_: check with ... $ grep os_ /etc/ceilometer/ceilometer.conf | awk '{printf("%s=%s\n", toupper($1), $3);}' > scrc ; . ./scrc13:41
eglynnvigneshvar_: ... then repeat: $ ceilometer statistics -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9"13:41
dhellmannflwang: yes, exactly. we decided very early on that most deployers would already have something for billing, so building a tool they could integrate with their existing systems would make more sense. Also, the rules for what people wanted to charge for might be very complex.13:42
*** fnaval has quit IRC13:43
flwangdhellmann: i see. thanks for the patient clarification13:43
dhellmannflwang: any time!13:44
vigneshvar_eglynn: you want me to do it on the terminal where . ceilometer-alarm-evaluator13:44
eglynnvigneshvar_: nope, just run any shell, then first run: $ . ~/devstack/openrc demo demo13:45
eglynnvigneshvar_: .., then $ grep os_ /etc/ceilometer/ceilometer.conf | awk '{printf("%s=%s\n", toupper($1), $3);}' > scrc ; . ./scrc13:45
eglynnvigneshvar_: ... that's set up your shell to use the same credentials13:46
eglynnvigneshvar_: ... that'll13:46
eglynnvigneshvar_: ... if not creds, the other obvious candidate is timestamp drift13:46
eglynnvigneshvar_: ... are both the compute node *and* the alarm evaluator host seeing the same current time13:47
eglynnvigneshvar_: ... same == "same ballpark"13:47
eglynnvigneshvar_: ... the times mentioned earlier looked way off13:47
vigneshvar_eglynn: the timestamps are correct. That machine time was not set properly13:48
vigneshvar_eglynn: It is a single node setup13:48
eglynnvigneshvar_: have you run the above?13:48
*** _nadya_ has quit IRC13:49
vigneshvar_eglynn: after setting up the new credential what should i run on that to test13:50
*** nacim has joined #openstack-ceilometer13:51
*** _nadya_ has joined #openstack-ceilometer13:52
eglynnvigneshvar_: $ ceilometer statistics -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9;timestamp>2014-05-03T19:15:08;timestamp<=2014-05-03T19:35:08'13:52
vigneshvar_eglynn: no data13:52
vigneshvar_eglynn: just an empty table13:52
eglynnvigneshvar_: again without the timestamp constraints13:52
eglynnvigneshvar_: $ ceilometer statistics -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9'13:53
vigneshvar_eglynn: then i get the data13:53
ekarlsoeglynn: whats' so bad with the metadata ?13:53
eglynnvigneshvar_: ... and the conclusion is?13:53
vigneshvar_eglynn: time problem13:54
eglynnvigneshvar_: ... yeap, smells that way, doesn't it?13:54
eglynnvigneshvar_: ... how about correcting the current time?13:54
vigneshvar_eglynn: yap you are right13:54
eglynnvigneshvar_: ... better still set up NTP13:54
vigneshvar_eglynn: does nt it affect other services ?13:54
eglynnvigneshvar_: ... it may well do, in some subtle ways13:55
vigneshvar_eglynn: so can i set up current time13:55
eglynnekarlso: ... what's bad about the "weight of highly repetitive free-form metadata"?13:56
eglynnekarlso: ... well it's weighty for a start13:56
eglynnekarlso: ... and highly repetitive ;)13:56
ekarlsoeglynn: how else u store metadata then ?13:57
eglynnekarlso: in a more lightweight form, that doesn't repeat rarely-changing resource metadata for every single datapoint13:58
ekarlsoeglynn: so what, store md once then or for a resource?13:58
*** julim has quit IRC13:58
eglynnekarlso: ... that's what we need to agree at summit, how to handle the fact that the metadata is rarely changing but *not* completely static14:00
*** julim has joined #openstack-ceilometer14:02
ildikoveglynn, ekarlso: if we can identify the parts of metadata that are static, than maybe we will be a half step closer14:03
eglynnildikov: yeap ... or possibly treat changes in metadata as being akin to a "new identity" for the resource14:05
ildikoveglynn, ekarlso: but I'm living in a dream world, where metadata is validated against a model or somehow not 100% free form :)14:05
vigneshvar_eglynn: how to check if any new data is collected ?14:06
eglynnvigneshvar_: use the sample-list command line above14:07
ildikoveglynn: hmm, that new identity thing sounds a bit complicated related to that the data is stored for a longer time period, where these identities are changing14:07
eglynnvigneshvar_: $ ceilometer sample-list -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9"14:07
vigneshvar_eglynn: i dont find any data with current date as i have set now14:08
*** prad has joined #openstack-ceilometer14:08
eglynnvigneshvar_: has a 600s interval rolled around yet?14:08
eglynnvigneshvar_: if you're impatient ...14:09
*** fnaval has joined #openstack-ceilometer14:09
eglynnvigneshvar_: ... change the interval for the cpu source in the pipeline.yaml to say 60s14:09
eglynnvigneshvar_: ... restart the compute agent14:09
eglynnvigneshvar_: $ sleep 60 ; ceilometer sample-list -m cpu_util -q 'metadata.user_metadata.stack=44837952-3f1f-4497-8e59-fb314a3ea337;project=24ba4f14daa74fc18e4a6a1d1c8689e9"14:10
eglynnildikov: ... yeah all open for discussion in ATL methinks, another approach mooted was to only store the latest metadata and reply on events to bracket relevant changes to the resource state14:12
eglynnildikov: ... e.g. instead of having the instance state=suspended for some datapoints and state=active for others, the suspension/resume events effectively carry the bracketed time ranges14:13
vigneshvar_eglynn: no new data at all14:14
ildikoveglynn: yeap, it's an option, but we will see what direction the summit talks will go to14:14
eglynnildikov: yep14:15
ildikoveglynn: I'm still behind with reading the mails, it's all your fault ;)14:15
eglynnvigneshvar_: look at the compute agent logs14:15
eglynnildikov: LOL :)14:15
*** promulo has joined #openstack-ceilometer14:15
vigneshvar_eglynn: got new samples14:16
vigneshvar_eglynn: alarm state true14:17
vigneshvar_eglynn: state - alarm14:17
eglynnvigneshvar_: \o/14:17
vigneshvar_eglynn: thanks a lot got it working . You are awesome14:17
eglynnvigneshvar_: np!14:18
*** eoutin has quit IRC14:20
*** alexpilotti has joined #openstack-ceilometer14:20
gordcdhellmann: i added a comment to notifier middleware bp: https://blueprints.launchpad.net/oslo.messaging/+spec/grad-notifier-middleware ... some concerns about where to graduate code to.14:34
openstackgerritArtur Svechnikov proposed a change to openstack/python-ceilometerclient: Add methods to resource classes  https://review.openstack.org/9155414:35
*** vigneshvar_ has quit IRC14:51
*** shakayumi has joined #openstack-ceilometer14:52
*** DuncanT has left #openstack-ceilometer14:53
*** jergerber has joined #openstack-ceilometer15:04
openstackgerritA change was merged to openstack/ceilometer: Corrections of spelling, rephrasing for clarity  https://review.openstack.org/9218415:07
*** lsmola has quit IRC15:18
*** fnaval has quit IRC15:21
*** fnaval has joined #openstack-ceilometer15:23
*** shakayumi has quit IRC15:31
*** AMike has quit IRC15:32
*** shakamunyi has joined #openstack-ceilometer15:32
*** zul has quit IRC15:34
*** _cjones_ has joined #openstack-ceilometer15:35
*** alexpilotti_ has joined #openstack-ceilometer15:41
*** alexpilotti has quit IRC15:44
*** alexpilotti_ is now known as alexpilotti15:44
*** eglynn has quit IRC15:46
*** fnaval has quit IRC15:47
*** eglynn has joined #openstack-ceilometer15:52
*** changbl has joined #openstack-ceilometer15:54
*** _nadya_ has quit IRC15:56
*** zul has joined #openstack-ceilometer15:58
*** fnaval has joined #openstack-ceilometer15:59
*** Ruetobas has quit IRC16:01
*** Ruetobas has joined #openstack-ceilometer16:03
*** mengxd has joined #openstack-ceilometer16:06
openstackgerritKoert van der Veer proposed a change to openstack/ceilometer: Implemented metering for cinder's snapshots  https://review.openstack.org/9236516:07
*** zul has quit IRC16:07
*** Ruetobas has quit IRC16:07
*** Ruetobas has joined #openstack-ceilometer16:13
*** zul has joined #openstack-ceilometer16:13
openstackgerritKoert van der Veer proposed a change to openstack/ceilometer: Implemented metering for cinder's snapshots  https://review.openstack.org/9236516:19
*** _nadya_ has joined #openstack-ceilometer16:26
*** Qiming has quit IRC16:27
dhellmanngordc: you might be right, I'll have to look at the dependency graph again16:38
gordcdhellmann: cool cool.16:39
dhellmanngordc: if the notifier middleware moves to oslo.messaging, wouldn't the audit middleware (and oslo.middleware) just depend on oslo.messaging?16:40
*** eglynn has quit IRC16:40
gordcdhellmann: right... but the audit middleware exists in oslo.middleware... and notifier middleware depends on oslo.middleware (assuming the base middleware code gets moved there (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/middleware/base.py))16:42
*** shakamunyi has quit IRC16:42
dhellmanngordc: I think moving the auditing middleware to messaging may have been a mistake (though I know it was done to fix adoption issues with oslo.messaging). I'm not sure how to correct it, now, though. :-/16:43
dhellmannwe can't just put all of the middleware in the messaging lib16:43
dhellmannand we don't want oslo.messaging to depend on oslo.middleware, even to handle a backwards-compatibility issue like the auditing middleware16:44
gordcdhellmann: right. well we can have notifier middleware in oslo.middleware so it'll just be oslo.middleware dependent on oslo.messaging (except now you're pulling in oslo.messaging for something only a subset of middlewares use)16:45
dhellmannyeah, I think that's why I suggested putting the notifier code in oslo.messaging16:46
dhellmanngordc: this is hurting my head :-)16:46
gordcdhellmann: i'd assume the issue would be present regardless of audit middleware... any middleware that wants to extend notifier middleware will create a cyclic dependency.16:46
dhellmanngordc: is any of this simpler if we assume that no code from the incubator is going into any of these libraries? because that's my assumption.16:47
gordc:) glad to spread the headache.16:47
dhellmanngordc: how is there a cycle? does the notifier middleware use a base class that's going to be in oslo.middleware?16:47
gordcdhellmann: ^^ the base.py file above...16:48
gordcdhellmann: that said, it's pretty generic so we could just keep two copies around.16:48
dhellmanngordc: ok, I missed that16:48
dhellmannnah, we'll just move all of the middleware to oslo.middleware, I guess16:48
gordcdhellmann: ok... yeah, i'm not sure if there's a scenario where can avoid not pulling in oslo.messaging into oslo.middleware... unless we drop notifier middleware completely.16:50
dhellmannwell, we can't drop it if people are using it16:51
dhellmannit might have to go into its own library or something, but that may stir up other issues16:51
dhellmanneglynn: what are the chances of moving http://junodesignsummit.sched.org/event/22cb077a1722e710955b78aaef700ba7 so it doesn't conflict with any oslo sessions?16:52
gordcright... i mean the goal is to drop audit middleware at some point but notifier middleware is its own thing so not sure if that can be dropped.16:52
dhellmanngordc: I don't suppose I could convince you to write up the analysis of those middleware modules and make some recommendations for how to organize them?16:55
*** nacim has quit IRC16:56
gordcsure. i can write up an ether... what type of info you looking for? what middleware does and its dependencies?16:56
dhellmanngordc: yeah, just a list of the modules and how they depend on each other and other libraries17:00
*** kun_huang has quit IRC17:11
*** ildikov has quit IRC17:16
*** mengxd has quit IRC17:20
*** yjiang5_away is now known as yjiang517:23
*** zul has quit IRC17:25
*** dperaza has joined #openstack-ceilometer17:45
*** _nadya_ has quit IRC17:51
*** _nadya_ has joined #openstack-ceilometer17:53
*** nekron99 has joined #openstack-ceilometer17:55
*** nekron99 has quit IRC17:55
*** nekron99 has joined #openstack-ceilometer17:56
*** _nadya_ has quit IRC17:57
*** cjchand has joined #openstack-ceilometer18:13
*** alexpilotti has quit IRC18:17
*** alexpilotti has joined #openstack-ceilometer18:20
*** _nadya_ has joined #openstack-ceilometer18:27
*** ildikov has joined #openstack-ceilometer18:37
*** zul has joined #openstack-ceilometer18:44
*** zul has quit IRC19:02
*** zul has joined #openstack-ceilometer19:06
*** promulo has quit IRC19:15
*** _nadya_ has quit IRC19:25
*** _nadya_ has joined #openstack-ceilometer19:25
*** promulo has joined #openstack-ceilometer19:31
*** _nadya_ has quit IRC19:38
*** cjchand has quit IRC19:48
*** cjchand__ has joined #openstack-ceilometer19:48
openstackgerritgordon chung proposed a change to openstack/ceilometer: fix indices in event tables  https://review.openstack.org/9150119:53
openstackgerritgordon chung proposed a change to openstack/ceilometer: fix event model  https://review.openstack.org/9245419:53
*** eglynn has joined #openstack-ceilometer19:56
*** _nadya_ has joined #openstack-ceilometer20:08
*** julim has quit IRC20:31
*** mengxd has joined #openstack-ceilometer20:40
*** nekron99 has quit IRC20:45
*** _nadya_ has quit IRC20:46
*** jdob has quit IRC20:55
*** prad_ has joined #openstack-ceilometer21:03
*** prad has quit IRC21:05
*** prad_ is now known as prad21:05
*** xdmeng has joined #openstack-ceilometer21:09
*** mengxd has quit IRC21:12
*** xdmeng has quit IRC21:15
*** mengxd has joined #openstack-ceilometer21:16
*** mengxd has quit IRC21:17
*** rdmcnair has quit IRC21:20
*** mengxd has joined #openstack-ceilometer21:28
*** jaypipes has quit IRC21:30
*** xdmeng has joined #openstack-ceilometer21:31
*** mengxd has quit IRC21:34
*** xdmeng has quit IRC21:39
*** xdmeng has joined #openstack-ceilometer21:39
*** cjchand__ has quit IRC21:41
*** eglynn has quit IRC21:51
*** zul has quit IRC22:07
*** zul has joined #openstack-ceilometer22:09
*** zul has quit IRC22:23
*** prad has quit IRC22:39
*** changbl has quit IRC22:49
*** fnaval has quit IRC22:59
*** cjchand has joined #openstack-ceilometer23:02
*** liusheng has quit IRC23:06
*** jergerber has quit IRC23:14
*** fnaval has joined #openstack-ceilometer23:37

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!