15:00:57 #startmeeting monasca 15:00:59 Meeting started Wed Dec 7 15:00:57 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:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:02 The meeting name has been set to 'monasca' 15:01:03 o/ 15:01:07 o/ 15:01:10 o/ 15:01:10 o/ 15:01:10 hello 15:01:13 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 15:01:26 Agenda for Wednesday December 7 2016 (15:00 UTC) 15:01:27 1. Grafana branch - merge upstream? 15:01:27 2. Reviews: 15:01:27 1. https://review.openstack.org/#/c/395246/ 15:01:27 2. https://review.openstack.org/#/c/349097 - SAP team would like to contribute 15:01:27 3. https://review.openstack.org/406936, https://review.openstack.org/407371 15:01:27 4. https://review.openstack.org/407379 15:01:27 5. https://review.openstack.org/#/c/395897/ 15:01:33 hi everyone 15:01:41 o/ 15:01:49 it is really cold and snowing here 15:02:00 0/ 15:02:14 where? 15:02:16 nice 15:02:24 fridge opened? 15:02:28 Fort Collins, CO 15:02:42 o 15:02:53 let's get started with the agenda first 15:03:05 #topic Grafana branch - merge upstream? 15:03:09 That's me 15:03:21 please proceed 15:03:42 Raintank, the owner's of Grafana have been fairly silent lately 15:03:52 uhh, ohhh 15:04:25 We're not sure that our original plan of brining them on as vendors for Charter is going to work 15:04:48 And our fork of Grafana is slowing getting more complex and harder to merge in. 15:04:59 do you think that they are having financial problems 15:05:06 or just not interested in what we are doing 15:05:14 or other priorities 15:05:15 Just not interested 15:05:27 That's probably more accurate 15:05:52 So we either need to make a push as a community to get the keystone changes moved into upstream, or we need to resign ourselves to maintaining a permanent fork again. 15:05:52 i thought you guys were going to put a support agreement or licensing in-place 15:06:05 that would have incenticized them enough 15:06:17 We're still trying, but they stopped replying. 15:06:26 The difficulties with the merger may have scared them off 15:06:44 i see 15:07:18 So it's a question of whether we can rally enough support 15:07:30 I can put up a new pull request 15:07:40 ok 15:07:51 are we just supposed to thumbs up it at that point 15:08:00 what does support mean from your viewpoint? 15:08:08 Thumbs up would be good 15:08:14 I also plan on emailing them directly. 15:08:15 ok, we can do that 15:08:21 ok 15:08:26 If anyone wants to be included on that let me know 15:08:26 i can contact them also 15:08:34 please include me 15:08:45 will do 15:08:46 are you talking to raj dutt 15:08:50 i think that is the name 15:08:57 it has been a while 15:09:09 Yeah, him and Torkel if I can dig out his email. 15:09:34 with more and more folks using monasca, i'm hoping they would be interested 15:09:48 there are potential support/service agreements they could get as a result 15:10:16 That and the fact that the changes we want are actually keystone specific, so in theory it could be used with any openstack projects, or just Grafana as a service. 15:10:26 but, there is a lot of momentum around some other tools, like promethues and influxdb, that is probably distractign them 15:11:06 Well, they just released Grafana 4, so hopefully this is a good time, while they're still planning for the next version. 15:11:11 yes, i agree, i would expect some interest on their part 15:11:36 so, now that 4 is out, are you going to look at adding alerts? 15:11:39 :-) 15:11:48 We're going to look into it, yes 15:11:53 thanks 15:12:11 we've been using grafana a lot internally lately, and it is working great 15:12:17 Good to hear 15:12:28 we had some very impressive demos this week with kubernetes 15:12:34 and monasca 15:12:49 That's all I had on this subject. I'll put up a new pull request and bring that up at the meeting next week. 15:13:26 i'm wondering if we should get a higher level business call together with raintank between allthe interested companies 15:13:37 charter, hpe, fujitsu, …, 15:13:41 I would be up for that. 15:13:48 I'll suggest that in my email 15:13:56 you have our support too 15:13:56 yes, please do 15:14:15 i think they should understand the momentum and business opportunity better 15:14:29 maybe we should get and email out to openstack-dev list as well 15:14:47 there are other companies involved in deploying monasca these days that we could also lobby 15:15:05 invariably, it is going to be about the money i guess 15:15:19 or the perceived opportunity 15:15:51 Probably, but they are open source, and did tell us they were interested even without a contract when we talk initially. 15:16:19 ok, let's see what happens with the email 15:16:28 Sounds good. I'll include you on that. 15:16:30 and then maybe we can rally the troops 15:16:41 thanks rbak 15:16:44 good update 15:16:59 #topic https://review.openstack.org/#/c/395246/ 15:17:13 That one is also mine 15:17:25 Just wondering if it can be merged 15:17:35 It's been around a couple weeks with some +1s 15:17:36 i +1'd again this morning, but yes i think it is ready 15:18:05 you should probably ping craig 15:18:13 as he spotted a couple of issues 15:18:27 Alright, I can get him to look at it 15:18:31 but he hasn't looked at it again since your latest fixes/reviews 15:19:03 assuming he is ok, then it could be merged 15:19:14 Sounds good. I'll ping him 15:19:29 thx 15:19:33 #topic https://review.openstack.org/#/c/349097 15:19:56 sap, jbors u there? 15:20:03 yep 15:20:11 we are willing to help. 15:20:17 thanks 15:20:20 and we are working on some complementary stuff 15:20:33 so, do you want to take on this review 15:20:42 i don't think haneef is working on it anymore 15:20:48 and was just waiting to merge it 15:20:57 i had signed off on it 15:21:01 sure 15:21:06 thanks 15:21:24 sorry, late to the topic and just catching up on the discussion so far - all sounds good to me. We need to get some kind of response from raintank, even if it's jsut to get an answer one way or the other 15:21:24 we want to add notification templates for slack and mail since this is what we are using 15:21:47 dhague: yes, i agree 15:21:56 ... and I just noticed the topic change. sorry 'bout that 15:22:10 rbak: please add dhague and jbors to email list, i'm assuming 15:22:24 will do 15:22:25 email list to raintank that is 15:22:27 thanks 15:22:33 +1 15:22:35 ok, np on topic change 15:23:32 so, i'm assuming dhague will take over the custom formatting for the hipchat plugin 15:23:49 you had also fixed the slack plugin recently too 15:23:52 on the new topic, I am looking at that - in fact, having some kind of per-channel templating 15:24:02 the idea is this: 15:24:38 alarm definition "description" field will be a jinja template, so we can generate some kind of human-readable alert message 15:24:57 question on the hipchat plugin formatting 15:25:11 then at the channel level that can be fed into another template - pretty raw for hipchat & slack, but email would allow HTML headers etc 15:25:29 will this patch let us change msg color based on alarm severity? 15:25:49 Oh, the public cloud meeting's over 15:25:51 :( 15:25:55 that will be possible 15:26:06 jinja2 has primitives like if and for etc. 15:26:22 excellent -- it's goofy that everything is green today 15:26:49 the redesign has two parts 15:27:00 jobrs and I had a brainstorming on this yesterday, the above is the brief summary of what we discussed - is it OK with everyone? 15:27:07 I will let jobrs continue... 15:27:26 just wanted to add what I discovered today 15:27:46 so part one is just in notification: templates for formatting notification messages 15:28:49 part two is more tricky: have the monasca-api pass the alarm-definition's description alongside the alarm (not just the name) 15:29:15 that's not there already? 15:29:23 so we would need some support in reviewing the API changes and someone who would do the Java side of it 15:29:51 why do you need the description in the alarm? 15:30:09 can't you get that by querying the db? 15:30:25 not sure i understand the proposal 15:30:54 having the alarm definition description in the alarm is useful -- we use it for runbook links for oncall 15:31:01 the description is what matters most to the user (imho) 15:31:16 but i believe it's already there -- this is from the current hipchat plugin: 15:31:22 "old_state": "UNDETERMINED", 15:31:22 "alarm_description": "The http response time is greater than 3s on avg", 15:31:22 "message": "Thresholds were exceeded for the sub-alarms: avg(soapuiv2MonascaTesterMetric{hostname=dnvrco02-keystone-001}) > 3.0 with the values: [4.6218046456454775]", 15:31:51 it is in the notifications, but not the alarms. when you display the alarm in a UI it would be good to have the description of it 15:32:22 aah. i see. 15:32:58 but, that could be done with mutiple queries 15:33:06 get alarm, then get alarm definition 15:33:07 if you have a templated alarm description and you can render it using the alarm attributes, then you can have quite instructive alarms 15:33:09 then merge the two 15:33:25 slow 15:33:40 you did the job already for the alarm-description-name 15:34:02 ok 15:34:15 interesting, that we didn't see that through 15:34:44 so, when you query an alarm, you would also return the description in the json body? 15:35:03 yes, and I would do the template rendering in the monasca-client 15:36:11 so, how would the monasca-client know how to render it? 15:36:34 the custom formatting is for the notifications 15:37:19 that is what I mean with two parts. One thing is to have descriptions with variables. the other is to have proper presentation for your notification channel 15:37:37 we believe you need both to have actionable alarms 15:38:50 ok 15:39:07 not sure i'm grokking the full extent of the changes 15:39:31 it should be non-breaking 15:39:43 good enough for me 15:39:51 :-) 15:40:09 We can discuss the fine details in the code review :-) 15:40:15 sounds good 15:40:30 let's do so 15:41:39 so, at this point i please proceed, and we can discuss more in the code review 15:41:51 last question - can we use the change for further developments or created a separate one? 15:42:15 sure, you can use that review 15:42:26 i think that is the best option 15:42:48 great, I hope we can deliver the first proposal next week 15:42:54 thanks 15:43:46 #topic https://review.openstack.org/406936, https://review.openstack.org/407371 15:44:55 yingjun: you there? 15:45:07 yep 15:45:17 you are up 15:45:25 Fix UnicodeEncodeError for alarm definition 15:46:27 so as the bug reported, when i input Chinese in description, it will raise the UnicodeEncodeError 15:47:42 i thought we could encode/decode utf8 15:48:13 so, i'm a bit confused by the fix and why it was necessary 15:48:24 yingjun: could you add that case to the tests? 15:48:59 witek_, sure 15:49:12 shouldn't decode(('utf8') work for both chineese and other strings 15:50:01 what you are doing now is not decoding the string if it is six.text_type 15:50:45 yes 15:51:59 i’m not sure if there’s case it wasn’t text_type 15:52:59 yes, i'm wondering why the data isnn't stored as text_type 15:53:12 i'm wondering if bad data got in the db 15:53:22 should we have converted it when storing the description 15:53:35 it sounds to me that it wasn't converted when we stored it 15:53:52 the case https://github.com/openstack/monasca-api/blob/master/monasca_api/tests/test_alarms.py#L504 do 15:54:40 but it mocks the db return value 15:55:00 ok, i'll look at it more 15:55:18 i obviousely am missing some bit of understanding 15:55:33 ill add comments to the review 15:55:38 ok 15:55:38 have you checked that your db has utf8 encoding? 15:56:06 witek_, not yet 15:56:36 witek_, i will check that tomorrow, it pretty late here in China... 15:57:02 witek_, and the test env not in my laptop 15:57:19 #topic https://review.openstack.org/#/c/407379/ 15:57:42 looks like joe merged that one this morning 15:58:11 #topic https://review.openstack.org/#/c/395897/ 15:58:21 i think we are going to run out of time to discuss this one 15:58:35 ;( 15:58:50 i'll try and look at it more 15:59:01 rhochmuth, thanks 15:59:23 tomasz seems to think it was the right direction too 15:59:37 he should probably be pinged again on this one 15:59:45 so, i need to close out the meeting again 15:59:51 one hour just isn't enough some days 16:00:04 thanks everyone 16:00:11 thanks 16:00:17 thanks 16:00:26 #endmeeting