14:00:17 <rhochmuth> #startmeeting monasca
14:00:18 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <rhochmuth> o/
14:00:22 <openstack> The meeting name has been set to 'monasca'
14:00:51 <witek> hello
14:00:57 <rhochmuth> hello
14:01:04 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
14:01:41 <rhochmuth> looks like a small set of attendees today
14:02:00 <rhochmuth> #topic EOL stable/mitaka for monasca-ceilometer
14:03:48 <witek> joadavis: we are on your topic now
14:03:58 <joadavis> great. :)
14:04:47 <joadavis> 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 <rhochmuth> so it looks like you want to EOL stable/mitaka for monasca-ceilometer
14:05:06 <rhochmuth> so, are you just looking for a +1 on the review
14:05:37 <joadavis> yes, I think that is what is needed
14:06:02 <joadavis> aagate: Is there anything else?
14:06:04 <aagate> rhochmuth: if you can reply to email that Andreas Jaeger sent that will be great cc: openstack-infra dist
14:07:42 <aagate> I think they want to make sure that PTL is fine with the change
14:08:34 <rhochmuth> ok, i was trying to find that in my email backlog, but will work on it after we close
14:08:41 <rhochmuth> sorry for the delay
14:09:07 <aagate> rhochmuth: np..thank you!
14:09:13 <rhochmuth> #topic Review request for Monasca Cassandra DB integration initial proposal
14:10:12 <jgu> 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 <witek> I have started reading, but I'm not through yet
14:12:12 <jgu> 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 <rhochmuth> ok, i'm going to have to read this off-line too
14:13:38 <jgu> rhochmuth and Witek: that'd great. We need help to poke holes in it :-).
14:13:46 <joadavis> 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 <witek> have you tested query perf with lots of different metric/dimension combinations?
14:14:10 <jgu> not like we have not got help Roland and Joel already :-)
14:14:45 <jgu> witek: are you asking about the read queries?
14:14:50 <witek> yes
14:16:05 <rhochmuth> yeah, me reading this now is not helping
14:16:08 <jgu> 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 <rhochmuth> it will take a while to digest
14:16:53 <rhochmuth> are you doing any buffering?
14:17:01 <rhochmuth> are you doing any compression?
14:17:20 <jgu> witek: anything specific combinations you are concerned about?
14:17:50 <witek> just a number of unique metrics/dimensions
14:19:07 <jgu> rhochmuth: no we have not tested with compression yet. it's said compression won't impact write.
14:19:51 <jgu> witek: you mean a large number of unique metrics in the measurement query?
14:21:16 <witek> yes, the query which results in many unique metrics across partitions
14:22:14 <jgu> 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 <jgu> 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 <jgu> 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 <jgu> 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 <jgu> Roland and Witek: should I set up an "offline" meeting with you and others interested?
14:29:12 <rhochmuth> possibly
14:29:24 <rhochmuth> i would like to just review off-line first
14:29:33 <witek> It would be great
14:29:52 <rhochmuth> so, can we end the meeting today
14:30:04 <witek> rbrndt was also involved in the initial investigation
14:30:07 <jgu> yes for me :-)
14:30:18 <jgu> Ryan?
14:30:28 <rhochmuth> right, ryan brandt
14:30:32 <rbrndt> yup
14:30:45 <jgu> I'll forward it to Ryan.
14:30:55 <jgu> he is already here :-)
14:31:26 <jgu> thanks Roland, Witke and Ryan
14:31:27 <rhochmuth> ok, i'm going to end this meeting
14:31:32 <rhochmuth> #endmeeting