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