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