14:00:17 #startmeeting monasca 14:00:18 Meeting started Wed Aug 2 14:00:17 2017 UTC and is due to finish in 60 minutes. The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:20 o/ 14:00:22 The meeting name has been set to 'monasca' 14:00:51 hello 14:00:57 hello 14:01:04 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 14:01:41 looks like a small set of attendees today 14:02:00 #topic EOL stable/mitaka for monasca-ceilometer 14:03:48 joadavis: we are on your topic now 14:03:58 great. :) 14:04:47 Basically, we should have all monasca-* services in line with EOL for mitaka. for monasca-ceilometer, I think there is just an approval needed to proceed 14:04:48 so it looks like you want to EOL stable/mitaka for monasca-ceilometer 14:05:06 so, are you just looking for a +1 on the review 14:05:37 yes, I think that is what is needed 14:06:02 aagate: Is there anything else? 14:06:04 rhochmuth: if you can reply to email that Andreas Jaeger sent that will be great cc: openstack-infra dist 14:07:42 I think they want to make sure that PTL is fine with the change 14:08:34 ok, i was trying to find that in my email backlog, but will work on it after we close 14:08:41 sorry for the delay 14:09:07 rhochmuth: np..thank you! 14:09:13 #topic Review request for Monasca Cassandra DB integration initial proposal 14:10:12 great :-). we've completed the first phase of investigation and have a proposal drafted at: https://etherpad.openstack.org/p/cassandra_monasca 14:10:41 I have started reading, but I'm not through yet 14:12:12 the metric upsert and read query seem to be reasonable in our testing. Upsert ranges from 80k to 250k per second with a single Java client on a two node cluster. 14:12:55 ok, i'm going to have to read this off-line too 14:13:38 rhochmuth and Witek: that'd great. We need help to poke holes in it :-). 14:13:46 It is an impressive amount of work Jgu and team have been doing, and I hope it can be of benefit to the monasca community. More reviews will be appreciated. 14:14:09 have you tested query perf with lots of different metric/dimension combinations? 14:14:10 not like we have not got help Roland and Joel already :-) 14:14:45 witek: are you asking about the read queries? 14:14:50 yes 14:16:05 yeah, me reading this now is not helping 14:16:08 we tested the read queries with some combinations. and they all seem to be very fast, because all based on the full Cassandra partition key(s). 14:16:11 it will take a while to digest 14:16:53 are you doing any buffering? 14:17:01 are you doing any compression? 14:17:20 witek: anything specific combinations you are concerned about? 14:17:50 just a number of unique metrics/dimensions 14:19:07 rhochmuth: no we have not tested with compression yet. it's said compression won't impact write. 14:19:51 witek: you mean a large number of unique metrics in the measurement query? 14:21:16 yes, the query which results in many unique metrics across partitions 14:22:14 there are a couple of caveats in the model: the measurement query becomes a two stage query. First find the metric ids by metric name and dimension combinationl then query measurements with time criteria in the measurement table. 14:23:30 also query metric name by dimensions needs a client side join. since we have limited number of metric names (~600?), the client side join in Java code won't be too bad. 14:25:00 witek: the measurement table partition is per metric id, so we are still search by partition keys using the IN operator when there are a number of unique metric/dimension combinations. 14:25:58 IN operator has an upper limit of 65k, but hope our user won't query for measurements for that many unique metrics at one time? 14:28:57 Roland and Witek: should I set up an "offline" meeting with you and others interested? 14:29:12 possibly 14:29:24 i would like to just review off-line first 14:29:33 It would be great 14:29:52 so, can we end the meeting today 14:30:04 rbrndt was also involved in the initial investigation 14:30:07 yes for me :-) 14:30:18 Ryan? 14:30:28 right, ryan brandt 14:30:32 yup 14:30:45 I'll forward it to Ryan. 14:30:55 he is already here :-) 14:31:26 thanks Roland, Witke and Ryan 14:31:27 ok, i'm going to end this meeting 14:31:32 #endmeeting