07:00:30 #startmeeting masakari 07:00:31 Meeting started Tue Feb 9 07:00:30 2021 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:00:34 The meeting name has been set to 'masakari' 07:00:37 #topic Roll-call 07:00:41 \o/ 07:01:39 o/ 07:02:18 hi jopdorp 07:02:35 suzhengwei is on holidays (lunar new year celebration) so let's start 07:02:39 #topic Agenda 07:02:51 * Roll-call 07:02:51 * Agenda 07:02:51 * Announcements 07:02:51 * Review action items from the last meeting 07:02:51 * CI status 07:02:51 * Backports pending reviews 07:02:52 * Release planning https://etherpad.opendev.org/p/masakari-wallaby-vptg 07:02:52 * Open discussion 07:03:06 #topic Announcements 07:03:11 I have none 07:03:23 Me neither 07:03:43 we are at R-9 07:04:00 so it's very very close to freeze and release 07:04:16 in fact feature freeze and the 3rd milestone is in 4 weeks 07:04:26 need to merge some features! 07:04:26 Ok 07:04:33 #topic Review action items from the last meeting 07:04:37 there were none 07:04:42 #topic CI status 07:04:56 green now 07:05:14 we were hit by alembic upgrade that caused taskflow to fail 07:05:21 but that was quickly handled 07:05:29 #topic Backports pending reviews 07:05:45 and there are none! 07:05:54 Ha! 07:05:59 #topic Release planning https://etherpad.opendev.org/p/masakari-wallaby-vptg 07:06:05 any progress on these points? 07:06:15 What about the features we should get merged? 07:07:19 right 07:07:32 I guess the enabling/disabling segments is very close 07:07:46 we just need to do it nicely 07:07:53 or as nice as we can afford to 07:08:06 others are a bit further off 07:08:25 gladly this cycle was nice for its bugfixes and I have some pending ones up my sleeve 07:08:48 but that's about it from me - could not get enough priority on it 07:09:05 well, we still have 4 weeks till freeze 07:09:23 and I will accept freeze exemptions if changes are safe enough not to break the whole thing 07:11:13 I did creste add a blueprint that goes with the auto reenable hosts a while ago 07:11:21 Create* 07:12:03 ah, yes, I remember 07:12:15 I think I did not get much time to digest it though 07:12:29 do you have a prototype implementation to see as well? 07:12:41 No 07:12:51 But I could make it 07:13:12 Not sure l'll be able to get it into the release though 07:13:41 Although in the end a lot can be done in 4 weeks 07:14:56 that's true 07:15:26 I have one important deadline this week so can't promise anything about reviewing things 07:15:37 Ok 07:15:48 (though I sometimes relax by reviewing changes) 07:16:04 Should I have a look st enabling/disabling segments? 07:16:07 anyhow, please be welcome to propose a prototype 07:16:15 at least it will be ready for the next cycle 07:16:18 I think you did 07:16:21 Yeah 07:16:28 you can check it again though 07:16:30 I had some comments 07:16:36 in the client 07:17:02 If su is on vacation I may be able to create a new patch 07:17:19 Or is that agaonst etiquette? :P 07:18:16 if you know how to tackle the issue, then please do 07:18:20 we can always revert 07:18:29 Ok 07:18:31 I think the priority is to get the feature in 07:18:42 not dwell on who worked the most on it 07:19:09 Yeah 07:19:35 all right 07:19:39 #topic Open discussion 07:19:52 if there is anything else... I'm all ears 07:20:18 Nothing here 07:20:33 Oh 07:20:37 Maybe this 07:20:56 Do you have any idea of the tempest tests? 07:21:22 Is it our responsibility to uodate those too? 07:21:33 Update* 07:21:52 Do they even exist? 07:23:49 the story is the following 07:24:02 if you look closely at our functional tests job 07:24:10 it's not the expected functional tests job 07:24:21 it actually sets up the whole environment with devstack 07:24:42 and runs "functional tests" 07:25:07 they are almost like integration tests but their coverage is a tad bit less than what one would expect from integration tests 07:25:22 ok 07:25:26 so we don't have masakari in tempest 07:25:37 but this job kind of aspires to do that 07:25:49 complicated, I know 07:26:01 also, there is this job that runs in NTT 07:26:23 which I have no idea what it tests because I have not received any e-mail back 07:26:33 Right 07:26:43 We don't have access to that source code? 07:26:53 nope 07:26:58 it's some black box 07:27:01 Weird 07:27:31 yup, but NTT really is not obliged to tell us 07:27:39 I hoped they would tell me 07:27:54 The functional tests are supposed to be unit tests? 07:28:03 but I am not planning to write to all NTT folks with questions, already wrote to 3 addresses 07:28:08 apart from the mailing list itself 07:28:22 nope, the unit tests are unit tests 07:28:24 they are there 07:28:33 in these tox-py36/8 jobs 07:28:50 Should we at some point migrate the integration tests to tempest and write unit tests in our functional tests? 07:29:00 our current functional is between what normally is functional and integration 07:29:32 because in functional one expects to still try to isolate parts 07:29:38 I guess I'm not clear on what should be the difference between functional and integration tests then 07:30:24 well, in unit tests you fake the code state (functions environments) and test code parts (functions) 07:30:47 in functional testing you fake the app environment and test the app 07:30:49 Then unit tests one class, functional tests multiple classes, but all inside out project and integration tests also use a live keystone and nova? 07:31:03 Our* project 07:31:06 so, the assumption would be you don't actually spin up nova for masakari functional testing 07:31:15 Yeah got it 07:31:18 And we do 07:31:26 functional tests actually "run the apps" 07:31:32 yup, that's it 07:31:39 and that should be done via tempest jobs 07:31:50 but then again the actual coverage of integration 07:31:55 is not that great 07:32:03 it's a good point 07:32:13 but I'm afraid we are extremely understaffed 07:32:25 to do that AND do something visible to the users 07:32:41 but still, I am tempted to improve testing coverage 07:32:46 always :-) 07:32:53 Hehe 07:33:02 Yeah tests can be relaxing to write 07:33:05 https://assets.mugglenet.com/wp-content/uploads/2016/01/Always.gif 07:33:16 Haha 07:33:45 not only that, but the peace of mind one can get from knowing the testing pipeline and coverage are sane 07:33:52 Are there coverage reports somewhere? 07:34:20 not sure, but they are only ever calculated for the unit tests I think 07:34:28 try `tox -e cover` 07:34:33 Ok 07:34:54 I don't understand why 07:35:34 Any test framework usually has coverage reports right? 07:36:19 Most stuff I do for myself has all three kinds of tests using the same framework 07:36:46 Then you can generate the coverage reports separately, but also the combined coverage 07:37:02 I am pretty sure the limitation is fictitious and boils down to the general lack of order :-) 07:37:18 Yeah 07:37:57 Lol 07:38:09 Off-topic 07:38:28 I'm hapoy that they finally merged in my s3 backup driver for cinder :p 07:38:49 well, congrats! 07:39:00 then more time for masakari! :D 07:39:08 Haha yes! 07:39:44 I'm also happy we don't have as complicated politics as there 07:40:42 well, it would be impractical to apply anything now with the current developer base 07:40:56 so running off common sense only 07:41:20 Yeah 07:42:28 thank you for the meeting jopdorp 07:42:31 I think we can close the meeting 07:42:37 #endmeeting