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