15:00:27 <rhochmuth> #startmeeting monasca
15:00:28 <openstack> Meeting started Wed Mar 16 15:00:27 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:32 <openstack> The meeting name has been set to 'monasca'
15:00:32 <rhochmuth> o/
15:00:39 <witek> hello
15:00:41 <bklei> o/
15:00:41 <rbrndt> o/
15:00:43 <ho_away> o/
15:01:28 <rhochmuth> i'm sort of out this week on spring break, and haven't been checking up on things
15:01:45 <shinya_kwbt> o/
15:01:52 <rhochmuth> looks like there are several agenda items at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:01:58 <rhochmuth> Agenda for Wednesday March 16, 2016 (15:00 UTC)
15:01:58 <rhochmuth> 1. Periodic metrics support
15:01:58 <rhochmuth> 1.	https://review.openstack.org/292753
15:01:58 <rhochmuth> 2.	https://review.openstack.org/292758
15:01:58 <rhochmuth> 2. monasca-log-api specifiction
15:01:59 <rhochmuth> 1.	https://review.openstack.org/273058
15:01:59 <rhochmuth> 3. vertica/api reduction of inner joins patch
15:02:00 <rhochmuth> 3.1 https://review.openstack.org/#/c/287507/
15:02:46 <rhochmuth> So, i'll go though the list
15:02:56 <rhochmuth> #topic period metrics support
15:03:17 <rhochmuth> i'm assuming that is tomasz
15:03:20 <witek> Tomasz has started working on periodic metrics
15:03:46 <rhochmuth> yes, i see
15:03:55 <rhochmuth> looks like ben is the only reviewer so far
15:03:57 <witek> he doesn't have much experience with monasca-thresh and storm
15:04:18 <fabiog> hi
15:04:26 <rhochmuth> hi fabiog
15:04:36 <rhochmuth> so, i think gettign some eyes on that
15:04:39 <witek> if someone could take a look, we would be very thankfull
15:04:40 <rhochmuth> i wont' review this week
15:04:46 <rhochmuth> but, i'll get back to it next week
15:04:56 <witek> rhochmuth: thanks
15:04:57 <rhochmuth> also our expert in this area craig is alos out htis week
15:05:01 <rhochmuth> on spring break too
15:05:16 <rhochmuth> but when he returns next hopefully he can review too
15:05:25 <witek> great
15:05:35 <rhochmuth> unfortuanately, he is a slacker and doesn't show up to meetings when he is on break
15:05:39 <rhochmuth> :-)
15:05:43 <witek> haha
15:06:06 <rhochmuth> either that or he is smarter than me
15:06:37 <bklei> no comment
15:07:07 <rhochmuth> i guess it isn't a lot of code to make those changes
15:07:14 <rhochmuth> so, the reviews should go prety quickly
15:07:58 <rhochmuth> #topic monasca-log-api specifiction
15:08:19 <rhochmuth> So, it looks like we are trying to wrap-up on, https://review.openstack.org/#/c/273058/
15:08:28 <fabiog> I think is good to go
15:08:40 <rhochmuth> looks like there are several +1s and 2s, so agree
15:08:44 <fabiog> rhochmuth: press the +1 workflow ;-)
15:08:48 <witek> :)
15:09:10 <rhochmuth> so, then i'm assuming tsv will wrap-up the implementation
15:09:17 <rhochmuth> i think he was the last one in there
15:10:05 <rhochmuth> his review is in merge conflict right now, but if we fixes that up, then it should get merged soon
15:10:21 <rhochmuth> as well as making sure the implementation is correct
15:11:01 <rhochmuth> i'm going to let witold merge it
15:11:15 <witek> you mean implementation?
15:11:47 <rhochmuth> actually, i meant the spec, but since you started the spec that wouldn't be best
15:11:50 <rhochmuth> i can +2 it
15:12:01 <rhochmuth> tsv still needs to wrap the implementation
15:12:07 <rhochmuth> assiming he is going to do that
15:13:00 <witek> i can merge the spec if we agree so here
15:13:05 <rhochmuth> i agree
15:13:29 <rhochmuth> one of these days i'll figure out how to do votes in irc
15:13:56 <rhochmuth> #topic vertica/api reduction of inner joins patch
15:14:02 <bklei> that's me
15:14:18 <rhochmuth> yes, i'm assuming you want to get this merged
15:14:20 <bklei> i think it's ready -- anyone disagree?
15:14:21 <rhochmuth> i haven't been able to test
15:14:23 <bklei> yep
15:14:25 <rhochmuth> but the code looks fine
15:14:35 <rhochmuth> rbrandt might be able to help
15:14:41 <rhochmuth> he should be here
15:15:01 <rhochmuth> rbrndt: u there?
15:15:01 <bklei> sounds like he pulled in kaiyan to test
15:15:15 <rbrndt> I tested it a little myself and kayak ran the tempest tests against it
15:15:28 <rbrndt> I was hoping to go over it once more before approving
15:15:37 <bklei> sure -- np
15:15:48 <bklei> thx rbrndt
15:15:58 <rbrndt> apologies to kaiyan whose name apparently auto corrects to kayak
15:16:04 <bklei> :)
15:16:09 <rhochmuth> lol
15:16:40 <rhochmuth> ok, then i'm assuming that will get merged relatively soon
15:16:46 <bklei> sweet
15:16:54 <rhochmuth> #topic https://review.openstack.org/#/c/287507/
15:17:57 <rhochmuth> sorry thought that was a new topic the way the indenting worked out
15:18:07 <rhochmuth> #topic 4. multiple metric and group_by
15:18:28 <rhochmuth> I started this review last wek https://review.openstack.org/#/c/289675/
15:18:38 <rhochmuth> rbrndt is working on it now because i'mout
15:18:59 <rhochmuth> basically, we would like to add a group_by query parameter to the measurmeents and statistics resources
15:19:31 <rhochmuth> initially, we would like to only support "group_by=*", to group_by all unique dimensions
15:19:43 <rhochmuth> this would impact the vertica and influxdb repos
15:19:56 <bklei> early testing of it was good at TWC -- rbrndt ping me when more baked and i'll retest
15:19:59 <rhochmuth> the goal is to return multiple metrics in a single query
15:20:08 <rhochmuth> did you look at performance
15:20:28 <bklei> no -- just in my sandbox, that'd be tough until it merges and deploys
15:20:41 <bklei> but it's gonna scream by design :)
15:20:49 <rhochmuth> so, is everyone ok with this change
15:21:05 <rhochmuth> i don't think we submitted a blueprint to explicitly cover what this is about
15:21:23 <rhochmuth> but the review is in progress, although will probably be a couple of weeks until it is complete
15:21:52 <rhochmuth> does anyone want to discuss further?
15:22:10 <rhochmuth> the reasons/motiviation for the change, the syntax, ...
15:22:39 <rhochmuth> implications, …
15:23:17 <witek> I haven't take a look before, but please explain
15:23:46 <rhochmuth> currently, when querying measurments or statistics, only one metric is returned
15:24:05 <rhochmuth> you can use the merge_metrics, to merge metrics, but in that case, it is still "one metric"
15:24:40 <rhochmuth> we are starting to see that this is becoming a performance bottleneck
15:25:27 <rhochmuth> for example, at twc where they are displaying multiple vm metrics per tenant, let's say 10-20 VMs, and 10 separate graphs, that results in 100-220 separte queries of the API
15:25:41 <rhochmuth> There is also a use case that we are seeing in Ceilosca
15:26:12 <rhochmuth> the group_by parameter will allow you to get multiple independent metrics back in a single query
15:26:33 <rhochmuth> we would like to support group_by=region, zone, hostname, ...
15:26:51 <rhochmuth> where region, zone, hostname are dimension keys/names
15:27:02 <bklei> once ^^ merges, rbak will make some corresponding grafana2 changes to parse the multiple metrics returned
15:27:05 <rhochmuth> in the short-term however, we would just like to support group_by=*
15:27:09 <fabiog> rhochmuth: would the group_by allow several params in a single group or is only ine?
15:27:21 <rhochmuth> where "*" is a wildacard for all dimensions
15:27:39 <rhochmuth> in other words, return all the unique metrics
15:27:59 <shinya_kwbt> that's interesting
15:28:06 <rhochmuth> it would allow several, fabiog
15:28:15 <rhochmuth> that is the end-goal, anyway
15:28:20 <fabiog> rhochmuth: ok
15:28:37 <rhochmuth> so, the review is up and you can follow the progress of it
15:28:44 <rhochmuth> and comment on it
15:29:03 <rhochmuth> i'm expecting a very significant performance increase as a result
15:29:12 <rbak> rhochmuth: Any idea what the timeline for supporting params other than * would be?
15:29:30 <rhochmuth> rbrndt: u there still?
15:30:02 <fabiog> rhochmuth: is only java, is still WIP or no plans to add Python?
15:30:12 <rhochmuth> we will add python too
15:30:27 <rbrndt> I'm still here
15:30:27 <rhochmuth> goal is too support java/python influxdb and vertica
15:30:30 <rhochmuth> all variations
15:30:43 <fabiog> btw, are we supporting Influx 0.10?
15:30:58 <rhochmuth> rbrndt: now that you've looked at this for a couple of days, do you have a time-line
15:31:13 <rhochmuth> for the complete java/python vertica/influxdb implementation?
15:31:21 <rhochmuth> no pressure
15:31:32 <rbrndt> I've begun work on the pagination issues we discussed for vertica, so I expect that will be done or close to done today
15:31:47 <rbrndt> I have some idea about the influx implementation, but I've yet to test them
15:32:02 <rhochmuth> so, 2-3 weeks maybe
15:32:03 <rbrndt> The python should follow pretty easily once the java is done
15:32:21 <rbrndt> I would say 2 would be sufficient to get a pretty good attempt done
15:32:44 <rhochmuth> so, it will be past the mitaka release date
15:33:10 <rbrndt> mostly likely
15:33:13 <rhochmuth> anymore questions on that topic
15:33:31 <rhochmuth> witek: did that answer your questions?
15:33:34 <jobrs> what about cassandra support?
15:33:55 <witek> yes, I have an idea :)
15:34:08 <rhochmuth> jobrs:  let's talk about next, related to the influxdb discussion
15:34:12 <rhochmuth> thanks witek
15:34:28 <rhochmuth> let me know if you have any further questions, and please comment on review if any conerns
15:34:44 <rhochmuth> #topic infuxdb 0.10.X
15:34:48 <jobrs> you were just mentioning influx and vertica above. influxdb will stop giving away versions with cluster support for free soon.
15:35:11 <rhochmuth> mhoppal, are you there
15:35:16 <mhoppal> yes here
15:35:24 <rhochmuth> jobrs: oh no
15:35:54 <rhochmuth> so, we've been doing a lot of influxdb analyis again
15:35:59 <jobrs> definitely
15:36:01 <rhochmuth> mhoppal can give an update
15:36:06 <shinya_kwbt> that too bad ;-(
15:36:21 <mhoppal> yes so we run some scale testing with influx 9.5 and the new version of 10
15:36:40 <mhoppal> looking to see if there were any differences between the two
15:37:04 <mhoppal> we saw a significant improvements in 10
15:37:40 <mhoppal> we are still going through the testing but have scaled 10 up to around 9000 measurements per a second
15:37:42 <bklei> is that clustered -- or single node?
15:37:45 <mhoppal> clustered
15:37:47 <jobrs> which storage engine?
15:37:50 <mhoppal> tsm
15:37:54 <mhoppal> for 10
15:37:59 <rhochmuth> tsm is default in 10
15:38:02 <mhoppal> yes
15:38:15 <rhochmuth> how is stability?
15:38:24 <mhoppal> great
15:38:40 <rhochmuth> how is disk utilization?
15:38:51 <mhoppal> about 10x better then 9.5
15:39:23 <rhochmuth> so, disk utilization is 1/10
15:39:33 <mhoppal> also in 9.5 we run into issues geting past 5000 measurements per a second we were recieving timeouts from influxdb and 10 had no issues with that
15:39:35 <mhoppal> and yes
15:40:10 <rhochmuth> so, summary, performance is looking good, hitting 9000 metrics/sec in test, but we haven't pushed harder yet
15:40:15 <rhochmuth> stability is great
15:40:25 <mhoppal> yes we are going to push it up further
15:40:30 <rhochmuth> compression is 10X better that 0.9.5
15:40:31 <mhoppal> and then start to do ha fail over testing
15:40:35 <mhoppal> but it is looking a lot better
15:40:40 <christian_> did you test failure scenarios like split brain, remove one node and bring it back into the cluster?
15:40:48 <rhochmuth> additioanlly, compressions is 2X better than vertica
15:40:49 <mhoppal> and the memory is a lot better as well
15:41:01 <mhoppal> we have not done much failure scenarios yet
15:41:05 <mhoppal> in the plan for the next week
15:41:30 <rhochmuth> christian_: we've done some initial ha testing, but more is planned
15:41:37 <rhochmuth> so far, we haven't seen any issues
15:41:50 <christian_> thanks...please keep us up to date :-)
15:42:08 <rhochmuth> so, based on that, we are rethinking our work on Cassandra
15:42:28 <rhochmuth> jobrs: do you have a link on the clustering
15:42:58 <bklei> you mean moving up or pushing out work on cassandra?
15:43:14 <jobrs> https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
15:43:21 <bmotz> I was just about to post that...
15:43:30 <jobrs> sry
15:43:40 <bmotz> no problem! :)
15:43:47 <bmotz> it was just to say that we are rethinking our plans around Influx
15:44:13 <bmotz> support is priced around $500/server/month
15:44:14 <bmotz> https://influxdata.com/pricing/#product-subscriptions
15:44:55 <jobrs> cassandra scaleability may be another pro (after looking at what netflix is doing with it)
15:45:26 <rhochmuth> the reason why we started with cassandra is due to the problems with influxdb
15:45:43 <rhochmuth> now that influxdb is looking good, we have much less of a reason to do cassandra
15:45:59 <bmotz> are there any blueprints or specs about the Cassandra thoughts?
15:46:04 <rhochmuth> we still haven't made the final decision thgouth
15:46:17 <rhochmuth> there is a cassandra blueprint
15:46:33 <bklei> does the fact that clustering won't be free with influxdb add another dimension to the cassandra support decision rhochmuth?
15:46:43 <rhochmuth> yes it does
15:46:57 <jobrs> this is what they plan exactly: "Next week we’ll be cutting the first release candidate for the 0.11.0 release. While this release includes significant improvements in the query engine and the clustering code base, it will be the last open source version that includes clustering."
15:47:14 <rhochmuth> that is really bad news
15:47:58 <jobrs> but two maintenance releases are released before at least (0.10.3 and 0.11)
15:48:10 <bmotz> I've been pointed towards KairosDB, which is built on Cassandra, but I haven't had a chance to look yet
15:48:26 <rhochmuth> i'll read the post more thoroughly after this meeting
15:48:56 <rhochmuth> maybe we should fork influxdb?
15:49:57 <rhochmuth> thanks mhoppal for the update
15:50:05 <mhoppal> of course
15:50:10 <rhochmuth> #topic Shinya's notification methods
15:50:19 <shinya_kwbt> that's me
15:50:31 <rhochmuth> thanks for the review
15:50:45 <rhochmuth> i just wanted to give you change to let folks know what you are working on
15:50:59 <bmotz> thanks
15:51:23 <shinya_kwbt> Im planning to change pagination style to Horizon style.
15:51:48 <shinya_kwbt> This needs sort parameter to api. So I added.
15:52:08 <rhochmuth> and this applies to notification methods?
15:52:09 <shinya_kwbt> Im writing selenium integration test.
15:52:35 <shinya_kwbt> Alarm Defs and Alarms already have sort parameter.
15:53:33 <rhochmuth> thanks
15:53:40 <shinya_kwbt> It is difficult for me to write selenium test for current implementation of pagination.
15:54:39 <shinya_kwbt> So I planned to change pagination style.
15:54:58 <rhochmuth> the paginiation style changes impact the monaca-ui
15:55:02 <rhochmuth> correct?
15:55:48 <shinya_kwbt> yes Horizon standard style.
15:56:07 <shinya_kwbt> It is able to change num of list.
15:56:15 <shinya_kwbt> By setting page.
15:56:47 <shinya_kwbt> Current implementaion is hard corded 10.
15:57:35 <shinya_kwbt> If big screen you have, it is convinient.
15:58:15 <rhochmuth> ok, will checout out the review
15:58:20 <rhochmuth> probably need to wrap-up
15:58:40 <rhochmuth> one other think, i'll be applying tags for the mitaka release in the next week or two
15:58:59 <rhochmuth> tags need to be applied by March 31st,
15:59:17 <rhochmuth> this will be the first "official" monasca release in-sync with openstack
15:59:42 <rhochmuth> so, we need to be careful about stability risky changes
15:59:48 <rhochmuth> for the next couple of weeks
16:00:07 <rhochmuth> ok, eveyrone meeting is done
16:00:13 <rhochmuth> it always creeps up to fast
16:00:15 <rhochmuth> bye
16:00:20 <bklei> cya
16:00:21 <witek> thanks Roland
16:00:22 <rbrndt> bye
16:00:26 <witek> bye
16:00:29 <ho_away> thanks & bye
16:00:40 <rhochmuth> #endmeeting