08:13:16 #startmeeting Functest weekly meeting 19 Dec. 2017 08:13:16 Meeting started Tue Dec 19 08:13:16 2017 UTC. The chair is ollivier. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:13:16 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:13:16 The meeting name has been set to 'functest_weekly_meeting_19_dec__2017' 08:13:37 hi 08:14:40 Linda is part of a internal conference and she wasn't sure to come today. 08:15:07 ah ok 08:15:26 Let's see if someone else joins... Else we will focus on your best choices :) 08:15:43 hi 08:15:46 ok, let's wait a bit 08:15:49 hi serena-zte 08:15:52 hi Serena 08:16:36 hi jose_lausuch ollivier 08:17:09 Sorry for having a little bit late. Trains work well in France except today :) 08:17:19 hehe no problem 08:17:29 hi 08:17:29 maybe we can cancel it 08:17:37 depo_ is here too 08:17:51 let's discuss topics that are not clear 08:17:54 yes 08:17:56 like the docker cleaning 08:18:19 Yes I will just print the other actions. 08:18:22 ok 08:18:42 #info action point follow-up: 08:18:51 #info 1 patch to review/merge https://gerrit.opnfv.org/gerrit/#/c/44677/ 08:19:00 #info release notes were updated (12/12 AP1) 08:19:03 thank you Jose 08:19:11 #info a first proposal about Docker container garbage collector has been published  (21/11 AP1) 08:19:14 np 08:19:50 The first proposal was ok regarding the previous model but now we must delete functest-core at the end 08:19:59 before we come to that 08:20:00 regarding tagging the repo 08:20:08 did we need to create only 1 tag? 08:20:25 https://gerrit.opnfv.org/gerrit/gitweb?p=functest.git;a=tag;h=refs/tags/opnfv-5.1.0 08:20:32 that one 08:20:56 I did it by hand (simply I create new manifests refering to last arm and amd64 images) 08:21:06 I guess we don't need opnfv-5.1.RC1 08:21:16 #info Linda Wang 08:21:39 no I haven't created it. It's quite useless and our classic latest and euphrates are better. 08:21:43 Agree? 08:21:45 Hi Linda 08:21:50 Hi ollivier 08:21:51 ok 08:22:04 #info SerenaFeng 08:22:08 it is useless, yes, but the instructions were saying that… a bit unclear 08:22:12 hi LindaWang 08:22:18 let's leave it as it is 08:22:21 another point 08:22:32 you built the docker images with the tags we have in the release notes, right? 08:23:22 To be very precise. The tag is put to the last git commit id for which new containers (amd64-euphrates and arm64-euphrates) have been built. 08:23:46 ok 08:23:49 Then I simply created new manifests without rebuilding the containers which were already good. 08:24:05 but we should also build amd64-opnfv-5.1.0 and arm64-opnfv-5.1.0 as we say in the docs 08:24:16 #info Juha Kosonen 08:24:35 Hello Juha. 08:24:39 https://gerrit.opnfv.org/gerrit/#/c/48727/5/docs/release/release-notes/functest-release.rst 08:24:47 https://git.opnfv.org/functest/tree/docs/release/release-notes/functest-release.rst#n104 08:24:50 last one sorry 08:25:19 We could update the docs. I think arm64- and amd64- are for internal purpose. Only manifests should be used by end users. 08:25:57 It's not a big deal. 08:26:10 what I mean is that we have released that doc telling the users to use that tag, and the tag doesn´t exist in dockerhub :) 08:26:18 jose_lausuch: are you ok to apply this minor updates? 08:26:53 we should only set the manifests instead of specifying the containers per arch. 08:27:22 then we should remove those lines in the release notes 08:27:29 yes 08:27:31 but the repo has been already tagged for release... 08:27:37 isn't it too late? 08:27:42 I think the doc is always updated 08:28:07 I will create the internal tag to conform with docs 08:28:07 ah 08:28:10 ok 08:28:26 #action Jose update release notes to simply list manifests 08:28:46 we can add in the release notes that amd64-euphrates is more convenient since it contains latest bugfixes 08:28:55 #action Cédric to publish new tags to conform with the documentation published 08:29:08 euphrates instead 08:29:35 ok, yes 08:29:38 euphrates -> (amd64-euphrates or arm64-euphrates) 08:29:50 right 08:29:56 agree to precise we prefer rolling release simply because it integrates bugfixes. 08:30:13 And we must apply actions for orchestra* (next topic) 08:31:12 sure 08:31:18 Regarding Docker gc, we should take of the list passed as args simply because the script can be called by hand too (also called via travis-ci). 08:31:35 if functest-core is listed, it should be remove at the end. 08:32:12 Could we switch to the next topic: Euphrates? 08:32:25 ok 08:32:38 #topic Euphrates 08:32:47 #info next corrective was released last week (December 15) 08:32:55 #info vyos_router should run well for all installers 08:33:04 #info to double check if there are caching issues when running Functest daily jobs vs Compass and Fuel 08:33:33 They seem fine but the vnf orders differ from installers. We should be careful about that 08:34:16 the vnf orders differ from installers still? 08:34:35 the new latest functest-vnf image has been pushed. 08:35:00 so i guess next run shall be fine, at least on Compass 08:35:01 When checking all results together but I think it's fine. I would prefer a double check 08:35:29 i checked the latest functest-vnf on Compass 08:35:55 I could be wrong because gerrit preserves the date when published not merged. 08:35:59 the image built on Dec 15th must have some issue. 08:36:05 yes, maybe 08:36:33 #info orchestra_* testcases failed due to unmet dependencies in packages 08:36:44 #info to disable orchestra_* testcases in all installers? only installers which configure https endpoint? 08:37:07 That's the key point. Orchestra testcase only run well on Daisy 08:37:39 #link https://jira.opnfv.org/browse/ORCHESTRA-17?src=confmacro 08:37:48 #link https://gerrit.opnfv.org/gerrit/#/c/49053/ 08:37:59 i would prefer disable them at least on Compass until they are fixed. 08:38:23 For Compass it seems clear because of https endpoint. 08:38:47 The question is about Apex and Daisy. 08:39:06 so shall we disable them on compass and fuel first? But why did it fail on Apex? 08:39:51 It's about management network reachability. It seems that Daisy allows a VM to reach management endpoints 08:40:15 https://gerrit.opnfv.org/gerrit/#/c/49183/ 08:40:30 I think it would be better to contact fuel first before disable it, does they have the intention to fix it, or are they ok with disable it 08:40:39 We could backport it and check if it works for Apex as well. 08:41:54 Fuel already highlighted all the issues. Regarding vnf they are lots of different results regarding the vnfs. We must be clear about the conditions (http vs https, public vs internal...) 08:42:57 Let's wait the next answer. From the being Functest returns OK for several installers (Orchestra is not part of Functest) 08:43:16 #action Cédric to backport https://gerrit.opnfv.org/gerrit/#/c/49183/ 08:44:21 Compass team prefer to disable them before https issue is fixed. 08:44:40 since it takes quite a long time to run orchestra_* 08:44:56 https://gerrit.opnfv.org/gerrit/#/c/49053/ could have been merged. The point is to fully disable it or not 08:45:51 Regardign the last comment in the JIRA ticket, they will only fix Fraser not E 08:46:03 Then it will be disabled at least for Fuel and Compass. 08:46:07 i would give +2 08:46:14 yes 08:46:40 ok. We could merge the first proposal. We will complete it by removing the next installers if needed. 08:46:49 ok 08:48:29 #info Fraser 08:48:33 #topic Fraser 08:48:43 #info we successfully reached the milestone 3 08:48:47 Thank you all. 08:49:03 #info config files are now patched in memory 08:49:14 #info lots of improvement in Functest (supporting python3, fixing yaml and pylint errors/warning, increase coverage) 08:49:23 #info a request was sent to LF to create the 3 new repositories (functest-requirements, functest-xtesting, functest-kubernetes) 08:49:38 #info they were created last night. 08:49:51 Good to know 08:50:01 great 08:50:06 functest-k8s tests shall be ready soon 08:50:21 I'd like to create 2 tests first 08:50:33 one is k8s_smoke 08:50:45 the other is k8s_conformance 08:50:53 they are all tested locally 08:51:03 Konrad will publish them soon 08:51:35 Perfect. Thank you. It would be great to implement a kind of healthcheck (MS3) too and to develop first possible framework updates (MS4) 08:51:35 sounds good too 08:51:41 we can enable them in joid and compass soon 08:51:43 but i am wondering do we have to create a new tier for k8s? or just 2 new tests? 08:52:00 tier is easier, I would say 08:52:02 We could create the same tier as they are separeted containers. 08:52:07 yep 08:52:08 ok 08:52:28 healthcheck makes sens in both Kubernetes and OpenStack 08:53:09 when it comes to Jenkins Job, we need to download images only required by specific tests or tier 08:53:13 The question is more about how we will integrate the new testcases. go or python? 08:53:29 python as a trigger 08:53:32 as usual 08:53:35 inheriting from testcase 08:53:35 yes agree 08:53:48 Especially for installer verify job, only cirros image is required 08:53:48 or BashFeature if it calls go. 08:53:49 and then using go as command or if there is a library in python better 08:53:55 yes 08:53:57 it is Bash 08:54:12 then Bash feature can make more sense 08:54:30 like this:/e2e.test --provider=local --ginkgo.focus="/[Conformance/]" 08:54:34 ok. then it seems fine. Xtesting will be published soon (I am playing with git sparse checkout) 08:55:25 #action Linda,Konrad to publish first kubernetes testcase 08:55:34 e2e.test is compiled binary 08:56:08 #action Cédric to finish moving core models from functest to xtesting 08:56:26 #link https://jira.opnfv.org/browse/FUNCTEST-887 08:57:21 I put 2 actions already proposed by mails. 08:57:37 #action Linda to improve check_deployment (Gambia milestone 3) 08:57:56 #action Juha to remove Ceilometer tests failing in rally sanity (they seem obsolete) 08:58:09 I'll submit a patch to blacklist them today 08:58:10 why do we have to obtainer tokens instead of socket 08:58:13 thank you 08:58:19 in general, discussion about ceilometer scenarios on Pike ongoing with Rally team 08:58:39 ollivier: good morning 08:58:47 opening a socket is not enough because it only tests a web server 08:58:55 fdegir: good morning 08:58:55 juhak:rally/ceilometer is still supported by Rally stable/0.10 ? 08:58:57 ollivier: is there a way to disable/blacklist certain test cases from healthcheck for xci? 08:59:23 ofc. But I think it's not relevant for the current heat issue 08:59:54 LindaWang: yes 09:00:34 I think connection_check is more relevant because it tests basic calls. I would like to move connection_check directly inside check_deployment 09:01:00 then healthcheck won't run if prerequisites are unmet (MS3) 09:01:25 or we could stop checking deployment and then MS3 is about the status of connection check. 09:01:38 ollivier: I'm not sure where heat issue originates from 09:01:47 ollivier: i think volume type encryption releated tests have been updated by Steven. 09:01:48 is it from heat itself or from osa 09:02:01 trying to get some response from osa first and then will go to heat 09:02:03 fdegir: It's next topic. It seems there is an issue regarding heat-engine 09:02:11 fdegir: It would be better to check the detailed log 09:02:23 sorry - I didn't notice you were having meeting 09:02:24 #info to finish juju_epc integration (they still remain errors) 09:02:36 fdegir: no pb. XCI is part of the meeting 09:03:06 Cedric - we will work with you over email on the juju_epc integration issues ... 09:03:06 let's check the next result on installer deploying http endpoint. 09:03:51 thank you. No we enforce an versioned endpoint as juju doesn't manage the keystone version discovery as it's requested in Pike. 09:04:24 I'm not sure there is a relevant run in Apex (not running), Joid or Daisy. 09:04:31 Right - Juju doesn't manage that ... 09:04:48 #link https://gerrit.opnfv.org/gerrit/#/c/49135/ 09:05:02 #info to debug Functest when deploying via XCI (issues during any basic heat operations) 09:05:53 Currently heat basic calls don't work on intel pod 16. The credentials seem right but we must go into deep analysis as fdegir is proposing :) 09:06:38 I dont' understand why there is no heat engine container. And heat engine config is not listed as param. 09:06:59 (I precise log is empty) 09:07:16 the log has stuff in it 09:07:21 I'll keep you updated 09:07:24 only heat api. 09:07:38 yes we could debug it right after the meeting 09:07:49 #topic AoB: 09:08:19 I will be on holidays for the next 2 weeks (+ several days off after as well) 09:09:16 We could cancel the next functest meetings as TSC/release meeting. 09:09:19 Agree? 09:09:48 okey, happy Christmas day 09:09:56 ollivier: Cool. Merry Xmas 09:10:16 Thank you. Jose, I think you will be off too ? 09:10:47 no, I will be working 09:10:55 but we can cancel it 09:11:03 not sure if I will be all the day working 09:11:12 merry xmas :) 09:11:13 oh :(. ok. we can cancel it. Be free to reuse the slot to discuss. 09:11:45 Merry Xmas to everyone ... 09:11:54 I will give a training course the first two weeks in January (OpenDaylight). I will be partially working for OPNFV (50%). 09:12:44 no conflict regarding regarding the meetings. 09:13:08 Something else to add? Else we can close the meeting. Sorry again to be late due to my train. 09:13:19 no from my side 09:14:21 ok. thank you very much. I was a great working week. 09:14:26 #endmeeting