08:00:45 #startmeeting Functest weekly meeting 28 Nov. 2017 08:00:45 Meeting started Tue Nov 28 08:00:45 2017 UTC. The chair is ollivier. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:00:45 The meeting name has been set to 'functest_weekly_meeting_28_nov__2017' 08:01:05 # info depo (Delia Popescu) 08:01:20 #info Cristina Pauna 08:01:26 #info Jose Lausuch 08:01:30 #info Cédric Ollivier 08:01:33 #info Juha Kosonen 08:01:33 #info Viktor Tikkanen 08:01:51 #info Linda Wang 08:02:01 #info Delia Popescu 08:02:13 #topic action points follow up 08:02:39 AP3 and AP6 done 08:02:54 #info rally db operations were updated and a bug fixed too 08:03:01 #link https://gerrit.opnfv.org/gerrit/#/c/47555/ 08:03:07 #link https://gerrit.opnfv.org/gerrit/#/c/47527/ 08:03:21 #info prepare_env were removed 08:03:40 #link https://gerrit.opnfv.org/gerrit/#/c/47267/ 08:03:56 #info AP1, AP2, AP4 and AP6 in progress 08:04:14 we will detail them in the next topics if required 08:04:29 #topic Euphrates 08:04:37 #info vEPC still under development (the container seems good) 08:04:53 #info the bug related to OS_AUTH_URL were fixed 08:05:01 #link https://jira.opnfv.org/browse/FUNCTEST-892 08:06:40 Be fre to add info for Euphrates? 08:07:12 depo_: CristinaPauna: What's the current status for ARM containers? 08:07:36 whell, functest works with arm containers on euphrates branch 08:07:40 and fails on master 08:08:01 on euphrates we still have prepare_env 08:08:08 yes. 08:08:45 on master even though I see the patch for aarch is being applied the tests fail staring with api_check 08:08:49 what does it fail in master? 08:09:07 oh ok 08:09:16 so, the framework stars correctly 08:09:21 it's the tests... 08:09:22 only connection_check from healthcheck is os 08:09:32 yes 08:09:34 I haven't checked the jenkins jobs. But now we can rely on the same jjobs for ARM64 and AMD64 08:09:48 yes 08:10:04 I'm working on fixing it for master 08:10:48 ok. I have seen some incompatible libc issues (mixing architectures) for several ARM runs. 08:11:16 #info functest works with arm containers on euphrates branch 08:12:08 ollivier: do you need help from us for the libc issues>? 08:12:54 CristinaPauna: we have to check if it's not related to manifests. 08:13:47 ok, we can sync on the details after the meeting 08:14:00 ok 08:14:14 #topic Releng 08:14:21 #info we should still implement the container garbage collector 08:14:31 oh yes 08:14:40 will do it this week for sure 08:14:47 Yes. No problem. 08:15:12 The most important is to have switched to multijobs and clean entry points. 08:15:47 cleaning containers will be done by our script. 08:15:58 #topic Fraser 08:16:07 yes, good job with that 08:16:21 Sure thank you all 08:16:22 how about leveraging --rm, so we don't need to clean containers 08:16:31 Yes but it's not enough 08:16:53 We have to clean the container images locally built. 08:17:08 and sometimes if the job fails or something, there are ugly leftovers 08:17:17 okey, --rm won't clean images 08:17:19 Regarding the common releng gc, we must take care of the order. 08:17:39 functest-core must be cleant at the end. 08:17:55 (after functest-smoke, etc...) 08:18:22 I would prefer we finish that before refactoring functest-components and functest-smoke. 08:18:42 (functest-smoke could inherit from functest-components) 08:19:03 #info all features are synchronized with OpenStack Pike and are enabled for F-release 08:19:05 yes, we would avoid installing twice the same 08:19:13 yes 08:19:33 #link https://gerrit.opnfv.org/gerrit/#/q/topic:opnfv/requirements 08:20:32 I think we can continue on modifying the copyrights (we haven't received any refusal from legal) as OpenStack has done 08:21:21 I must check milestones but we are more than ready regarding Features integration :) 08:21:39 is official copyrights guidance from OPNFV issued? 08:22:41 I think there is no issue. I haven't received any answer and we simply applied the same instructions as OpenStack 08:24:18 #info an email was sent about the new repository to host requirements 08:24:43 we are debating about a dedicated project and/or the possible hosting projects 08:24:50 I would suggest checking with OPNFV first before working on it 08:25:09 serena-zte: Yes. That's what we did. 08:25:16 in case OPNFV does not follow OpenStack 08:25:19 that's great 08:26:39 #info rally db operations were updated and a bug fixed too 08:26:45 #link https://gerrit.opnfv.org/gerrit/#/c/47555/ 08:26:54 #link https://gerrit.opnfv.org/gerrit/#/c/47527/ 08:28:02 juhak: LindaWang: I think there is a warning printing when creating the deployment (we could update the config?) 08:28:18 yes, i see 08:28:38 we need to update the log config 08:29:36 #action Linda,Juha to update the log config (rally) 08:29:38 Thank you 08:30:00 #info a new class to run any Robot Framework suites is proposed 08:30:22 Could you please review it? Be free to comment if you have any question. 08:30:22 that is a good idea 08:30:28 ok 08:30:47 ollivier: sure 08:31:31 ODL testcase looks like data conversions only now. But it's great to allow running any robot framework suites. 08:32:03 #link https://gerrit.opnfv.org/gerrit/#/c/47841/ 08:32:15 those tests: odl, odl_netvirt and fds? 08:33:12 ODL testcase (odl.py) only set variables required for odl robot suites (odl, odl_netvirt and fds) 08:34:01 any new odl related tests will be joined in future? I remember jose_lausuch said that 08:34:40 Yes. I remembered as well. And we must check if we can switch to netvirt test suites by default. 08:35:21 (I think I forwarded the discussion with Sam Hague: OVSDB PTL) 08:35:40 yes 08:35:49 I need to connect that discussion with the discussion in sdnvpn 08:35:56 they are also looking into odl tests 08:35:59 let me do that today 08:36:04 i have not received the email, could you forwad it to me? ollivier 08:36:16 sure. 08:37:13 about email, could you please send to my gmail from now on? 08:37:19 ok 08:37:40 now the company make some restrictions, I can not access zmail out side of company :( 08:38:06 and I can only access it in one computer now 08:38:22 thank you 08:38:31 #info the next testcases fail: snaps_smoke (partially induced by volume encryption), rally_sanity and tempest_smoke_serial 08:39:27 I think we could disable several tests if no installer can support them. What about volume encryption from the time being? 08:39:52 volume encryption are not supported by COMPASS yet 08:40:00 daisy as well 08:40:22 Yes and no useful run for the other installers. 08:40:41 they passed on Fuel 08:40:56 Ok. I have missed that. Thank you. 08:41:49 #info functest fails with arm containers on master 08:42:44 It would be great if a full run could be successful to validate the updates (OpenStack, rally, etc.) 08:42:53 #topic Functional Gating/Xtesting: 08:43:01 #info Dockerfile proposed to SDNVPN 08:43:45 jose_lausuch: could you please speak about that too during SDNVPN meeting 08:45:21 ollivier: I don´t attend sdnvpn meetings, maybe better per email 08:45:49 jose_lausuch: ok. wait and see. The email has already been sent. 08:45:59 ok 08:46:08 I am sure they will be interested in having xci runs for their gating 08:47:20 I would like now to discuss about the proposal to create new repositories for Functest. 08:48:03 Linda started a discussion on how to host Kubernetes testcases. 08:48:50 Could you please give your feedbacks? I think it's good to split them into multiple python packages then multiple git repositories. 08:49:12 Konrad has started working on a new container for k8s, https://github.com/djkonro/opnfv_functest_k8s/blob/master/alpine/Dockerfile 08:49:17 which is based on functest-core 08:49:30 #info Konrad has started working on a new container for k8s 08:49:37 #link https://github.com/djkonro/opnfv_functest_k8s/blob/master/alpine/Dockerfile 08:50:10 but we are not sure how many tests will be integrated into functest. because there are quite lots of kinds of tests, 08:50:24 we need to choose some from them 08:50:56 (Ideally we should remove gcc at the end as it's useless from runtime pov). 08:51:21 and when it comes to trigger and execute those tests, we could just use the binary of kubernetes. 08:51:50 ollivier: ok 08:52:39 but i am not sure if we need to create a new repo for k8s tests, cause for the time being, we have not started developing our own k8s tests. 08:52:47 but we agree on having a new k8 container from functrest-core? 08:52:59 functest-core installs a lot of openstack stuff that k8 doesn't need 08:53:00 jose_lausuch: yes, i agree 08:53:02 on what release? 08:53:06 but in the other hand, its our core... 08:53:09 depo_: master 08:53:16 ok 08:53:20 k8 container is for fraser 08:53:20 it's should be xtesting 08:53:26 yes 08:53:26 functest-core will remove those openstack stuff finally i think 08:53:33 from the time being we must inherit from functest core 08:53:47 so, shall we leave it for now functest-core and when xtesting is there we change it? 08:53:51 ok 08:53:56 let's do that then 08:53:57 exact 08:54:53 But it will be great if everyone gives feedbacks. We could ask for creating xtesting repo first then functest-kubernetes 08:55:51 ollivier: we have to ask, to create the repo, it could leave with the functest umbreall 08:55:53 umbrella 08:56:00 since all the repos need a responsible project 08:56:11 acording to the bylaw in opnfv 08:56:13 jose_lausuch: yes. we are working on that too 08:56:46 compared to requirements, Functest is the only choice for xtesting (aka new functest-core) and functest-kubernetes 08:57:13 yes 08:57:22 functest-kubernetes do you mean a new repo? 08:57:26 From the time being I would prefer that requirements is hosted by Functest too simply because of gerrit rights. 08:58:07 I think functest-kubernetes is a new container, right? 08:58:12 yes. It's maybe too early more if we select go for this part. That's the best way if we don't want to mix OpenStack and Kubernetes dependencies 08:58:50 but if we host it in functest for now and inherit from xtesting, it won´t have openstack libraries installed 08:59:00 btw, will we select some test cases from kubernetes like tempest/rally/snaps, or will we develop our own kubernetes test cases? 08:59:00 I think we all agree on the 3 containers. I think we should create 3 python packages simply to manage requirements. 08:59:01 in the end it´s functest tests 08:59:12 jose_lausuch: exact 08:59:38 it's just a proper way to manage python packages (and then the related requirements per package) 08:59:44 serena-zte: the idea is to first integrate and select from upstream, once that works, we will see. it would be interesting to create our own tests for telco deployments 09:00:19 yeah, agree 09:00:24 regarding xtesting, we could think about a dedicated project as the dev list could differ from functest. But it's too early and useless for this release. 09:00:45 I guess we can change the project ownership later on 09:01:12 yes. It will give us time to write the proposal before G if required. 09:01:28 yes 09:03:11 then it seems that I can ask for the new repo xtesting hosted by Functest (from the time being), no? 09:03:20 I think so 09:03:42 me too 09:03:56 new repo first 09:04:24 thank you. 09:04:31 #topic AoB 09:04:40 could we talk about the long duration test? 09:04:45 Which tests in Functest suitable for Bottlenecks to call as long during test? 09:05:04 Yes. I'm very sorry to be late. 09:06:47 I think we are more interested in multiplying tests. It could be great to run rally (or tempest/refstack) several times in a row. 09:07:27 It could help detecting remaining resources. 09:07:38 +1 for tempest smoke 09:07:46 and expect same results 09:07:46 full? 09:08:05 tempest_full contains about 1600+ tests 09:08:07 that would be great, but we don´t test full in CI 09:08:13 it would take so long 09:08:48 regarding long duration test, I think we could put tempest_full and rally_full into that area and asking for pod resources? 09:08:59 I remember morgan had worked on that before 09:09:00 +1 09:09:18 we could reuse functest-components. 09:09:23 yes, but not for bottlenecks 09:09:37 Bottlenecks has already had the pod resources, 09:09:42 that´s for the functest time slot, where we can run tempest full 09:09:52 but bottlenecks could use tempest smoke for repetability 09:10:08 what about rally? 09:10:18 rally as well 09:10:34 Why couldn't we use functest-components as "long duration" test ? 09:11:03 yes, that's for Functest long duration tests 09:11:28 we have not tested tempest_full, maybe lots of them will fail 09:11:31 but for bottlenecks using functest tests repeating them again and again, I would suggest temptes-smoke or other interesting things 09:11:47 but why donot we run functest-components? 09:12:13 what is the value of long duation test for functest? 09:12:14 As far as Bottleneck long duration is concerned, I think the test case should be stable and mature enough 09:12:25 it´s just my point of view 09:12:25 serena-zte: agree 09:12:34 serena-zte: +1, that's why I said tempest_smoke 09:12:39 because tempest_full and rally_full takes too much time 09:12:46 we don't have resources to run them 09:13:01 that's why we require 'long duration' pods for them 09:13:11 hope we can run them at least once aweek 09:13:25 The topic is long duration testing then 2 or 3 hours shouldn't be a problem. 09:14:08 We could propose running tempest-smoke as you're proposing. 09:14:35 I don´t know how many times bottlenecks runs the tests, but in vping it was several times 09:15:02 LindaWang, do you know what kind of test cases or which area are Bottleneck looking for? 09:15:02 I close the meeting as we are a little bit late (sorry). We could continue here if you're free or by mails. 09:15:03 sorry, need to leave some minutes 09:15:10 i think vping is also fine 09:15:34 #endmeeting