15:01:16 <rhochmuth> #startmeeting monasca
15:01:16 <openstack> Meeting started Wed Mar 23 15:01:16 2016 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:20 <openstack> The meeting name has been set to 'monasca'
15:01:40 <shinya_kwbt_> o/
15:01:42 <rhochmuth> o/
15:01:43 <rbak> o/
15:01:44 <Kamil> o/
15:01:46 <hosanai> o/
15:01:52 <bmotz> o/
15:02:01 <tomasztrebski> o/
15:02:05 <bklei> o/
15:02:23 <rhochmuth> Meeting agenda is posted at, https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:02:31 <rhochmuth> Agenda for Wednesday March 23, 2016 (15:00 UTC)
15:02:31 <rhochmuth> 1. Horizon updates for Grafana 2
15:02:31 <rhochmuth> https://review.openstack.org/#/c/295983/
15:02:31 <rhochmuth> 3. Periodic metrics
15:02:31 <rhochmuth> 3.1 Initial state for sparse metrics? AlarmState.OK ?
15:02:32 <rhochmuth> 3.2 Value for sparse (period < 0) metrics? Force 1.0 as value, or leave it to be specified elsewhere ?
15:02:32 <rhochmuth> 3.2.1 Using aggregate functions when it comes to sparse metrics?
15:02:33 <rhochmuth> 3.3 Should period be forced to -1 always ?
15:02:33 <rhochmuth> 3.4 Should alarm transition to AlarmState.OK in next cycle in case there were no metrics collected, given that previously it was AlarmState.ALARM? => for sparse only
15:02:34 <rhochmuth> 3.5 SubAlarm#getExpression#getPeriod  - logic behind, could it be somehow reused or is it something different at all?
15:02:34 <rhochmuth> 4, Mitaka release update and tagging
15:02:35 <rhochmuth> 5. InfluxDB 10.X update
15:03:13 <rhochmuth> so, let's start with the grafana 2 update
15:03:18 <rhochmuth> #topic grafana 2
15:03:35 <rbak> I don't have too much at the moment.
15:03:47 <rhochmuth> i saw the review that you posted
15:03:51 <rbak> I put up a patch for monasca-ui changes for grafana 2.
15:04:09 <rhochmuth> i haven't tested, but I think it would be great to convert over
15:04:16 <rhochmuth> hpe isn't the primary user of the ui anymore
15:04:30 <rhochmuth> so, this would be up to other orgs to approve
15:04:40 <rbak> I'm not sure who else is using the ui
15:04:42 <rhochmuth> also, your review is referencing your twc repos
15:04:57 <rbak> Yes, since that's where monasca is at the moment.
15:04:59 <rhochmuth> fujitsu, nec, sap, ...
15:05:03 <rbak> grafana, not monasca
15:05:27 <rhochmuth> true
15:05:37 <rhochmuth> i think they are all interested in your grafana changes
15:05:45 <rhochmuth> but i'm not sure if they are using
15:05:50 <rhochmuth> sap seemed very interested
15:06:07 <rhochmuth> i believe joachim was looking at it
15:06:15 <bmotz> we're using it, and interested in the Grafana 2 update at some point - I'll try to have a look at the patch
15:06:24 <tgraichen> maybe just a little note from your side: darran hague from our team has added some more functionality to the grafana2 keystone stuff like syncing roles from keystone to grafana
15:06:40 <rhochmuth> thanks bmotz
15:06:43 <rhochmuth> thanks traichen
15:06:57 <tgraichen> as far as i know ryan also implemented something like this and darran and ryan will try to merge their changes together somehow
15:07:02 <rhochmuth> shinya, are you looking at grafana 2
15:07:22 <shinya_kwbt_> Sorry not yet
15:07:28 <rhochmuth> thx
15:07:29 <rbak> tgraichen: Send me an email about those changes.  I think we might have some overlap
15:07:49 <shinya_kwbt_> I will try
15:07:50 <tgraichen> i rbak: arran will contact you i think
15:07:58 <rbak> sounds good
15:08:12 <rhochmuth> rbak: have you tested the devstack deploy
15:08:23 <rhochmuth> with your ui/grafana changes?
15:08:59 <rbak> It passed the testing, but I  haven't tested in devstack.
15:09:18 <rhochmuth> it would be really nice to see this integrated in devstack
15:09:25 <rbak> Grafana requires building the packages yourself, so the monasca-ui links aren't going to work by default in devstack.
15:09:49 <rhochmuth> you can actually do a build in devstack
15:09:57 <rhochmuth> we build the jave projects i beleive
15:10:04 <rbak> I'll look into it
15:10:20 <rhochmuth> the last time i tried the devstack build, horizon wasn't working for me
15:10:34 <rhochmuth> so, it could have been somethign was out-of-sync
15:10:35 <rbak> monasca-ui, or horizon in general?
15:10:45 <rhochmuth> horizon in general
15:11:12 <rhochmuth> anyway, i'l kinda anxious to get all this working in-time for the summit
15:11:27 <slogan> did it generate a traceback or was some functionality just not working quite right?
15:11:43 <rhochmuth> it generated a django traceback
15:11:50 <slogan> that would be nice to see
15:11:56 <rhochmuth> not sure what i did with the error
15:12:13 <rhochmuth> i'll try again
15:12:22 <shinya_kwbt> I also want see traceback
15:12:51 <slogan> and some general steps that lead to the traceback if possible (standard stuff I know)
15:13:20 <rhochmuth> ok, i'll try and get one, but can't do right now
15:14:46 <slogan> early april I'm going to be putting together demos with broadview that will involve some amount of using monasca-ui grafana, if I see any bugs I'll report them (or fix them)
15:14:59 <rhochmuth> rbak: do you have any status update on whether they are going to accept your changes?
15:15:09 <rhochmuth> slogan: thanks
15:15:22 <rbak> rhochmuth: That's not looking good at the moment.
15:15:31 <rhochmuth> ohh, what happened?
15:16:11 <rbak> We had a lot of communication for a while, and had a plan for moving forward, but then they just disappeared.
15:16:35 <rbak> I haven't heard anything for a while now.  We're trying to get in touch again.
15:17:00 <rbak> I'll give an update when I know more.
15:17:03 <rhochmuth> ok, thanks
15:17:22 <rhochmuth> so, i guess we';; have to use your repos
15:17:53 <rbak> for the moment anyway.
15:19:06 <rhochmuth> well, anyway, just want to reitterate it would be nice to see this running in the devstack environment...
15:19:12 <rhochmuth> i guess next topic
15:19:50 <rhochmuth> #topic Periodic metrics
15:20:06 <tomasztrebski> that's on me, lots and lots of questions :)
15:20:26 <rhochmuth> we might need to schedule a meeting on this one and get Craig involved
15:20:35 <rhochmuth> i started to review last night
15:20:54 <rhochmuth> and then craig told me he wasn't sure the direction you were headed was going to work
15:21:06 <rhochmuth> so, it is probably best to have some one-on-one time with him
15:21:14 <rhochmuth> but, you are free to ask away
15:21:24 <rhochmuth> if it is not too technical
15:21:28 <rhochmuth> i'm a ptl you know
15:21:32 <slogan> lol
15:21:42 <rhochmuth> thanks slogan
15:21:58 <tomasztrebski> you're tough :) and my questions are not technical
15:22:08 <rhochmuth> ok
15:22:12 <rhochmuth> please proceed
15:22:15 <tomasztrebski> more or less I have couple points where I am not exactly sure where to go with implementation
15:22:26 <rhochmuth> ok
15:22:47 <tomasztrebski> so, first of all for sparse metric, I've been thinking what should be the initial state the alarm should enter
15:23:00 <tomasztrebski> till now it was UNDETERMINED, right ?
15:23:04 <rhochmuth> correct
15:23:05 <tomasztrebski> but it was for periodic metrics
15:23:09 <rhochmuth> right
15:23:26 <tomasztrebski> should stay the same at least till first measurements are received ?
15:23:42 <rhochmuth> it probably makes sense that a sparse metric would transition immediately
15:24:20 <rhochmuth> the alarm doesn't exist until the first metric is received
15:24:43 <tomasztrebski> well, I've been testing it a bit and until first data arrives it stays with initial state UNDETERMINED
15:25:01 <rhochmuth> in he case of a period metric, it doesn't transition until after it has received some number of metrics
15:25:26 <rhochmuth> so, the alarm is created when the first metric is received in the undetermined state
15:25:39 <slogan> lazy instantiation
15:25:53 <rhochmuth> then some number of metrics will need to be sent, until the threshold engine "has enough"
15:26:09 <rhochmuth> then it will transition to ok or alarm
15:26:14 <tomasztrebski> yes
15:26:56 <tomasztrebski> ok, IMHO it is better to put this to OK at once
15:27:00 <rhochmuth> but in the case of a sparse metric, it should transition when the alarm is created
15:27:03 <rhochmuth> i agree
15:27:13 <rhochmuth> at least in the sparse case
15:27:37 <rhochmuth> it should transiiton to the ok or alarm state
15:27:43 <tomasztrebski> yes, because for periodic it should stay the same with one exception (if metric would come with period > 0, that value should be used)
15:28:00 <tomasztrebski> *the behaviour should stay the same, I mean
15:28:07 <rhochmuth> correct
15:28:44 <tomasztrebski> ok, so if nobody has any objections, let's move on, I don't want to spend too much time asking ;-)
15:28:58 <tomasztrebski> next questions is for values of "value" and "period"
15:29:08 <rhochmuth> ok
15:29:43 <tomasztrebski> for value I am not sure what should be the value, just make it 1.0 and stick to it or let any agent to set it on its own, but I'd rather think that it should be specified outside of the threshold engine (i.e. monasca-agent)
15:30:08 <tomasztrebski> I mean metric['value'] ;-0
15:30:22 <tomasztrebski> and that's also question for sparse metrics only
15:30:24 <rhochmuth> i'm not sure i follow
15:30:34 <rhochmuth> the value is sent for a sparse metric
15:31:09 <rhochmuth> so the value would normally just be the value of the last metric sent
15:31:42 <tomasztrebski> mhm, yeah but it was better to ask, I got little lost in threshold engine but I need to come up with something at least testable
15:32:25 <rhochmuth> i don't think using the avg function is useful for sparse metrics
15:33:57 <tomasztrebski> maybe not, I am not sure right now, but if it wouldn't make sense, we would need to modify logic somewhere to store period and in the same time do the same in monasca-ui to display only those functions that make sense
15:35:08 <rhochmuth> that is a possiblity, but a lot more invasive
15:35:22 <rhochmuth> i think the usage of the metric is implicit in the metric
15:35:27 <rhochmuth> not explicit
15:35:37 <tomasztrebski> so the question would be what functions are not suitable, if any...but maybe that's not the right time to debate over this, I will put this in the agenda that will give some time to think over this
15:36:51 <rhochmuth> so for a sparse metric, raking the avg over the last 5 minutes or hour, either doesnt' make sense, ir it is just the last value that was sent,
15:37:04 <rhochmuth> unless multiple metrics were sent in the last time period
15:37:44 <tomasztrebski> maybe if you would like set the metric (as we need in alarm-on-logs) to establish avg amount of logs from entire system, maybe that would make sense
15:37:55 <tomasztrebski> *set the alarm
15:38:09 <rhochmuth> so, i'll talk to craig and will try and setup something with you to discuss implementation details further
15:38:13 <rhochmuth> does that sound ok
15:39:04 <tomasztrebski> yes, I will keep the rest of the questions for that meeting
15:39:10 <rhochmuth> ok, thanks
15:39:26 <rhochmuth> #topic mitaka
15:39:40 <rhochmuth> we are coming up on the mitaka final release
15:39:52 <rhochmuth> i'll need to apply tags to all the monasca repos over the next few days
15:40:11 <rhochmuth> we have a number of reviews in flight, mainly focused on bugs and performance improvmenets
15:40:22 <rhochmuth> so, i would like to just focus on those for the next few days
15:40:33 <rhochmuth> in general, our master branch is always in excellent shape
15:40:52 <rhochmuth> so, i'm planning on moving tags to top of master by the end of the week
15:41:05 <rhochmuth> please heop out with reviews and testing if possible
15:41:15 <rhochmuth> as this is our first major release with monasca
15:41:22 <rhochmuth> official release that is
15:41:44 <rhochmuth> if anyone knows of anything that needs to be or shoudl be adressed pleae let me know
15:41:52 <slogan> how does one gauge the priority of one review over another?
15:42:07 <slogan> I recall when I was involved with neutron there would be a list somewhere
15:42:42 <rhochmuth> bugs and performance enhancements are usually priortized above features
15:42:50 <rhochmuth> we dont' have an active list like neutron
15:43:07 <slogan> this priority is in the bug system (noob question)
15:43:19 <rhochmuth> possibly
15:43:23 <slogan> ok
15:43:50 <rhochmuth> we also have bugs that are reported by our representative orgs, like hpe
15:44:21 <slogan> there is some convention, like the commit message specifies the bug URI, or number?
15:44:43 <rhochmuth> correct, we use that when bugs are reported via launchpad
15:44:51 <slogan> ok, cool
15:45:08 <rhochmuth> but sometimes bugs are jsut fixed, without a corresponding launchpad number
15:45:30 <rhochmuth> i'm probably violating some openstack rule somewhere
15:45:31 <slogan> I guess then it is a matter of using the mailing list or IRC to get people aware of severity
15:45:44 <rhochmuth> yes, that is what we've been doing
15:45:52 <rhochmuth> it is often teh sequeky whell principle
15:46:01 <rhochmuth> but if a review has been sitting around for a while
15:46:12 <rhochmuth> usually just brining it up here is enoguht to get some attention to it
15:46:33 <rhochmuth> sometimes reviews sit around a while because they are difficult to test
15:46:38 <rhochmuth> or don't seem that important
15:46:43 <slogan> nod
15:46:51 <rhochmuth> or folks are working on there own problems
15:47:04 <rhochmuth> but if it is raised here, usually someone gets to it
15:47:09 <slogan> just to be clear, any bugs I file will be priority 1 :-P
15:47:15 <rhochmuth> i sometimes have to poke people here
15:47:21 <rhochmuth> haha
15:47:40 <rhochmuth> ok, hopeflly that is enough on that topic
15:47:54 <rhochmuth> we have around 10 minutes
15:48:00 <rhochmuth> i was going to give an influxdb update
15:48:12 <rhochmuth> but if there is something elese that is pressing please let me know
15:48:30 <tomasztrebski> influx is pressing to stop releasing db for free...
15:48:38 <rhochmuth> tomasz: you can probably merge your review that deprecates the v2.0 log api
15:48:47 <slogan> I've sent you e-mail about the summit and we can do that over e-mail if you like, I assume some rooms etc. were approvided
15:48:52 <slogan> er, approved
15:49:11 <rhochmuth> slogan: i don't know yet, but i'll get with you over email
15:49:17 <rhochmuth> i'm still recovering from last week
15:49:18 <slogan> perfect
15:49:25 <rhochmuth> mabe i shouldn't take off anymore
15:49:34 <slogan> I was thinking that...
15:49:38 <tomasztrebski> roland: ok, I will try to do this, I have one other thing to commit but once it is ready I'll just publish it
15:49:40 <slogan> :-)
15:49:56 <rhochmuth> tomasz: cool, i'm just trying to get this into the mitaka release
15:50:04 <rhochmuth> and time is running out
15:50:19 <rhochmuth> although, we did merge the latest v3.0 code
15:50:24 <rhochmuth> so that is in good shape
15:50:30 <rhochmuth> i'll look for your changes
15:51:12 <rhochmuth> #topic influxdb
15:51:25 <rhochmuth> so, we had a discussion with them yesterday
15:51:51 <rhochmuth> they are going to review to see if they come up with anything that would meet the requirement for an open-source ha influxdb
15:52:14 <rhochmuth> i was wondering what other s thoguht about this announcement
15:52:17 <rhochmuth> and the impact
15:52:44 <bmotz> we're more concerned about the clustering
15:53:00 <rhochmuth> that is what i meant by the ha
15:53:12 <bmotz> ah, ok :)
15:53:18 <rhochmuth> basically, clustering in influxdb will be closed source
15:53:46 <bklei> from what paul said, the free product without clustering will support HA, and ~400 metrics/sec
15:53:54 <bklei> sorry -- 400K :)
15:54:26 <rhochmuth> it is poor man's ha
15:54:35 <bmotz> in the medium term we're looking at scaling to data rates an order of magnitude or three above that...
15:54:35 <rhochmuth> basially replication to another influxdb instance
15:54:40 <bklei> basically duplicate writes
15:54:44 <bklei> yup
15:54:50 <rhochmuth> which we can already do in monasca using kafka and the persister
15:55:06 <rhochmuth> correct, duplicate writes
15:55:17 <rhochmuth> so, that implies databases coudl get out of sync
15:55:23 <bklei> for sure
15:55:33 <bklei> you get what you pay for :)
15:55:34 <rhochmuth> kafka occers a certain amount of protection,
15:55:42 <rhochmuth> yeah, i can't argue that
15:55:55 <rhochmuth> from an hpe perspective, vertica is superior to influxdb
15:56:04 <fabiog> from which version the clustering will be close source?
15:56:10 <fabiog> 0.11?
15:56:10 <rhochmuth> it's only issue was that it is closed source
15:56:15 <bmotz> and Vertica has a clearer pricing struture!
15:56:15 <rhochmuth> 0.12
15:56:37 <bklei> and vertica is free up to 1TB?
15:56:48 <rhochmuth> i'm sure vertica is clearer, and proabbly more expensvie, after the 1TB limit
15:57:12 <bklei> does the free vertica < 1TB allow clustering?
15:57:16 <rhochmuth> yes
15:57:35 <rhochmuth> i think it is full featured, just a 1TB limit
15:57:49 <bklei> that's pretty good
15:58:17 <rhochmuth> yes, with the encoding, you are getting a significant amount of "compression"
15:58:28 <rhochmuth> so 1 TB translates proabbly into around 20
15:58:48 <fabiog> is there any TS opensource database that could fit the bill?
15:58:49 <shinya_kwbt_> wow
15:59:03 <bklei> i think the license limit is based on uncompressed ingest
15:59:13 <fabiog> like OpenTSB or such?
15:59:26 <rhochmuth> yes, that is true, but i don't think they count the encoding that we use as compression
15:59:46 <rhochmuth> we are still looking at cassandra
16:00:09 <rhochmuth> ok, time is up everyone
16:00:18 <rhochmuth> i need to end the meeting
16:00:22 <rhochmuth> bye
16:00:24 <bklei> cya
16:00:25 <tomasztrebski> so cheers and good luck till next time
16:00:27 <Kamil> bye
16:00:27 <tomasztrebski> cya
16:00:29 <shinya_kwbt_> bye
16:00:32 <hosanai> thanks & bye
16:00:39 <rhochmuth> #endmeeting