15:00:24 #startmeeting monasca 15:00:24 Meeting started Wed Mar 6 15:00:24 2019 UTC and is due to finish in 60 minutes. The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'monasca' 15:00:34 Greetings 15:00:38 hello everyone 15:00:40 hi joadavis 15:01:05 do you have any topics for the agenda? 15:01:23 o/ 15:01:26 hi dougsz 15:01:30 I don't. I've been wishing I was working upstream a bit more lately 15:01:37 +1 15:01:39 hi dougsz 15:01:50 hey all 15:02:12 thanks for the reviews on Kafka client last week 15:02:15 Hello 15:02:19 hi Dobroslaw 15:02:39 dougsz: Dobroslaw please fill in topics in the agenda if you have any 15:02:56 nothing from me this week 15:03:06 Don't have any at this moment 15:03:42 I've looked again at dropping measurements with parsing errors in persister 15:03:50 https://review.openstack.org/638589 15:04:30 actually we do validate that the measurements for empty dimension values in API 15:04:57 so the measurement should be rejected before already 15:05:22 but I think that the change still can be useful 15:06:16 I've suggested to define a new config option to control if the measurement should be dropped or persister stopped 15:06:28 So is he sending measurements straight to persister? 15:06:50 straight to Kafka, I assume 15:07:29 we do it in monasca-log-metrics as well 15:07:49 Ok 15:09:41 please comment in review if you think it's a good idea 15:10:17 Will try to take a look when I get some time 15:10:29 thanks dougsz 15:11:26 I've added story about broken formatting in Python 3 client to the board 15:11:33 https://storyboard.openstack.org/#!/board/111 15:12:34 and I'm working on adding Confluent Kafka client in persister 15:13:48 Nice 15:14:57 dougsz: do you know if Kolla could need tagging images on releases? 15:16:22 we wanted to build and publish Monasca images on every release but Dobroslaw has reported it's not supported by infra as of now 15:16:45 on every tag at last 15:18:17 It's probably possible to create docker images on tag but jobs would need to stay in openstack-config 15:18:46 *project-config 15:19:52 witek: Not quite sure I understand 15:20:22 It can apply arbitrary tags to images 15:20:29 Are you talking about in CI? 15:20:40 we would like to have a job in CI which publishes an image on every version tag in repo 15:20:43 In CI 15:20:50 ah got it 15:21:16 To have stable images more frequently 15:21:35 So in kolla there is a static file which tracks all the versions, but you can override parts of it. 15:22:13 I will have a look at exactly what goes on in CI and report back next week 15:22:24 Thank you 15:22:31 np 15:23:07 #topic email notification templating 15:23:22 Hi witek, its mine 15:24:05 I can say that would like to contribute to monasca by customising notification template 15:24:47 Hope dougsz already in testing phase of slack notification, I would like to work similar on email body customisation 15:25:03 Currently email body looks like this http://paste.openstack.org/show/747345/ 15:25:52 From end user comments, It will be good if customise mail subject & body with more simple information. 15:26:21 Looking forward witek & dougsz and all advise here 15:26:46 as a final goal it would be great to have an API to control how the notification method looks like 15:27:18 Yeah, so tenants can customise it individually per project 15:27:25 it could be added as parameter to create-notification method 15:27:42 Yes, but here looking forward everyone advise. From our user comments need tenant_name in mail body and subject 15:27:58 and then persisted in SQL DB 15:28:43 pandy: If you put a break point in just before it calls the notification method you can see all the information you have available which could be included in the message. 15:30:41 dougsz, okay understood. I can pull information whatever i want for my local user. but In general default template need little shape as told like adding few moew information in subject & mail body, so globally all can use 15:31:49 pandy : I like to ve this feature in Monasca, If you need any help please let me know . we can collaborate 15:33:26 I think we could start with putting some requirements and implementation plan to the story 15:33:27 mohankumar, Yes. based on user story feel to have this info in default in upstream monasca will be good :) Looking forward witek to support to contribute 15:34:20 witek, yes thats am looking from you all, So I can work on 15:34:25 what we want is to have some easy to edit template which would control the shape of notification message 15:35:14 and have some simple defaults, like a generic message with simple formatting. 15:35:15 to follow the spirit of Monasca we would like to have an API resource to control this templates 15:35:35 but that could be a second step 15:36:31 witek: how about enable user to add their template (yaml/j2) . we can expose some API to add them in monasca notification template 15:38:11 I rather thought about persisting it in the DB 15:38:28 witek: agree 15:39:17 witek, please add your comments in https://storyboard.openstack.org/#!/story/2005111, so can follow up 15:40:08 probably would fit best in POST notification-methods 15:40:09 https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#post-v20notification-methods 15:41:38 mohankumar: and yes, the users should be able to add own templates 15:42:27 pandy: I guess you can start extending the story based on that discussion 15:42:43 sure, I do. 15:42:53 thanks 15:43:08 :) 15:44:24 cool, some more questions on that? 15:45:06 Nope, witek. will get back if have doubts :) 15:45:22 thanks, that's all from me 15:45:33 I'll be wrapping up if there's nothing else 15:46:00 Thank you all 15:46:10 thank you 15:46:11 Thanks all, until next week 15:46:14 see you next week 15:46:15 Nothing else 15:46:16 Thanks 15:46:21 buy 15:46:23 thank you 15:46:27 bye :) 15:46:28 Til next time. :) 15:46:41 #endmeeting