13:00:35 #startmeeting monasca 13:00:36 Meeting started Tue Feb 25 13:00:35 2020 UTC and is due to finish in 60 minutes. The chair is witek_. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:40 The meeting name has been set to 'monasca' 13:00:52 Hello 13:00:54 hello everyone 13:00:57 hi 13:00:57 Hello 13:01:01 hi 13:01:16 agenda for today: 13:01:22 https://etherpad.openstack.org/p/monasca-team-meeting-agenda 13:01:36 let's start 13:01:42 hi 13:02:00 #topic monasca-notification: drop YAML configuration support 13:02:37 we've hit a bug this week in CI with monasca-notification not being able to start 13:03:13 because of CLI option yaml_config being wrongly declared 13:04:04 the bug was easy to fix, but that brings me to the point that it's actually long overdue to remove support for YAML config there 13:04:26 dougsz has started this work already 13:04:28 https://review.opendev.org/656769 13:05:09 I understood that you left the option to use the yaml because of monasca-docker, right? 13:05:35 I wanted to just fix the existing code 13:05:58 but I think we should go one step further and remove deprecated code 13:06:19 Thanks for iterating on that patch witek 13:06:56 and yes, Docker deployment still relies on YAML config 13:08:24 there are also some other places marked for removal in that context but these are not that important 13:09:13 I agree with Witek we should remove deprecated code 13:09:25 +1 13:10:10 +1 13:10:33 +1, i already printed the yaml config and set fire to it 13:10:48 :) 13:10:56 not CO_2 friendly 13:11:01 :D 13:11:03 :D 13:11:52 who would like to take an action item to add support for oslo.config in Docker? 13:13:06 i can try 13:13:26 adrian told me he will help me at the begining :) 13:13:33 great, I think it should not be complicated 13:13:35 thanks 13:13:46 Thanks piotrowskim, I can review 13:14:25 Feel free to push changes to https://review.opendev.org/656769 and add yourself as co-author 13:14:38 ok 13:15:27 just for reference: 13:15:32 https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors#creating-co-authored-commits-on-the-command-line 13:16:10 I guess we can move on? 13:16:41 #topic Updating alarm definitions 13:17:03 Similar to this bug: 13:17:09 https://storyboard.openstack.org/#!/story/2006750 13:17:50 bandorf and Goetz found a bug (at least in stable/pike) when the alarm definition is updated. 13:18:11 More specific when the 'times' is updated in the expression 13:18:59 In this case it seems that the bug is not in monasca-api, but in the thresh 13:19:41 I read the kafka message (topic event) that thresh receives after the alarm-definition is updated 13:20:12 the parameters time and times were correct, but not updated 13:20:33 Right now I am trying to reproduce it in devstack (master branches) 13:21:05 I will create a similar Story in case of bug in master branch 13:21:18 I'm not sure, but it might be that this is documented not to be supported 13:22:29 Yes, I remember something about restrictions on update. 13:23:32 And the problem for final user is that it is not possible to create an alarm-definition in monasca-ui assigning parameters time and times 13:24:20 So, if the final user doesn't have access to CLI, he should create the alarm-def in the UI and then updated it 13:24:23 :( 13:25:21 yes, that workaround doesn't work, indeed 13:26:12 Witek, do you know where this has been documented? 13:26:44 This would finally mean that you can't handle alarm definitions using time/times can't be managed with the UI 13:27:12 not from the top of my head, api-spec or monasca-thresh repo 13:28:15 possibly it could be easier to extend the UI then fix thresh 13:28:52 +1 13:29:11 The problem we found so far: The expression in the alarm-definition will be updated, but not the expression in the sub-alarm-definition. 13:29:22 https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#changing-alarm-definitions 13:30:20 that does not cover changing periods though 13:30:33 That's OK, we neither change match_by (not used in this case) nor the metric itself 13:31:11 Does anybody know where in thresh the updated of sub-alarm-definition should happen? 13:31:33 We can search as well, just maybe, somebody already knows. That would shorten our search... 13:32:53 Sorry, it's been a long time since I looked at it 13:33:14 not without looking into it, sorry 13:33:56 OK, thanks 13:34:10 maybe is arround to this point https://github.com/openstack/monasca-thresh/blob/master/thresh/src/main/java/monasca/thresh/infrastructure/thresholding/AlarmCreationBolt.java#L150 13:35:06 seems plausible 13:35:46 let's move on 13:36:07 #topic Update events topic 13:36:26 adriancz works on merging events API 13:37:02 and proposed renaming the currently used topic in monasca-api 13:37:09 https://review.opendev.org/708335 13:37:50 i still working on this change ( i need to update docker ) 13:38:01 I understand the motivation but I'm wondering about the impact 13:38:40 we would have to think about migration as well, right? 13:38:41 but this change is more like open discussion if we should change this name 13:39:19 hm, yeah, would be nice to avoid the migration challenge 13:39:29 so far the topic events is used in the metrics-pipeline to handle alarm-definitions-(creation, update and removal) 13:39:33 that's why I'm bringing it here up, to bring it to attention and share 13:40:50 what about the call the other events like external-events 13:40:55 or something like that 13:41:26 or openstack-events 13:41:37 I guess we don't have to decide anything now, just spend some time to think it over and leave your opinion in review 13:42:01 To be honest, it's really ugly to have a concept of "events", a kafka-topic named "events", and they are not related. 13:42:16 agree 13:42:22 +1 13:43:16 do we want to continue the discussion in review or mailing list? 13:43:56 +1, will add review 13:44:05 +1 review 13:44:13 thanks 13:44:46 do we have anything else for today? 13:45:36 Not from me 13:45:54 testing auto-scaling has fixed itself on its own :) 13:46:00 https://review.opendev.org/700886 13:46:50 hi joadavis, you made it :) 13:47:02 what time is it? 13:47:56 I think we should wrap up, thanks for joining 13:48:02 and see you next week 13:48:04 bye 13:48:12 bye all, thanks 13:48:15 #endmeeting