| *** xmltok has joined #openstack-ceilometer | 00:02 | |
| *** prad_ has joined #openstack-ceilometer | 01:16 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/python-ceilometerclient: Enable hacking H233 rule https://review.openstack.org/68531 | 01:16 |
|---|---|---|
| *** prad_ has quit IRC | 01:16 | |
| *** prad has quit IRC | 01:17 | |
| *** xmltok has quit IRC | 01:45 | |
| *** rwsu has joined #openstack-ceilometer | 02:14 | |
| *** adriant has joined #openstack-ceilometer | 02:45 | |
| openstackgerrit | liusheng proposed a change to openstack/python-ceilometerclient: return sample info when creating sample with CLI https://review.openstack.org/66125 | 02:50 |
| openstackgerrit | A change was merged to openstack/ceilometer: Insertion in HBase should be fixed https://review.openstack.org/52670 | 03:10 |
| openstackgerrit | A change was merged to openstack/python-ceilometerclient: replace assertTrue(isinstance) to assertIsInstance https://review.openstack.org/67641 | 03:10 |
| openstackgerrit | A change was merged to openstack/ceilometer: assertTrue(isinstance) replace by assertIsInstance https://review.openstack.org/67608 | 03:10 |
| openstackgerrit | A change was merged to openstack/ceilometer: Add new rate-based disk and network pipelines https://review.openstack.org/66658 | 03:35 |
| openstackgerrit | A change was merged to openstack/ceilometer: Trivial typo https://review.openstack.org/66679 | 03:45 |
| openstackgerrit | A change was merged to openstack/ceilometer: use six.move.xrange replace xrange https://review.openstack.org/67635 | 03:45 |
| *** adriant has quit IRC | 04:46 | |
| *** nadya__ has joined #openstack-ceilometer | 05:40 | |
| *** nadya__ has quit IRC | 05:44 | |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 05:46 | |
| openstackgerrit | A change was merged to openstack/ceilometer: Added resources support in pollster's interface https://review.openstack.org/58489 | 05:47 |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 05:49 | |
| openstackgerrit | Jenkins proposed a change to openstack/ceilometer: Imported Translations from Transifex https://review.openstack.org/62808 | 06:03 |
| *** nadya__ has joined #openstack-ceilometer | 06:18 | |
| *** nadya__ has quit IRC | 06:27 | |
| *** nadya__ has joined #openstack-ceilometer | 06:57 | |
| *** nadya__ has quit IRC | 07:03 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/ceilometer: Removes use of timeutils.set_time_override https://review.openstack.org/67826 | 07:24 |
| *** nadya__ has joined #openstack-ceilometer | 07:30 | |
| *** nadya__ has quit IRC | 07:35 | |
| *** boris-42 has quit IRC | 07:41 | |
| *** krast has quit IRC | 07:44 | |
| openstackgerrit | Lianhao Lu proposed a change to openstack/ceilometer: Added abc.ABCMeta metaclass for abstract classes https://review.openstack.org/68565 | 07:49 |
| *** julienvey_ has joined #openstack-ceilometer | 08:10 | |
| *** s2r2_ has joined #openstack-ceilometer | 08:13 | |
| *** krast has joined #openstack-ceilometer | 08:27 | |
| *** ildikov_ has quit IRC | 08:31 | |
| *** ildikov_ has joined #openstack-ceilometer | 08:53 | |
| openstackgerrit | Nadya Privalova proposed a change to openstack/ceilometer: Fix happybase version https://review.openstack.org/68436 | 09:01 |
| *** Alexei_987 has joined #openstack-ceilometer | 09:07 | |
| *** yassine has joined #openstack-ceilometer | 09:10 | |
| openstackgerrit | Nadya Privalova proposed a change to openstack/ceilometer: Fix recursive_keypairs output https://review.openstack.org/67704 | 09:30 |
| *** jeju has joined #openstack-ceilometer | 09:36 | |
| jeju | hi | 09:38 |
| jeju | i'm trying to get work this template http://pastebin.com/V7NYJDvR , but in my ceilometer-agent's log I see "transitioning to insufficient data because 1 datapoints are unknown" and the alarms is in "insufficient data" state.. :| | 09:40 |
| jeju | why? | 09:40 |
| *** boris-42 has joined #openstack-ceilometer | 09:46 | |
| *** sayali has joined #openstack-ceilometer | 09:47 | |
| *** sayali has quit IRC | 09:47 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/ceilometer: Fix wrong doc string for meter type https://review.openstack.org/68582 | 09:48 |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 09:51 | |
| openstackgerrit | Nadya Privalova proposed a change to openstack/ceilometer: Make lists query-able during fetching samples and meters https://review.openstack.org/68583 | 09:53 |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/python-ceilometerclient: Fix typos picked up by misspellings https://review.openstack.org/68584 | 09:54 |
| *** xianghui has joined #openstack-ceilometer | 10:14 | |
| *** eglynn has joined #openstack-ceilometer | 10:21 | |
| *** xianghui has quit IRC | 10:23 | |
| *** vrovachev has joined #openstack-ceilometer | 10:34 | |
| *** vrovachev has left #openstack-ceilometer | 10:34 | |
| *** yassine has quit IRC | 11:52 | |
| *** ildikov_ has quit IRC | 12:00 | |
| *** ildikov_ has joined #openstack-ceilometer | 12:03 | |
| *** sayali has joined #openstack-ceilometer | 12:04 | |
| *** sayali_ has joined #openstack-ceilometer | 12:04 | |
| *** sayali_ has quit IRC | 12:04 | |
| *** vkodam has joined #openstack-ceilometer | 12:05 | |
| vkodam | hi | 12:05 |
| *** jeju has quit IRC | 12:09 | |
| *** xianghui has joined #openstack-ceilometer | 12:22 | |
| *** jdob has joined #openstack-ceilometer | 13:00 | |
| *** _ruhe is now known as ruhe | 13:01 | |
| *** yassine has joined #openstack-ceilometer | 13:03 | |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 13:13 | |
| *** sayali has quit IRC | 13:18 | |
| *** ruhe is now known as _ruhe | 13:22 | |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 13:22 | |
| openstackgerrit | Eoghan Glynn proposed a change to openstack/python-ceilometerclient: Avoid discarding alarm-threshold-create --query option https://review.openstack.org/68637 | 13:31 |
| *** sayali has joined #openstack-ceilometer | 13:33 | |
| *** thomasem has joined #openstack-ceilometer | 13:40 | |
| *** s2r2_ has quit IRC | 13:49 | |
| *** SergeyLukjanov is now known as SergeyLukjanov_a | 13:50 | |
| *** tongli has joined #openstack-ceilometer | 13:50 | |
| *** SergeyLukjanov_a is now known as SergeyLukjanov_ | 13:51 | |
| *** s2r2_ has joined #openstack-ceilometer | 13:52 | |
| scroiset | Hello all | 13:54 |
| scroiset | FYI I added a topic to the meeting agenda today: about Heat notifications | 13:54 |
| scroiset | https://blueprints.launchpad.net/ceilometer/+spec/handle-heat-notifications | 13:55 |
| nadya_ | scroiset, hi! could you please share a link with agenda? | 14:01 |
| scroiset | nadya_: https://wiki.openstack.org/wiki/Meetings/Ceilometer#Agenda | 14:01 |
| nadya_ | scroiset, thanks! | 14:01 |
| *** yfujioka has joined #openstack-ceilometer | 14:03 | |
| openstackgerrit | Nadya Privalova proposed a change to openstack/ceilometer: Fix work with metadata in HBase https://review.openstack.org/68641 | 14:09 |
| vkodam | Hi | 14:10 |
| vkodam | I have updated the blueprint for ceilometer dynamic meters | 14:11 |
| vkodam | you can refer https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters | 14:11 |
| vkodam | for more information | 14:11 |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 14:12 | |
| *** boris-42_ has joined #openstack-ceilometer | 14:14 | |
| openstackgerrit | Nadya Privalova proposed a change to openstack/ceilometer: Fix work with metadata in HBase https://review.openstack.org/68641 | 14:15 |
| *** boris-42 has quit IRC | 14:15 | |
| openstackgerrit | Ilya Tyaptin proposed a change to openstack/ceilometer: Add run pollsters on demand function to api https://review.openstack.org/66551 | 14:16 |
| *** _ruhe is now known as ruhe | 14:17 | |
| *** sayali has quit IRC | 14:18 | |
| *** dhellmann_ is now known as dhellmann | 14:19 | |
| *** sayali has joined #openstack-ceilometer | 14:19 | |
| openstackgerrit | Ilya Tyaptin proposed a change to openstack/ceilometer: Add run pollsters on demand function to api https://review.openstack.org/66551 | 14:19 |
| *** s2r2_ has quit IRC | 14:36 | |
| openstackgerrit | Eoghan Glynn proposed a change to openstack/python-ceilometerclient: Avoid discarding alarm-threshold-create --query option https://review.openstack.org/68637 | 14:39 |
| *** s2r2_ has joined #openstack-ceilometer | 14:43 | |
| *** s2r2_ has quit IRC | 14:47 | |
| *** s2r2_ has joined #openstack-ceilometer | 14:51 | |
| *** zqfan has joined #openstack-ceilometer | 15:04 | |
| nadya_ | eglynn: I added a small note in aggregation etherpad, please take a look | 15:04 |
| eglynn | nadya_: will do, after the IRC meeting | 15:04 |
| nadya_ | eglynn, just wanted to discuss this on meeting | 15:05 |
| eglynn | nadya_: ack | 15:06 |
| *** gordc has joined #openstack-ceilometer | 15:12 | |
| *** xianghui has quit IRC | 15:26 | |
| *** prad_ has joined #openstack-ceilometer | 15:32 | |
| *** boris-42_ has quit IRC | 15:39 | |
| *** s2r2_ has quit IRC | 15:40 | |
| *** jdob has quit IRC | 15:41 | |
| *** dhellmann is now known as dhellmann_ | 15:53 | |
| *** jdob has joined #openstack-ceilometer | 15:55 | |
| *** gordc has quit IRC | 15:56 | |
| *** gordc has joined #openstack-ceilometer | 15:57 | |
| *** ilyashakhat has joined #openstack-ceilometer | 16:02 | |
| nadya_ | will continue here? | 16:03 |
| jaypipes | nadya_: yes, I've asked Ladislav to join us. | 16:04 |
| nadya_ | ok | 16:04 |
| jaypipes | ilyashakhat: good evening. :) | 16:04 |
| *** lsmola_ has joined #openstack-ceilometer | 16:05 | |
| jaypipes | nadya_: do you have the *exact* API query that the Horizon UI would be making to Ceilo? | 16:05 |
| jaypipes | or lsmola_^^ | 16:05 |
| eglynn | just now on #openstack-metering ... <lsmola_> eglynn: /me processing where start % 1hour != 0 even if period == 1hour | 16:05 |
| lsmola_ | jaypipes: ok, I am not sure how to achieve start % 1hour != 0 even if period == 1hour | 16:05 |
| nadya_ | I wanted to remind you that our current UI needs to be improved. We may make it in the way to use cache more actively | 16:05 |
| eglynn | lsmola_: the example I gave earlier in the meeting | 16:06 |
| lsmola_ | jaypipes: what i am doing is put condition to query for start and end date, which is always end and beginning of some day | 16:06 |
| eglynn | lsmola_: ... 10:07->11:06,11:07->12:06,... | 16:06 |
| lsmola_ | jaypipes: and compute period so it always shows around 300 samples | 16:07 |
| jaypipes | lsmola_: k, understood. so... that data does not change after the first time you execute it (if you execute it for a period in the past of course). So, what about just storing the results of your Ceilometer API call in memcache and having the UI simply return the memcache results after the first query to Ceilometer? | 16:07 |
| eglynn | lsmola_: my question earlier was whether such clamping to start and end of days was the way horizon currently works? | 16:07 |
| lsmola_ | jaypipes: horizon doesn't have cache server yet i believe | 16:08 |
| jaypipes | lsmola_: right, but it could. this is why I am pushing back on changing the design of ceilomter to fulfill the use case of a UI. | 16:09 |
| lsmola_ | jaypipes: yeah it could be cached for <start,end,meter> key | 16:09 |
| jaypipes | lsmola_: I am also playing "devil's advocate" a bit here... want to make sure to discuss all angles of the use cases. | 16:09 |
| lsmola_ | jaypipes: if it is in the past, and period will remain the same | 16:09 |
| nadya_ | Is it too bas to show timeseries for 11:07->14:06 in the following way: 11.07-12.00, 12.00-13.00, 13.00-14.00, 14.00-14.06? | 16:10 |
| jaypipes | lsmola_: right, exactly... | 16:10 |
| eglynn | nadya_: that approach could certainly work for charting | 16:11 |
| nadya_ | yep | 16:11 |
| eglynn | nadya_: ... though it's not how alarming currently works | 16:11 |
| lsmola_ | nadya_: well my period changes, because I don't want to show thousands of points in a chart | 16:11 |
| jaypipes | nadya_: I'm not saying it's bad. :) I'm saying that baking that functionality (fixed-interval stats caching) into Ceilometer's server implementation is not ideal. Instead, having that caching layer external to Ceilometer is more flexible IMO | 16:11 |
| lsmola_ | nadya_: so it is not always one hour | 16:11 |
| nadya_ | that was my idea maybe to reduce user's choices for params but make UI (or just queries) faster | 16:12 |
| lsmola_ | nadya_: the issue here is that we use multiline chart | 16:13 |
| nadya_ | or to make user ability to configure queries that is most important for them | 16:13 |
| jaypipes | nadya_: understood, and that is a perfectly valid use case. I'm just saying I don't think this should be implemented in the CM server. | 16:13 |
| lsmola_ | nadya_: and SVG rendering should now have thousands of entities, or it can break (didn't actually test the limits) | 16:13 |
| *** s2r2_ has joined #openstack-ceilometer | 16:13 | |
| lsmola_ | nadya_: so that is why I always change the period to show some reasonable amount of point in a chart | 16:14 |
| jaypipes | nadya_, lsmola_: are you both working on the horizon metering graph UI? | 16:15 |
| lsmola_ | nadya_: so so some cache server (memcache, redis) as jaypipes is proposing might make more sense here | 16:15 |
| nadya_ | but what about not-UI cases? | 16:15 |
| lsmola_ | lsmola_: just me as far as i know :-) | 16:15 |
| lsmola_ | nadya_: that i don't know :-) | 16:15 |
| nadya_ | I'm not working on UI :) | 16:16 |
| eglynn | the other big repetitive hit on the stats API is alarming | 16:16 |
| nadya_ | I know that a lot of services want to get statistics fast | 16:16 |
| lsmola_ | eglynn: yeah but the amount of samples always changes there, right? | 16:17 |
| eglynn | but that doesn't look like it could really benefit from pre-aggregation with wall-clock boundries | 16:17 |
| lsmola_ | eglynn: cause it is working with present data | 16:17 |
| nadya_ | if statistics for several hours is ok, but if I request stats for several days it is slow | 16:17 |
| jaypipes | oooh, oooh, I have an idea... | 16:17 |
| eglynn | yep alarming is more oriented towards currency ... i.e. the freshest samples over relatively short timescales | 16:18 |
| *** prad_ has quit IRC | 16:18 | |
| lsmola_ | jaypipes: storing cpu_util.hour, .day ? | 16:18 |
| *** prad has joined #openstack-ceilometer | 16:19 | |
| nadya_ | eglynn, what about your example in etherpad, did you read my answer? | 16:19 |
| jaypipes | nadya_: what about this... create some middleware that uses memcache or redis for caching *deterministic interval queries*. For example, if a query comes in for a specific time interval in the past between X and Y, then the middleware would look up a cache entry for X-Y-metername in the cache storage and return it immediately if found. If not found, execute the main query and store in cache. The Glance image ca | 16:19 |
| jaypipes | che middleware I wrote does virtually the exact same thing... | 16:19 |
| eglynn | lsmola_: ... which sounds more like roll-up | 16:19 |
| jaypipes | nadya_: only the Glance image cache middleware uses a disk-based cache instead of memcache, but the idea is the same. | 16:20 |
| eglynn | nadya_: this answer you mean? | 16:20 |
| eglynn | "Yep, everything is correct. But every time 11.00-12.00 will be get from cache. The 'raw' computing will take place only in two corner hours. So if you enlarge period you will get more profit from cache." | 16:20 |
| lsmola_ | eglynn: trying to remember olap terminology | 16:20 |
| lsmola_ | eglynn: yeah | 16:20 |
| nadya_ | eglynn, yes, what i'm missing here? | 16:21 |
| lsmola_ | eglynn: avg will remain same, we will loose local extremes | 16:21 |
| lsmola_ | eglynn: or | 16:22 |
| lsmola_ | eglynn: not | 16:22 |
| nadya_ | jaypipes, need to think about this | 16:22 |
| eglynn | nadya_: ... only one out of every sixty queries from alarming will hit that 11:00->12:00 sweet spot and get any benefit from the pre-aggregation cache | 16:22 |
| jaypipes | we could name the middleware "SweetSpotMiddleware" ;) | 16:23 |
| eglynn | nadya_: ... so alarming wants to know the average over periods that advance one minute every minute | 16:23 |
| nadya_ | eglynn, wait... | 16:23 |
| nadya_ | eglynn: I will write in etherpad | 16:24 |
| eglynn | nadya_: k | 16:24 |
| nadya_ | eglynn: ping | 16:27 |
| eglynn | nadya_: yo | 16:27 |
| nadya_ | eglynn: do you see inlined comments? | 16:27 |
| eglynn | nadya_: a-ha, earlier I didn't notice the inlined ... "here we may use cache 11-12. we may merge request 10.01-11.00, 11.00-12.00 (cache) and 12.00-12.01" | 16:29 |
| nadya_ | eglynn: sorry, I should tell you a line num | 16:29 |
| eglynn | nadya_: k | 16:29 |
| eglynn | nadya_: so is it the "here we may use cache .." comment on line 49 that you want to discuss? | 16:31 |
| nadya_ | eglynn: yes, yes | 16:32 |
| eglynn | nadya_: the thing is ... if we ask for timestamp>=10:01 && timestamp<12:01 with period=3600 | 16:32 |
| eglynn | nadya_: we don't want all the samples from the duration 10:01-12:01 all merged together | 16:32 |
| eglynn | nadya_: instead we want the aggregation of 10:01->11:00:59 and 11:01->12:00:59 to be seperated out into disjoint buckets | 16:33 |
| nadya_ | eglynn: ah, I didn't pay attention to period | 16:33 |
| eglynn | nadya_: does the concern make sense now? | 16:34 |
| lsmola_ | eglynn: so what about the roll up? | 16:37 |
| nadya_ | eglynn: yes. I thought a lot about periods and looks like it is not possible to cache everything | 16:37 |
| eglynn | nadya_: yep agreed, unless the typical start and end times are "clamped" and don't advance minute-by-minute | 16:38 |
| eglynn | lsmola_: roll-up == a related concept where older fine-grained (short period) samples are distilled into coarser-grain (longer period) aggregates | 16:39 |
| nadya_ | eglynn: so we have one more use case - just normal statistics :) | 16:39 |
| openstackgerrit | gordon chung proposed a change to stackforge/pycadf: mask token values https://review.openstack.org/68689 | 16:39 |
| lsmola_ | eglynn: for stats that could be enough | 16:40 |
| eglynn | nadya_: by "just normal statistics" do you mean arbitrary queries not from alarming or charting apps? | 16:40 |
| lsmola_ | eglynn: I could just pick whether i want day, month aggregates | 16:40 |
| nadya_ | eglynn: yes, I'm interested in roll-up too. I thought that hour-aggregated statistics may be kept fot old data | 16:40 |
| nadya_ | and old data may be removed | 16:41 |
| eglynn | yep, the two concepts are related though I think the goals tend to be different | 16:41 |
| eglynn | aggregation makes the common queries faster | 16:41 |
| eglynn | roll-up makes the older data smaller | 16:41 |
| nadya_ | hm, but implementation looks the same, no? | 16:42 |
| eglynn | so roll-up would tend to apply to older data, whereas pre-aggregation need to applier to fresher data also since these data tend to be queried more often | 16:43 |
| eglynn | nadya_: yep, we were hopng for some commonality of implementation | 16:43 |
| nadya_ | I mean except when data is needed to be aggregated | 16:43 |
| nadya_ | looks like we need different managers | 16:43 |
| eglynn | but I think the complexity around shifting/advancing start & end time brackets doesn't impact on roll-up | 16:44 |
| nadya_ | eglynn: yep, agreed | 16:44 |
| eglynn | i.e. roll-up *replaces* the pre-existing data with more coarse-grain distillate | 16:44 |
| nadya_ | lsmola_, sorry I didn't get UI limitations, I mean why agregation is not ok for UI. Sorry, you wrote it on meting but it was too fast | 16:47 |
| eglynn | back in a sec ... | 16:47 |
| lsmola_ | nadya_: np :-) | 16:49 |
| nadya_ | lsmola_, maybe it would be useful to look at UI again. it was rather long time ago | 16:50 |
| lsmola_ | nadya_: there is not much now | 16:51 |
| lsmola_ | nadya_: just one multiline timeseries chart for all meters | 16:51 |
| nadya_ | lsmola_: as I remember there is a chart where user chooses statistics_type, start, end and..? | 16:51 |
| nadya_ | lsmola_: and meter | 16:51 |
| lsmola_ | nadya_: yeah, thats still all | 16:52 |
| lsmola_ | nadya_: i am waiting for some ceilometer features to upgrade that | 16:52 |
| lsmola_ | nadya_: also designers works on some new beautiful overview pages | 16:52 |
| lsmola_ | eglynn: btw. have you checked how to do that 'unique' like aggregation query? | 16:53 |
| nadya_ | and what about periods? hours-aggregates will not help at all? | 16:53 |
| nadya_ | lsmola_: ^^ | 16:54 |
| lsmola_ | nadya_: well if it would be stored as different meters | 16:56 |
| lsmola_ | nadya_: e.g. cpu_util.hour | 16:56 |
| lsmola_ | nadya_: I could work with that I guess | 16:56 |
| lsmola_ | nadya_: cause if I obtain avg,sum,min or max from that, it will be stil lthe same | 16:57 |
| *** yfujioka has quit IRC | 16:58 | |
| eglynn | lsmola_: we don't currently tie a meter's identity to a set period | 16:58 |
| eglynn | lsmola_: ... i.e. the cadence of the data gathering determines the periodicity of the samples | 16:58 |
| lsmola_ | eglynn: i believe i saw that in baremetal stats | 16:59 |
| eglynn | lsmola_: I think that's just a thriw-back to the SNMP style of stats gathering | 16:59 |
| eglynn | *throw-back | 16:59 |
| lsmola_ | eglynn: yeah, here the SNMP makes the aggregation | 16:59 |
| eglynn | lsmola_: ... whereas for "native" ceilo stats, this is kind of implicit | 17:00 |
| lsmola_ | eglynn: ok | 17:00 |
| eglynn | lsmola_: (... as things stand now, though we wanted to change that to make it explicit somehow) | 17:00 |
| ildikov_ | lsomla_: is that 'unique' like aggregation is the one with distinct? | 17:00 |
| eglynn | lsmola_: (... i.e. have the generator of the samples know it's own cadence and record that directly in the sample data) | 17:01 |
| lsmola_ | ildikov_: yeah | 17:01 |
| lsmola_ | ildikov_: I think we didn't figured out how to make such query yet | 17:01 |
| nadya_ | lsmola_: ok, I see | 17:01 |
| ildikov_ | lsomla_: if I remember right, we did not figure out the query itself either | 17:02 |
| eglynn | lsmola_: yep, I haven't time to look into "distinct" queries | 17:02 |
| *** boris-42 has joined #openstack-ceilometer | 17:02 | |
| ildikov_ | or I'm not sure that second version is actually does, what you really eant | 17:02 |
| lsmola_ | eglynn: ok | 17:02 |
| ildikov_ | lsomla_: s/eant/want | 17:02 |
| nadya_ | eglynn: anyway, do you think that "just queries from users or cloud operators" case doesn't worth to create aggregations? | 17:02 |
| lsmola_ | eglynn: do you see something liek that landed in I3? | 17:02 |
| lsmola_ | eglynn: or should I tell the bad news to Horizon :-D | 17:02 |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 17:03 | |
| eglynn | nadya_: that's a good question, it really depends on the typical stats query profile | 17:03 |
| eglynn | nadya_: the two heavy-hitters on the stats API that I'm most familiar with are alarming and charting | 17:04 |
| eglynn | nadya_: ... but there may well be other apps that make repetitive stats queries | 17:04 |
| eglynn | nadya_: ... that would benefit from the style of aggregation you had in mind | 17:04 |
| nadya_ | eglynn: I think filtering mechanism may be useful for users to determine 'query profile' | 17:05 |
| ildikov_ | lsmola_: as for our future implementation for statistics, if we can get somehow the complex query in, then we can figure out, how we can do that query for stats, that you need | 17:05 |
| eglynn | lsmola_: ... I remain optimistic, but have been time-poor of late | 17:05 |
| jaypipes | eglynn: yeah, you and me both :( | 17:06 |
| nadya_ | eglynn, lsmola_ and do we have bp for this? | 17:06 |
| eglynn | nadya_: by "filtering mechanism" do you mean the complex query logic that ildikov_ is working on? | 17:06 |
| nadya_ | eglynn: just hour- or day- aggregate for concrete filters that user wants | 17:06 |
| lsmola_ | nadya_: I believe no | 17:06 |
| lsmola_ | eglynn: ildikov_ ok, understood | 17:07 |
| lsmola_ | running home, see you guys | 17:08 |
| nadya_ | lsmola_: ok, thanks! | 17:08 |
| eglynn | nadya_: well if I understand your BP question, there's also this related one: https://blueprints.launchpad.net/ceilometer/+spec/state-meter | 17:08 |
| eglynn | lsmola_: see ya! | 17:08 |
| eglynn | (I haven't had a chance to think about it in detail yet ...) | 17:09 |
| eglynn | (i.e. that state-meter idea) | 17:09 |
| nadya_ | eglynn: i'll take a look into it too | 17:09 |
| eglynn | cool | 17:09 |
| nadya_ | eglynn: is it clear about filtering? | 17:10 |
| eglynn | nadya_: filtering as a way of profiling query patterns? | 17:10 |
| eglynn | nadya_: ... is that what you meant? | 17:11 |
| nadya_ | eglynn: so it may be any filter from user's config. We store Statistics aggregate with filter that was used for fetching samples | 17:11 |
| nadya_ | eglynn: flattened SampleFilter in db, we have a conversation in review | 17:12 |
| eglynn | nadya_: yep, sure ... I guess that doesn | 17:12 |
| *** tong_ has joined #openstack-ceilometer | 17:12 | |
| eglynn | 't tell us though whether the query filter is "typical" | 17:12 |
| nadya_ | eglynn: need to go now, sorry | 17:13 |
| eglynn | (in the sense of one that's likely to be repeated and thus reap the benefit of having a pre-calculated valued available) | 17:13 |
| eglynn | nadya_: sure, I need to run also very shortly | 17:13 |
| *** lsmola_ has quit IRC | 17:13 | |
| eglynn | nadya_: ... lets continue the conversation tmrw or early next week | 17:13 |
| nadya_ | eglynn: thank you a lot! Ok, will continue | 17:13 |
| eglynn | nadya_: cool, thanks! | 17:14 |
| *** tongli has quit IRC | 17:14 | |
| *** eglynn has quit IRC | 17:14 | |
| openstackgerrit | Ilya Tyaptin proposed a change to openstack/ceilometer: Add table prefix for unit tests with hbase https://review.openstack.org/68698 | 17:15 |
| *** ildikov_ has quit IRC | 17:19 | |
| *** yassine has quit IRC | 17:30 | |
| *** Alexei_987 has quit IRC | 17:48 | |
| *** s2r2_ has quit IRC | 17:54 | |
| *** tong_ has quit IRC | 17:58 | |
| *** tongli has joined #openstack-ceilometer | 18:03 | |
| *** s2r2_ has joined #openstack-ceilometer | 18:04 | |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 18:06 | |
| openstackgerrit | Rob Raymond proposed a change to openstack/ceilometer: Fix some typos in architecture doc https://review.openstack.org/68714 | 18:12 |
| *** nadya__ has joined #openstack-ceilometer | 18:14 | |
| *** nadya__ has quit IRC | 18:29 | |
| *** nadya__ has joined #openstack-ceilometer | 18:29 | |
| *** xmltok has joined #openstack-ceilometer | 18:37 | |
| *** nadya__ has quit IRC | 18:41 | |
| *** nadya__ has joined #openstack-ceilometer | 19:05 | |
| openstackgerrit | Rob Raymond proposed a change to openstack/ceilometer: Fix some typos in architecture doc https://review.openstack.org/68714 | 19:14 |
| *** ruhe is now known as _ruhe | 19:19 | |
| *** ildikov_ has joined #openstack-ceilometer | 19:25 | |
| *** ildikov has joined #openstack-ceilometer | 19:33 | |
| *** nadya__ has quit IRC | 19:43 | |
| *** nadya__ has joined #openstack-ceilometer | 20:04 | |
| *** sayali has quit IRC | 20:04 | |
| *** dhellmann_ is now known as dhellmann | 20:04 | |
| *** tongli has quit IRC | 20:06 | |
| *** adriant has joined #openstack-ceilometer | 20:08 | |
| *** sayali has joined #openstack-ceilometer | 20:10 | |
| *** sayali has quit IRC | 20:17 | |
| *** s2r2__ has joined #openstack-ceilometer | 20:23 | |
| *** s2r2_ has quit IRC | 20:23 | |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 20:28 | |
| *** nadya__ has quit IRC | 20:30 | |
| *** adriant has quit IRC | 20:31 | |
| *** ildikov_ has quit IRC | 20:31 | |
| *** zqfan has quit IRC | 20:31 | |
| *** vkodam has quit IRC | 20:31 | |
| *** ildikov has quit IRC | 20:45 | |
| *** s2r2__ has quit IRC | 21:22 | |
| openstackgerrit | ZhiQiang Fan proposed a change to openstack/ceilometer: Use explicit http error code for api v2 https://review.openstack.org/68775 | 21:28 |
| *** jdob has quit IRC | 21:56 | |
| *** thomasem has quit IRC | 22:05 | |
| *** gordc has quit IRC | 22:47 | |
| *** julienvey_ has quit IRC | 23:05 | |
| *** prad has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!