15:01:17 <rhochmuth> #startmeeting monasca
15:01:18 <openstack> Meeting started Wed Jun 22 15:01:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:23 <openstack> The meeting name has been set to 'monasca'
15:01:33 <iurygregory> o/
15:01:34 <ericksonsantos> \o
15:01:36 <rbak> o/
15:01:37 <witek> hi
15:01:38 <jayahn> o/
15:01:39 <shinya_kwbt> o/
15:01:39 <Kamil__> o/
15:01:41 <arturbasiak> o/
15:01:41 <koji> o/
15:01:42 <hosanai> o/
15:01:55 <bklei> o/
15:02:09 <tsv> 0/
15:02:12 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:02:22 <slogan> o/
15:02:22 <rhochmuth> Agenda for Wednesday June 22, 2016 (15:00 UTC)
15:02:22 <rhochmuth> 1.	Grafana Update
15:02:22 <rhochmuth> 2.	Revert "Remove cassandra repository" https://review.openstack.org/291319
15:02:22 <rhochmuth> 3.	Encrypted password in monasca-agent configuration file ??
15:02:22 <rhochmuth> 4.	'locked alarms' http://lists.openstack.org/pipermail/openstack-dev/2016-June/097831.html
15:02:23 <rhochmuth> 5.	Reviews
15:02:23 <rhochmuth> 1.	https://review.openstack.org/301443
15:02:24 <rhochmuth> 2.	https://review.openstack.org/331582
15:02:34 <rhochmuth> Good morning Monasca
15:02:39 <Fdaisuke_> o/
15:02:41 <rhochmuth> What movie is that from
15:03:04 <tomasztrebski> Artur, can you find the link ? :D
15:03:17 <arturbasiak> for noise?:D
15:03:21 <rhochmuth> So, hi everyone, looks like we have a descent agenda to work through
15:03:37 <rhochmuth> so, we might as well get started
15:03:43 <tomasztrebski> cool
15:03:51 <rhochmuth> #topic Grafana update
15:03:58 <rbak> That's me.  Just a couple of things to mention.
15:04:11 <rbak> I've updated the monasca grafana repos for Grafana 3
15:04:23 <rhochmuth> are they going to let you in?
15:04:32 <rbak> For anyone that wants to use that there are new branches.  master-keystone and master-monasca
15:04:50 <rbak> We're still working on getting the keystone auth in.  I'm not sure when that will happen
15:05:10 <rbak> For the monasca datasource, that will always be a plugin because of their new model.
15:05:12 <rhochmuth> do you have a gentleman's agreement in place
15:05:18 <rhochmuth> that they are going to let you in
15:05:28 <rhochmuth> or let keystone in?
15:06:06 <rbak> They've said they'll work with us.  We're in the process of paperwork to make them a Vendor so we can pay for support and make this a priority for them.
15:06:07 <rhochmuth> i'm sorry, gentleman is not applicable here
15:06:30 <rbak> For the monasca plugin though we might want to find a permanent home.
15:06:36 <rhochmuth> wow, very cool
15:06:49 <rhochmuth> i didn't realize you would have to go to the level of a contract
15:07:09 <rbak> They said they were interested in it either way, but this way it gets done sooner
15:07:15 <rhochmuth> very nice
15:07:23 <rhochmuth> what are you impressions of grafana 3?
15:07:32 <rhochmuth> over 2
15:07:46 <rbak> Not as big a change as 1 to 2, but some improvements.
15:07:55 <rbak> Most of the changes are architectural
15:08:06 <rhochmuth> so, where do you want to put the plugin
15:08:12 <rhochmuth> didn't they have a grafana-plugins repo
15:08:27 <rbak> Yeah, but that's being decommissioned
15:08:45 <rhochmuth> and the grafana repo isn't the right location either?
15:08:46 <rbak> The new model is maintain your own repo and link to it on their site
15:08:59 <rhochmuth> will that be true for all data sources
15:09:10 <rbak> All but about six.
15:09:11 <rhochmuth> like influxdb, opentsdb, …
15:09:23 <rbak> A couple were even removed and made into plugins.
15:09:37 <rhochmuth> i see
15:09:40 <rbak> You can see the plugin list at their new site.  grafana.net
15:09:40 <witek> perhaps a new repo at openstack?
15:09:52 <rbak> That's probably what we want long term.
15:10:24 <rhochmuth> so, do you want a monasca-grafana-plugin repo?
15:10:34 <rhochmuth> within the openstack org
15:10:46 <rbak> monasca-grafana-datsource is probably more accurate
15:10:56 <rbak> there are other types of plugins
15:11:38 <rhochmuth> so, we can add another repo to the long list of repos if that seems appropriate in this case
15:11:59 <rhochmuth> that makes the most sense to me
15:12:01 <witek> they won't like us :)
15:12:02 <rbak> It's either that or it sits in the twc repo forever, and I don't think that's what we want
15:12:23 <rhochmuth> pretty soon monasca is going to have more repos than the rest of opensack
15:12:29 <tomasztrebski> ]:->
15:12:40 <tomasztrebski> it is called 'aggressive expansion'
15:12:41 <rhochmuth> we'll have a monasca summit in which we'll feature the rest of openstack
15:13:02 <witek> lol
15:13:04 <rbak> rhochmuth: Can you either get that repo or point me to instructions.  I'm not sure how to do it myself.
15:13:09 <rhochmuth> rbak: in all seriousness, i agree, and i think that makes the most sense to me
15:13:18 <rhochmuth> i can get that set-up if you want
15:13:24 <rhochmuth> or if you want to do the submission that is fine too
15:13:34 <rhochmuth> it is mostly logistical
15:13:46 <rbak> If you want to do that since you already know how that would be great.
15:14:15 <rhochmuth> rbak: you wish is granted
15:14:22 <rhochmuth> you only have two remaining
15:14:32 <rhochmuth> i'll get it done
15:14:33 <rbak> awesome, thanks.
15:14:37 <bklei> wish for more wishes
15:14:56 <rhochmuth> so, "monasca-grafana-datasource",
15:15:21 <rhochmuth> is that the name
15:15:31 <rbak> I think that makes sense, yes
15:15:33 <rhochmuth> that will be the first monasca repo with 2 dashes
15:15:41 <rhochmuth> ok, sounds good to me
15:15:49 <witek> not really :)
15:16:04 <tomasztrebski> monasca-log-api was the first.... -_-
15:16:15 <tomasztrebski> ;-)
15:16:16 <rhochmuth> ooops
15:16:38 <rhochmuth> ok, it will be the second repo with two dashes
15:16:44 <rhochmuth> aha
15:16:49 <rhochmuth> got you
15:17:10 <rhochmuth> did someone spike my coffee
15:17:13 <tomasztrebski> I will send you list of changes I'd like to have accepted because you forgot about us ;-)
15:17:36 <rhochmuth> so, are we good on grafana
15:17:41 <rbak> Yep, that's all I had
15:17:49 <rhochmuth> i'm assuming you'll update devstack too?
15:17:53 <rhochmuth> please
15:18:02 <rbak> I will once we get the new repo in place.
15:18:08 <rhochmuth> thx
15:18:13 <rhochmuth> #topic Revert "Remove cassandra repository" https://review.openstack.org/291319
15:18:26 <shinya_kwbt> It's me
15:18:54 <shinya_kwbt> I'm fixing deklan's cassandra support code.
15:19:32 <shinya_kwbt> But cassandra support code are removed in monasca-persister
15:19:45 <rhochmuth> yeah, that was added then removed
15:19:47 <shinya_kwbt> So I want to revert this change.
15:19:50 <rhochmuth> so it will need to be readded
15:19:58 <rhochmuth> ahhh, that will work too
15:20:07 <rhochmuth> i think that is ok with me
15:20:22 <witek> +1
15:20:26 <tomasztrebski> cassandra as an alternative to influx and vertica, right ?
15:20:26 <rhochmuth> bigger question then, is cassandra the way we ant to go?
15:20:33 <rhochmuth> correct
15:20:47 <tomasztrebski> don't we investigate that, Witek ?
15:21:02 <witek> yes, Matthias investigates alternatives
15:21:08 <tomasztrebski> so, +1
15:22:04 <rhochmuth> my biggest concern going forward is that we have enough support within monasca to continue to support and improve the cassandra
15:22:07 <witek> rhochmuth: I think it's too early to say
15:22:51 <rhochmuth> so, it seems like general concensus is to add cassandra back and continue to evaluate and improve
15:23:32 <rhochmuth> lot's of questions around performance, scale, compression still
15:24:01 <shinya_kwbt> Almost function are worked in my env. But I don't know speed. So please evaluate cassandra. Of course I also improve
15:24:23 <rhochmuth> +1
15:25:47 <shinya_kwbt> I will push fix in this week.
15:25:58 <rhochmuth> thanks shinya_kwbt
15:26:13 <tomasztrebski> perhaps, it'd be worth considering dropping influx if cassandra as open source app will support features influxdb closes in
15:26:20 <tomasztrebski> but I don't know cassandra at all
15:26:26 <tomasztrebski> and that's a mere suggestion here
15:27:04 <rhochmuth> sounds like a reasonable suggestion to me
15:27:38 <rhochmuth> we are already spending a lot of time of various databases support so reducing the number would be good
15:27:49 <rhochmuth> i think dropping would be a community decision though
15:28:11 <tomasztrebski> if so, only after cassandra is fully compatible
15:28:33 <rhochmuth> yes, that seems reasonable
15:28:51 <rhochmuth> so there is data injest performance
15:28:56 <rhochmuth> there is query performance
15:29:10 <rhochmuth> also, compression on disk
15:29:20 <rhochmuth> those are the main areas
15:29:25 <tomasztrebski> migration from influx to cassandra ?
15:29:31 <tomasztrebski> db migration, I mean
15:29:36 <rhochmuth> i think cassand's clustering is rock solid
15:29:49 <rhochmuth> i don't think a migration would be easy
15:30:02 <rhochmuth> and i think that would be outside the scope of monasca project
15:31:24 <rhochmuth> shinya_kwbt: so closing on this issue, i don't see any major functional issues proceeding with cassandra
15:32:00 <shinya_kwbt> I found one issue.
15:32:01 <rhochmuth> biggest concern is what the final performance, compression will be
15:32:12 <rhochmuth> as well as the future community support
15:32:16 <shinya_kwbt> Maybe little concern
15:32:57 <shinya_kwbt> It is difficult to support multiple dimension value
15:33:29 <rhochmuth> do you have an exampel?
15:33:43 <shinya_kwbt> like that hostname=devstack|mini-mon
15:34:00 <rhochmuth> in the query?
15:34:01 <shinya_kwbt> values has | split
15:34:04 <shinya_kwbt> Yes.
15:34:36 <shinya_kwbt> Is is caused lack of cassandra function. So I want to idea.
15:35:24 <rhochmuth> biggest issue with cassandra is query performance due to lack of in-database join, merges and analytics
15:35:53 <rhochmuth> so, i'm not sure how to deal with that efficiently
15:36:14 <shinya_kwbt> Yes, I agree. But I didn't measure speed yet.
15:37:40 <shinya_kwbt> And I don't have servers to use free yet ;-(
15:38:18 <shinya_kwbt> I will ask my boss to get servers.
15:38:34 <rhochmuth> shinya_kwbt: sounds good
15:39:20 <rhochmuth> shinya_kwbt: is it ok to move on to next topic?
15:39:28 <shinya_kwbt> Yes
15:39:37 <rhochmuth> thx
15:40:10 <rhochmuth> i will start reviewing your reviews
15:40:29 <rhochmuth> #topic Encrypted password in monasca-agent configuration file ??
15:41:13 <rhochmuth> as usual i don't know who posted this topic
15:41:18 <tomasztrebski> ok, it's me
15:41:29 <tomasztrebski> I thought Witek would want to describe thi
15:41:32 <witek> :)
15:41:44 <witek> actually the requirement is
15:41:53 <witek> not to use plaintext passwords
15:41:59 <witek> in monasca-agent
15:42:36 <witek> are there other possibilities for agent to authenticate with keystone?
15:42:48 <rhochmuth> so, is there any other example in openstack where passwords are encrypted?
15:43:04 <rhochmuth> i was just wondering if there is an existing precedent that has been established
15:43:12 <rhochmuth> for how to handle this
15:43:52 <rhochmuth> also, do you want to submit a bp for adding this
15:44:03 <rhochmuth> and what would be your suggested way
15:44:13 <Kamil__> sure, but first we wanted to ask about your feeling
15:44:26 <rhochmuth> i dont' have any major issue
15:44:37 <rhochmuth> i wonder why it is required
15:44:46 <rhochmuth> and how you would support this
15:44:53 <rhochmuth> and if OS was doing this anywhere else
15:44:58 <bklei> who is requiring this?
15:45:07 <witek> our product owner
15:45:14 <Kamil__> we haven't investigated on this topic yet. The request was coming from our product owner
15:45:37 <cbellucci> in the scenario of monitoring as a service, for security reasons
15:45:37 <bklei> aah.  would be nice to make encryption optional, so others aren't forced to change -- shops that are OK with just file perms to lock it down
15:46:02 <rhochmuth> bklei: agree
15:46:07 <Kamil__> good point bklei
15:46:48 <Kamil__> so i would say, we will investigate and create a blueprint for that
15:47:09 <rhochmuth> I know on Windows, there was a system password that could be used
15:47:16 <rhochmuth> not sure what Linux has in this area
15:48:13 <rhochmuth> so, will wait for bp and then we can have a discussion
15:48:17 <rhochmuth> sound good?
15:48:19 <witek> ok
15:48:22 <tsv> rhochmuth, we set 600 mode for the conf files that have sensitive data
15:48:24 <Kamil__> +1 thx
15:48:36 <rhochmuth> #topic 'locked alarms' http://lists.openstack.org/pipermail/openstack-dev/2016-June/097831.html
15:48:46 <witek> that's me
15:49:11 <witek> I'm looking for a good name for 'locked/latched alarms'
15:49:19 <bklei> i like this idea witek -- could this be used to 'mute' an alarm too?
15:49:24 <witek> The functionality allows the operator to define an alarm which after transition to ALARM state, stays in that state until it is manually reset.
15:49:43 <bklei> so if it's alarming and you're going to address it at some point in the future, but you want to 'silence' it?
15:50:19 <witek> well, the alarm will stay in ALARM stay, so no notification
15:50:21 <tomasztrebski> mute is kind of available through disabling notifications, right ?
15:50:43 <tomasztrebski> but alarm transitions are not affected that way
15:50:45 <tomasztrebski> here, it would
15:51:07 <bklei> i was thinking of the overview page in horizon -- which is alarm based, not notification
15:51:33 <witek> oh, I see
15:51:33 <rhochmuth> i think the idea is that if something goes to the ALARM'd state, if the metric then goes back to OK, you want the alarm to remain ALARM'd until the operator clears it
15:51:55 <witek> rhochmuth: correct
15:52:00 <rhochmuth> you don't want to miss and alarm basically
15:52:04 <bklei> ok, different than what i'm thinking
15:52:46 <rhochmuth> this is also related to deterministic alarms that are sent "sporadically"
15:53:02 <witek> another question is about implementation detail
15:53:06 <rhochmuth> for example, in the case that you are creating metrics from error messages in log files
15:53:35 <witek> should we make it by extending AlarmExpression, or would it be enough to add attribute to AlarmDefinition?
15:54:03 <rhochmuth> i've already added my vote in response to your email
15:54:20 <witek> oh, I didn't read yet
15:55:06 <rhochmuth> AlarmDefinition is what i/we thought
15:55:16 <rhochmuth> your second option
15:55:21 <witek> nice
15:55:22 <witek> thanks
15:55:47 <witek> would it conflict with current monasca-thresh implemenation somehow?
15:55:59 <rhochmuth> i don't think so
15:56:20 <witek> thanks for your answers
15:56:28 <witek> we can move on
15:56:33 <rhochmuth> implementation should be straiht-forward, but craig bryant will probably come up with corner cases
15:56:41 <witek> :)
15:56:53 <rhochmuth> "locked" seems like a reasonably field name
15:57:06 <rhochmuth> until come up with something better
15:57:08 <tomasztrebski> I'd prefer isLockable for alarm definiiton
15:57:16 <tomasztrebski> and locked for alarm
15:59:04 <rhochmuth> not sure i have a better name, but will ponder this one more
15:59:49 <rhochmuth> i think we need to end the meeting
16:00:14 <witek> thanks Roland!
16:00:14 <rhochmuth> i'll try and get to your reviews tomasz
16:00:23 <tomasztrebski> thank you ;-)
16:00:24 <witek> bye
16:00:27 <Kamil__> thanks and bye
16:00:39 <bklei> thx
16:00:43 <rhochmuth> by everyone
16:00:45 <shinya_kwbt> bye
16:00:46 <koji> bye
16:00:48 <ericksonsantos> bye
16:00:56 <rhochmuth> #endmeeting