13:01:10 <witek> #startmeeting monasca
13:01:11 <openstack> Meeting started Tue Apr 21 13:01:10 2020 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:14 <openstack> The meeting name has been set to 'monasca'
13:01:23 <witek> hello everyone
13:01:29 <chaconpiza> Hi
13:01:31 <adriancz> HI
13:01:44 <dougsz> hi all
13:01:50 <witek> the agenda for today:
13:01:54 <witek> https://etherpad.opendev.org/p/monasca-team-meeting-agenda
13:02:23 <witek> we've got a number of items to discuss, let's start
13:02:32 <witek> #topic virtual PTG
13:02:59 <witek> it has been decided the PTG will be held virtually this time around
13:03:08 <witek> in the week 1-5 June
13:04:03 <chaconpiza> The original schedule before the covid pandemic was 8-11 June
13:04:33 <witek> really, haven't realized that
13:05:06 <chaconpiza> I have vacations exactly 1-5 June, but of course I can join one day
13:05:20 <witek> anyway, all the teams have been asked to decide how many sessions they'd like to hold and when
13:05:27 <witek> that's unfortunate, indeed
13:05:42 <witek> also 1 June is holiday in Germany
13:06:54 <openstackgerrit> Merged openstack/monasca-persister master: Migrate from ujson to simplejson  https://review.opendev.org/719989
13:07:12 <witek> I've looked up the notes from our previous PTGs
13:07:48 <witek> in Denver we had 3 slots 3,5 hours each
13:07:52 <witek> https://wiki.openstack.org/wiki/MonascaTrainPTG
13:08:38 <witek> but the last session has ended very early from what I recall
13:10:22 <witek> then the Ussuri planning meeting was virtual
13:10:25 <witek> https://etherpad.opendev.org/p/monasca-planning-ussuri
13:10:48 <witek> it was one slot of 4 hours
13:11:34 <witek> any preferences for this time?
13:12:48 <witek> the organizers have suggested to not put more than 4 hours on a single day
13:12:49 <chaconpiza> Tuesday in the morning
13:13:08 <dougsz> I'm pretty flexible. Tuesday in the morning would work.
13:14:09 <witek> morning could be difficult for US
13:14:24 <chaconpiza> that's right
13:15:35 <witek> does Tuesday afternoon work for you?
13:15:58 <witek> not many projects have declared their slot yet
13:16:02 <witek> https://ethercalc.openstack.org/126u8ek25noy
13:16:11 <witek> do you know what ECG stands for?
13:16:47 <chaconpiza> Edge Computing Group - OpenStack
13:16:55 <witek> thanks
13:17:05 <chaconpiza> (I just google it : ) )
13:17:30 <dougsz> :) Afternoon is good too
13:17:41 <witek> the proposed afternoon slot is 13-17 UTC
13:18:25 <chaconpiza> Ok, what about Tuesday 13:00 UTC to keep the habit
13:18:28 <chaconpiza> yes
13:18:39 <adriancz> +1
13:18:50 <witek> wow, indeed, that's out time! :)
13:18:55 <chaconpiza> :)
13:19:19 <witek> let's start with that then
13:19:31 <bandorf> ok with me
13:19:38 <witek> great, thanks
13:19:59 <witek> I'll also create an etherpad to start collecting topics
13:20:27 <witek> and if we feel like we're running out of time we can decide to extend
13:20:34 <witek> even in the following week
13:20:49 <witek> we haven't book any convention center ;P
13:21:48 <witek> we could also hold a cross-project monitoring session
13:22:28 <witek> perhaps as part of automation SIG?
13:22:52 <witek> I could talk with Rico if you like the idea
13:23:37 <witek> #action witek create etherpad for PTG planning
13:24:05 <chaconpiza> +1
13:24:20 <witek> #action witek book a slot for Monasca session at PTG
13:25:14 <witek> if there are no other comments, I guess we can move on
13:25:15 <witek> ?
13:26:15 <witek> #topic updating alarm definitions
13:26:24 <bandorf> OK
13:27:10 <bandorf> Topic 2.1.1: acceptance criteria: This was a difficult one, but I found some schema that is "good enough" for the specific purpose
13:27:44 <bandorf> 2.1.3 Execute reference tests: Basically, validation of acceptance criteria
13:28:31 <bandorf> Worked ok without issues (exception, valid for most of the test cases: time it takes to change to "UNDETERMINED". But this is not considered for now)
13:28:57 <bandorf> 2.1.4: Execute tests with alarm definition update, but no existing alarms:
13:29:11 <bandorf> Again, everything worked ok - as expected.
13:29:34 <bandorf> 2.1.5 Tests with update alarm definitions, alarms exist:
13:29:53 <bandorf> changing time period definitely doesn't work as expected
13:30:16 <bandorf> chaning number of time period might work, I need to execute further tests
13:30:49 <bandorf> As a note: I executed a subset of tests of 2.1.5, stopping/restarting monasca-thresh.
13:31:05 <bandorf> Then, test results are as expected.
13:31:17 <bandorf> No big surprise, but I wanted to be sure.
13:31:17 <witek> you're testing your updated API calls, is that correct?
13:31:44 <bandorf> Yes, correct. I fixed monasca-api, nothing else. And then, I executed the tests.
13:31:54 <witek> thanks, wanted to be sure
13:32:21 <bandorf> 2.2 Current status:
13:33:00 <bandorf> 2.2.1.1 update of FUNCTION: I executed some quick tests some time ago. These worked. But I still have to do "proper testing"
13:33:34 <bandorf> 2.3 Next steps:
13:33:43 <bandorf> 2.3.1 and 2.3.2 are clear.
13:34:24 <bandorf> I'm curious: Assuming that test results would be time cannot be updated, times can be updated.
13:34:41 <bandorf> What would be your opinion? Allow update for times or not?
13:35:06 <witek> if it works as expected, I'd allow it
13:35:15 <bandorf> OK.
13:35:17 <chaconpiza> +1
13:35:29 <witek> and the rest we could document as the limitation
13:35:48 <witek> I mean, as the workaround we still could recreate the alarm definition, right?
13:35:49 <bandorf> Well, we can restrict in the API as well, like other params.
13:36:01 <witek> +1
13:36:40 <bandorf> Recreation of alarm definition of course always works. That's the work-around we used for our customer
13:37:20 <bandorf> I will add one more "next step": Elfriede has just extended system test with alarms.
13:37:32 <chaconpiza> yeah!
13:37:45 <witek> nice work, thanks
13:37:46 <bandorf> When I come to the conclusion that some parameters can be updated, we will test this as well with system test
13:38:27 <witek> good to have it tested in a systematic way, should we extend tempest as well?
13:39:02 <bandorf> Yes, of course. But I haven't gone into this topic.
13:39:19 <witek> fair enough, thanks for the update
13:39:57 <bandorf> I'll provide an update next week. System test execution for update AD might not be ready then
13:40:09 <witek> nice
13:40:23 <dougsz> Thanks bandorf. +1 for extending tempest / upstream coverage if possible.
13:40:55 <bandorf> Yes, I have it on my list. But this will take some more time, due to other internal priorities
13:41:43 <dougsz> understood
13:41:52 <witek> OK, should we move on?
13:42:02 <bandorf> I' done :-)
13:42:11 <witek> thanks bandorf
13:42:26 <witek> #topic reviews
13:42:40 <witek> we've struggled with CI in the last time
13:43:14 <chaconpiza> The ripple effect
13:43:19 <witek> but we managed to get ujson->simplejson finally merged
13:44:08 <witek> it should be possible to merge other changes now
13:44:20 <dougsz> thanks for that effort!
13:44:22 <witek> like topic:periodic_notifications
13:45:02 <witek> https://storyboard.openstack.org/#!/story/2006837
13:45:15 <witek> or topic:update-hacking
13:45:47 <witek> https://review.opendev.org/#/q/projects:openstack/monasca+is:open+topic:update-hacking
13:46:13 <witek> I'm not sure how to proceed for monasca-log-api repository
13:46:26 <witek> https://review.opendev.org/716408
13:46:48 <witek> we actually have said, we don't want new code merged there, just bug fixes for old API
13:48:56 <dougsz> I see your point
13:49:11 <witek> on the other hand Python 2 is deprecated anyway, so we should probably use Python 3 for old API as well
13:50:32 <dougsz> It's a can of worms
13:50:46 <witek> how do you mean that?
13:51:06 <dougsz> Sorry, just thinking about Kolla not using Python 3 in older releases
13:51:15 <witek> yeah, get it
13:51:55 <witek> hm, I guess we should comment on review and see what AJaeger thinks of it
13:52:31 <dougsz> Agreed, seems likely he will have some wisdom to share
13:53:08 <witek> another set of reviews up there is topic:unittest.mock
13:53:32 <witek> it's replacing third party lib with Python 2 support included
13:53:55 <witek> with standard library's  unittest.mock
13:54:10 <chaconpiza> where monasca-log-api is in the list
13:54:16 <witek> https://review.opendev.org/#/q/(projects:openstack/monasca+OR+project:openstack/python-monascaclient)+is:open+topic:unittest.mock
13:54:52 <witek> chaconpiza: https://review.opendev.org/716408
13:55:04 <witek> and https://review.opendev.org/720943
13:55:41 <chaconpiza> yes, it was a statement ;)
13:55:49 <witek> oh, I see
13:56:07 <chaconpiza> About the list related to the mock, it is strange that monasca-persister was not there
13:56:22 <chaconpiza> do you know why?
13:56:42 <witek> indeed, don't know
13:57:04 <chaconpiza> and exactly that blocked us
13:57:36 <witek> OK, please spend some time on these reviews, should be easy in most cases
13:57:45 <chaconpiza> +1
13:57:48 <witek> before we end, last topic
13:58:05 <witek> #topic RC1
13:58:17 <witek> this week is deadline for RC1 release
13:59:00 <witek> please ping me if there is something which should be included in Ussuri
13:59:30 <witek> after RC1 the stable branch will be created and only bug fixes are allowed to be cherry-picked
13:59:51 <chaconpiza> ok
14:00:45 <witek> for other changes feature freeze exempts have to be created
14:01:10 <witek> that's a new process for us but we moved to release-with-rc model in this cycle
14:01:26 <witek> all from me
14:01:30 <witek> thanks for joining
14:01:37 <witek> and see you next week
14:01:39 <bandorf> What does that mean for threshold replacement?
14:01:54 <witek> not ready in Ussuri
14:01:58 <bandorf> ok
14:02:14 <bandorf> thanks everybody, bye
14:02:23 <chaconpiza> thanks, bye!
14:02:24 <witek> bye bye
14:02:28 <witek> #endmeeting