08:06:45 #startmeeting Functest weekly meeting 26 June. 2018 08:06:45 Meeting started Tue Jun 26 08:06:45 2018 UTC. The chair is ollivier. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:06:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:06:45 The meeting name has been set to 'functest_weekly_meeting_26_june__2018' 08:06:53 #info Cédric Ollivier 08:06:56 #info Viktor Tikkanen 08:07:03 #info Juha Kosonen 08:08:22 #topic Action point follow-up 08:08:53 #info logs have to be improved (add debug flags) 08:09:57 #info tempest test could run in parallel as for refstack 08:10:20 viktor_t: juhak: what's your feelings about that? I think we have a try 08:10:43 You mean we have to try? 08:11:27 I would suggest to run them in parallel in master. It seems fine here. 08:11:46 It seems to be reasonable 08:12:28 thank you. 08:12:39 #info it seems that tempest_full has to be updated (it has to conform with Neutron's tempest full) 08:13:09 I think Neutron doesn't run all tempest tests in gates. I have to check that. 08:14:09 As discussed in LA, I would like to introduce tempest and rally full in all gate. If we can, it would be great to force 100%. 08:14:30 +1 08:16:01 #info Delia Popescu 08:16:08 Regarding a topic discussed last week, a new opnfv/functest-tempest was published. It mainly allows refactoring many Dockerfiles. 08:16:16 Hello Delia 08:16:53 #topic Functest Gambia 08:17:09 #info 6 new scenarios are now offered: tenantnetwork[1,2], vmready[1,2], singlevm[1,2] 08:17:30 it avoids duplicating code as for vnfs 08:17:38 it eases writing testcases for endusers (e.g. shaker: https://gerrit.opnfv.org/gerrit/#/c/58501/) 08:17:43 all testcase config sections will follow the same rules (about overlays, extra flavor specs, etc.) 08:17:47 it could allow easily cleaning all remaining resources 08:18:29 They can be seen as intermediate steps to boot vm reachable via ssh 08:18:51 looks great, you have been busy again 08:19:37 Yes but that's not the worst point. You have to know that I'm facing with troubles regarding them. 08:20:22 I added them as intermediate testcases in Healthcheck to allow gating them and to detect the right deployment error 08:21:04 There is a quite huge debate which is overpushed because I added new testcases in healthcheck 08:22:00 It's increased by the fact that I moved odl, cinder and vping into healthcheck as well. 08:22:04 I still going through the changes but saw some discussion about that 08:23:35 are there some scenarios which don't pass healthcheck anymore? 08:24:39 Regarding a global functional scope, I'm even not sure that it changes someting. I do check if one snaps test in api_check asks for metadata. 08:25:54 Badly installers haven't run them since yesterday. I would bet that only sdnvpn could be impacted by that if I understood correctly their tempest issues. 08:26:28 I don't see the point to run smoke if two vms can't ping each others or if ODL api is unreachable. That was my point. 08:27:05 Please let me know your feelings. I can simply revert that changes. 08:27:39 Maybe you need time to read the new classes. 08:27:54 https://gerrit.opnfv.org/gerrit/#/q/status:merged+project:functest+branch:master+topic:scenarios 08:27:58 https://gerrit.opnfv.org/gerrit/#/q/status:merged+project:functest+branch:master+topic:shaker 08:29:27 depo: could you please run healthcheck vs arm? 08:29:53 It will fail with ping 08:30:18 ollivier: will check new classes, but anyway the basic requirement for successful ping test sound reasonable 08:30:36 depo: due to ping or deployment ? Could you please share functest.log 08:30:38 no, it does not, not for an initial release 08:31:05 juhak: thank you 08:31:11 we are having noe problems with vm console, mysql issues, is under fix 08:31:19 console is useless 08:32:08 It is OK if it is (still) possible to run other tests (like smoke etc.) manually even if healthcheck fails. 08:32:22 I hear you, but for me healthcheck should mean that openstack is installed and it answers to API checks ( like it has a heart beat.. ) 08:32:37 not ping, at least not in such a short time 08:32:44 maybe later 08:33:18 healthcheck is designed for the daily build isn't it? We may propose daily releases vs which the enduser can't boot a vm. 08:33:34 If we do so, we have to remove api_check and snaps_healthcheck 08:34:05 I am not saying that, we will fix the issues by Friday 08:35:09 you asked my opinion, I say we cannot enforce ping on Monday for Friday 08:35:17 ok. I thought it was about moving vping in smoke again. 08:35:28 it is 08:36:05 we cannot enforce anyone to have ping on healthcheck since we have MS on Friday 08:36:36 it's not about the move itself, it's about the timing 08:36:50 The problem is not milestone here. We can temporarily disable it if needed for Friday. 08:37:20 From an overall point of view, do you agree that vping is part of healthcheck? 08:37:24 it kind of is the milestone 08:38:12 later, after MS, we can debate what goes into gating, but we should also implicate installer people and TSC 08:38:37 and also gating is not about having tests in healthcheck 08:38:58 it's about what we decie to be reasonable enough criteria 08:39:37 I don't understand how TSC could be involved in testcases selected in Functest tiers. If we follow that Fatih'm model, we are not free to rename or add a testcase. 08:40:52 Even adding one specific test in healthcheck (tenantnetwork which simply configures a tenant network) is raising concerns. 08:41:29 I agree but installer release /MS depend on functest, we cannot enforce them rules for release either 08:41:59 There are two sides: a) vping is a very basic functionality and therefore it could belong to healthcheck b) if healthcheck will fail for some reason (e.g. because of ODL problem etc.), the side effect is that other test cases which wwill potentially pass (like most of smoke test cases) will not be executed at all 08:42:36 we can add/rename tests, but not for the suits that are relase/MS criteria without conulting with people who are impacted by this 08:43:32 a) +1 b) fully true. But it's the same as vpings are the first testcases 08:43:35 in smoke 08:44:46 Maybe atrole may pass even if vping is false. neutron_trunk? 08:44:46 so if vping will fail in smoke, no other tests will be executed? 08:44:50 yes 08:45:39 We temporarily turn off the mandatory flag when rewriting vping testcases but it has been the config for Functest realeases. 08:45:53 It was my opinion already years ago that vping is actally quite challenging test case since it requires that everythings works properly :) 08:45:53 I think it's back to mandatory 08:47:07 yes, it is , but not at MS3.2 08:47:28 we just ported Queens 08:47:44 My opinion is its the basics requirement for an enduser installing OPNFV. Even if we can tolerate issues for advanced cases (controller) 08:47:47 at this point is expected not to be very functional 08:48:22 I would propose to disable the test for several installers in failure to be fair. 08:48:48 But moving it to smoke again seem the wrong way. 08:48:52 it's not fair 08:49:02 Does everybody agree on that? 08:49:22 to be fair regarding milestones. 08:49:39 why not creayte a separate tier for them? 08:49:44 *create 08:49:52 A new tier for vping? 08:49:53 like.. advanced_healthcheck 08:50:08 advanced_hwalthecheck that requires ping 08:50:35 Basically I agree with ollivier. But if you will move vping/vping_userdata back to smoke, move them to the end of smoke tests... 08:50:52 We are not able to add a test in healthcheck. I can't imagine what could happen if we propose a new tiers. 08:51:14 we can try 08:51:59 viktor_t: yes. we will do so. 08:52:17 I will propose the review. 08:52:33 #info connection_check is now leveraging on Shade 08:52:47 #info APEX mster is well verified via tempest_smoke_serial (+Apex promotion snapshot -> functional gating) 08:53:31 About tempest (reused by Dovetail) 08:53:39 we may ease include/exclude tempest subtests via simple regex or service (it would avoid the full lists from Dovetail) 08:53:44 we may add a flag to return False if one subtest is skipped (Dovetail) 08:54:32 #info shaker arm64 image is being shared 08:54:52 depo: I send you a link to send the image. Thank you in advance 08:55:10 ollivier: sure 08:55:22 #topic AoB: 08:56:18 anything else? 08:56:51 not from me 08:57:04 no 08:57:38 nothing from my side 08:57:42 Thank you very much for that interesting discussions. 08:57:47 #endmeeting