08:06:18 #startmeeting Functest weekly meeting 23rd of May 08:06:18 Meeting started Tue May 23 08:06:18 2017 UTC. The chair is morgan_orange. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:06:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:06:18 The meeting name has been set to 'functest_weekly_meeting_23rd_of_may' 08:06:22 #topic call role 08:06:29 #info Morgan Richomme 08:06:37 #info Cédric 08:08:01 if we are only 2, I think we can cancel....did I miss anything on this meeting? 08:08:19 #info SerenaFeng 08:08:25 Hi Serena 08:08:29 #info Linda Wang 08:08:40 Hi morning 08:09:01 Shuya_ool: BTW I am working on vnf refactoring (abstraction class) it may have some impacts. I hope I could submit the patch this week... 08:09:21 now we are 3, which is better but a bit light for any discussion 08:09:23 #info Shuya(OOL) 08:09:30 #info Helen 08:09:58 ok seems we hae a quorum now :) 08:10:08 #topic action points follow up 08:10:44 #link http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2017/opnfv-functest.2017-05-16-08.00.html 08:10:46 morgan_orange: OK, I will do refactor the vyos_vrouter testing. 08:11:01 Shuya_ool: so no rush until the patch is available.. 08:11:03 #info AP1 jose_lausuch work on the 'enabled' flag patcvh 08:11:05 #info done 08:11:06 Cedric Ollivier proposed functest: Call fetch_os_creds.sh from $PATH https://gerrit.opnfv.org/gerrit/35169 08:11:16 #info AP2 morgan_orange valentin review vnf accoring to framework changes 08:11:18 hi 08:11:20 sorry for the late 08:11:23 #info Jose Lausuch 08:11:26 morgan_orange: Sorry, I got it. 08:11:37 #info in progress, hope I can submit something before the end of the week 08:11:47 thanks for starting it 08:12:08 #info it will have impact on the existing cases: orchestra_ims, cludify_ims, opera_ims, and future vrouter 08:12:20 LindaWang: Please see the update of https://gerrit.opnfv.org/gerrit/#/c/35169/. Be free to ask any question if unclear. 08:12:27 #info but it shall be cleaner and with respect of rules adopted in testcases and features 08:12:41 #info AP3 morgan_orange update test case description with new catalog description field 08:12:44 #info done 08:12:58 #link http://testresults.opnfv.org/test/api/v1/projects/functest/cases 08:13:09 feel free to comment if you do not agree on the description 08:13:12 yardstick also did it 08:13:26 so at least functest and yardstick shall be ready for the case catalog page 08:13:37 cool 08:13:38 #info AP4 morgan_orange move from amazon hosting to opnfv resources 08:13:50 there are some test cases from feature projects that still need that field 08:13:53 #info done, aricg shall provide the VM this week 08:13:55 ollivier: Thank you. 08:14:10 #info AP5 morgan_orange contact Dave (Urschatz) to see if container suite could be done with functest/cengn mentor 08:14:18 #action contact Dave (Urschatz) to see if container suite could be done with functest/cengn mentor 08:14:22 there is an intern 08:14:26 who may work on that soon 08:14:37 #info but new intern seems working on that (mentoring narinder) 08:14:56 need to xcheck with David, he needs an access to a community lab 08:15:12 #info AP6 HelenYao sync with jack Chan for internal API 08:15:18 HelenYao: any update on this point? 08:15:33 Url('/yardstick/asynctask', views.Asynctask, 'asynctask'), 08:15:33 Url('/yardstick/testcases', views.Testcases, 'testcases'), 08:15:33 Url('/yardstick/testcases/release/action', views.ReleaseAction, 'release'), 08:15:33 Url('/yardstick/testcases/samples/action', views.SamplesAction, 'samples'), 08:15:33 Url('/yardstick/testsuites/action', views.TestsuitesAction, 'testsuites'), 08:15:34 Url('/yardstick/results', views.Results, 'results'), 08:15:34 Url('/yardstick/env/action', views.EnvAction 08:15:49 yardstick has these urls 08:16:01 we have tier while they have testsuites 08:16:12 also, they have release/samples for testcases 08:16:48 do we put tier or testsuites in the api? 08:16:57 tiers or testsuites 08:16:59 we agreed on tiers... 08:17:05 the ones in the test diagram 08:17:09 for me tiers and testsuites are different..tempest, odl are testsuites (i.e. several tests) 08:17:14 ya 08:17:15 tiers are just categories 08:17:18 Cedric Ollivier proposed functest: Call fetch_os_creds.sh from $PATH https://gerrit.opnfv.org/gerrit/35169 08:17:18 tiers=categories 08:17:27 test suites=bunch of tests (can be in any category) 08:17:36 yep 08:17:41 same view 08:17:58 so I think their APi coudl be used, minor adaptations needed, no? 08:18:13 #chair jose_lausuch 08:18:13 Current chairs: jose_lausuch morgan_orange 08:18:33 #info AP7 to publish framework prez' 08:18:39 i think firstly we have to agree on the functest api definition 08:18:42 do not remember what was this poitn? 08:19:02 HelenYao: ok, could you make a proposal on the wiki?, so we could validate it next week? 08:19:12 I think it was from ollivier 08:19:31 I suggest to do follow functest cli way, HelenYao make a draft on wiki 08:19:40 then we can review and comments 08:20:02 ok 08:20:06 Yes. We could define new artifacts for framework prez' and apidoc 08:20:30 but we have to see also what to do with the developer guide 08:20:33 (as now tox generates the api docs) 08:20:39 they are targetting similar purposes 08:20:46 no. 08:21:09 we should avoid duplicating certain information 08:21:10 #action HelenYao prepare wiki page for Functest APi proposal (CLI / yardstick approach) 08:22:00 for developer guide, I created a developer guide at the testing group level (just a draft for the moment) 08:22:07 I think we have bigger issues than several duplicated data in docstrings, and framework presentation... 08:22:12 what is common shall be there, what is specific shall remain on our side 08:22:38 right 08:22:38 #info dev guide: work to spli common and functest specific stuff 08:22:50 the test api should be common for example 08:22:52 #link https://gerrit.opnfv.org/gerrit/#/c/35179/ 08:23:03 I will also modify the functest doc 08:23:25 but generated doc is really cool, as well as the console view on code quality... 08:23:33 good practice to be shared... 08:23:40 agree 08:23:47 It's not a dev guide. 08:23:52 But it makes sense :) 08:23:59 #action SerenaFeng jose_lausuch review https://gerrit.opnfv.org/gerrit/#/c/35179/1 08:24:22 It look like a readme.rst on root of functest 08:24:23 well, we explain the framework, how it works, etc 08:24:23 it is really a draft because Jack mentioned it during a mail exchange 08:24:36 but that is almost empty, we need to agree on the chapters.. 08:24:38 we will care about reorganizing the docs later 08:24:52 #info AP7 to create a Jenkins job for api doc 08:24:53 we will have a session with Sofia in the summit 08:24:59 #info I think it is done but not enabled 08:25:47 for those who did not see the last enhancements in the verify job 08:25:48 https://build.opnfv.org/ci/view/functest/job/functest-verify-master/4161/console 08:25:53 Please use docstings as much as possible instead of managing by hand 08:26:00 rst... 08:26:08 you can see now that unit tests can be executed offline, tests are executed towards several env (preparation for py3 support) 08:26:26 cool 08:26:45 I like the message at the end: congratulations :) 08:26:51 and all the files have now a mark ... that should help us to converge to a better quality.. 08:27:07 cover: 89% 08:27:25 ollivier: running it with my changes on vnf leads to the explosion of *_ims (as they are not adapted yet) :) 08:27:51 ok back to the agenda then 08:28:05 be careful. there are lots of alse positives in tests and mainly the last 5% is hard :) 08:28:05 #topic JIRA management rules 08:28:28 this comes from a conversation I had with Cedric 08:28:40 we should make use of JIRa the same way 08:28:45 but before that 08:28:57 I would like to ask you if it makes sense to create sprints 08:29:06 we didn't use them in the right way in Danube 08:29:19 we probably need to be more attached to milestones 08:29:28 instead of 3-week sprints 08:29:55 what do yiou think? 08:30:23 yep more realistic to stick to milestones 08:30:32 sprints are a bit artificial 08:30:41 sprints are barely used 08:30:44 they don't make sense for these type of work 08:30:44 ya 08:31:08 and less useless work for the PTL 08:31:29 #agree JIRA: no sprint / stick on Milestones 08:31:30 we know we have milestones, for example framework ready 08:31:31 agree 08:31:44 so our focus is in finishing the framework 08:31:45 as we are doing 08:31:49 and things like that 08:32:41 when we go towards milestone : test case ready 08:32:50 we need to focus on finishing the test cases 08:32:56 or in parallel 08:33:03 we are all not working on framework 08:33:14 and another thing 08:33:40 we shouldn't create a bug-jira for something we can fix 08:33:56 I mean, if I find a bug in Functest, it's ok just if I work on the patch 08:34:11 jira-bugs are more for things that need to be remembered 08:34:19 ollivier: would you like to express your opinion on that? 08:35:28 jose_lausuch: sure 08:35:40 If I find a bug, but I could not solve this. What should I do? 08:35:59 I think there is no need to open JIRA tickets for bugs concerning your testcase in master. 08:36:05 then it's fine to report it I would think 08:36:22 We should tag as bug all fixes we have to backport on stable 08:36:49 As soon as the patch is merged we cherry-pick it to the right stable branch 08:37:27 but the question from LindaWang is what to do with bug you cannot solve by yourself.. 08:37:36 the risk is to forget it 08:37:45 ya, then you can report it 08:37:46 it's fine in this case if you assign to someone else 08:37:57 Ok. 08:38:00 for me it is fine in this case to create a JIRA as well 08:38:11 please remember to put the fix versions field 08:38:22 but we do not need to create artificially jira load for things we know we can solve 08:38:26 but be careful about the version (next release here) 08:38:27 exactly 08:38:38 JIRA is not a tracker to know our activity (git/gerrit is the right place) 08:38:52 I think we should focus on gerrit and JIRA should be mainly used by external people 08:38:54 but if we cannot solve issues, then it is good way to remember 08:39:07 and assign 08:39:07 I will do a cleanup this week I have time 08:39:20 I have done one last days... 08:39:22 too 08:39:23 ok so I think we all agree.. 08:39:25 I know 08:39:35 next topic? 08:39:36 thanks about it 08:39:44 #topic Progress on framework 08:40:04 #info as said in action point follow-up: work in progress for VNF part 08:40:04 so, apparently, releng repo was removed from the dockerfile 08:40:06 why? 08:40:32 Yes! It's better to manage it via requirements.txt 08:41:21 mmm 08:41:27 I am not sure if any other file in releng is required other than fetch_os_creds.sh. 08:41:28 so now it's installed via requirements? 08:41:38 so the only problem is fetch_os_creds... 08:41:40 we can do the following 08:41:48 if only that file is required 08:41:54 Now we can imagine splitting docker containers if we stop cloning them in Dockerfile instead of several requiremetns 08:41:55 we just do it in the jenkins job 08:42:56 The only issues are induced by the fact we will detect all the bugs in setup.py (see snaps, releng...) 08:43:01 and we mandate functest to be created with the RC file as a volume 08:43:11 I saw snaps... thanks for fixing 08:43:17 will you fix releng? 08:43:28 please see https://gerrit.opnfv.org/gerrit/#/c/35183/ 08:44:04 ollivier: ah ok, awesome 08:44:08 but what do you think guys? 08:44:18 There is a big issue in releng related to duplicated setup.py but I will fix it when I finish functest 08:44:20 shall we create the container with the RC as a volume? or we leave as it is 08:44:49 It would be better to first manage correctly requirements.txt. 08:45:18 I clean it when I finish tox support but it remains a lot of external projects 08:45:27 ok 08:45:51 more things 08:45:53 then we can imagine switching to Alpine and offer several containers. 08:47:04 But this is the base... of any python project 08:47:04 ollivier: ok, we can think of that later, not sure if it will be ready for this release 08:47:04 LindaWang: you found some issue with tempest -offline 08:47:04 It seems more reasonable to create the container with the RC as a volume, cause except different testcases run for different installers, there is no need to pass the param INSTALLER_TYPE. 08:47:10 INSTALLER_TYPE is good to have in CI 08:47:21 it's not mandatory for outside OPNFV 08:47:33 but it is interesting to have to collect some information from the installer 08:47:41 You can set INSTALLER_TYPE = debian if you have your own database 08:47:44 but we can prepare the RC file as a volume 08:48:11 if we do so, we don't need fetch_os_creds in the container and we can forget https://gerrit.opnfv.org/gerrit/#/c/35183/ 08:48:29 we just need to tweak the jjob 08:48:34 that is how it is done with joid today 08:48:39 yep 08:48:42 OK. The issue is sometimes you do not know the INSTALLER_TYPE. 08:48:56 Of not. This file must be in setup.py 08:48:56 in CI we always know 08:49:15 I believe functest is not only just for CI. 08:49:17 If a python project project defines scripts it must install them as well 08:49:39 Here by cloning directly git repository, we mask the real mistakes. 08:49:45 ollivier: yes, but if we do it this way, we don't need it in functest then 08:50:04 I mean, fetch_os_creds 08:50:08 I will work on the jjob today 08:50:12 Sure. But still this file exist in repo, it must be installed. .. called or not 08:50:13 to be called only by jenkins 08:50:26 why? 08:50:34 if it's not used by functest, why should we have it? 08:50:34 it 08:50:40 it's not part of the releng modules 08:51:04 It is... 08:51:15 I think releng is not the right place to fix the problem 08:51:17 it is now, but with the changes in the jjjob, we won't need it 08:51:40 releng should not be modified just b/c functest needs it in a specific way 08:51:41 ?? 08:51:49 HelenYao: if we automate the creation of the cotnainer with the RC file as a volume, we don't need anymore fetch_os_creds in Functest 08:52:05 Please. Releng offer a script. It must installed it. 08:52:08 and we require that in the documentation when crating the container 08:52:23 ollivier: releng offers 1000 scripts, most of them are not used in Functest 08:52:38 for example, to do the upload to artifacts 08:52:44 i vote for mapping rc file to container 08:52:46 that is done in the JJOB, not by Functest 08:53:15 amazing.. That's a simple packaging task... 08:53:32 mapping rc file to container +1 08:53:37 let me work on that today and I will add you to the review 08:53:46 I am a bit lost, I am not sure we are speaking of the same thing, aren't we? 08:53:51 you don't understand the point. 08:53:59 morgan_orange: yes. 08:54:30 as far as I understand the idea is to adopt the joid way to get rc file and get rid of the fetch_os which is used for fuel, apex and compass) 08:54:47 morgan_orange: yes, taht's the point I'm trying to bring 08:55:08 the script is not needed, we need only the rc file 08:55:13 but I'm trying to fix a current issue.. 08:55:23 and to explain how we deal with requirements.txt 08:55:39 but this current issue will be fixed by that proposal 08:55:41 and setup.py 08:55:49 we won't need fetch_os_creds any more 08:56:09 i agree with putting the dependencies in requirements.txt 08:56:11 there is no other releng requirements? 08:56:17 agree also 08:56:20 morgan_orange: no 08:56:28 morgan_orange: only the ones used by the directory modules 08:56:29 And??? As long as the script could called by any opnfv functest, it must be installed when calling setup.py 08:56:51 if not I can simply switch my change to remove os_fetch... 08:57:19 that's simple packaging work 08:57:32 ollivier: but I don't get that, sorry, maybe I'm confused 08:57:38 why do we want to call it? 08:57:39 it is good to clean requirement management 08:57:50 Please don't break all the pending work 08:57:53 i think functest needs to find a way to adopt with releng instead of changing releng to accommodate functest. if mapping the rc file can remove the dependency of releng shell script, we are done here 08:57:55 and it is also good to clean the way we are tetrieving the rc files 08:58:29 but we should keep all the work done to manage external requirmeents 08:58:35 and be cleaner 08:58:38 HelenYao: by mapping you mean having the docker volume or putting it in setup? 08:58:50 having docker volume 08:58:56 ok 08:59:16 in that way, fetch_os_rc.sh will not needed by functest 08:59:23 yes, that's my point 08:59:34 refstack also does it this way 08:59:57 fetch_os_creds is a CI thing, only valid for OPNFv, then, we keep it out of functest 09:00:03 I understand. but will you delete the file? 09:00:12 in functest yes 09:00:16 no globally 09:00:21 but it will be still used by CI (releng) 09:00:30 so let it in setup.py please 09:00:30 I will use it in the jjob 09:00:59 ollivier: there are many more scripts in that directory https://git.opnfv.org/releng/tree/utils 09:01:07 why should we just keep 1? 09:01:19 those util scripts are used by jenkins jobs only 09:01:22 because it's designed as external 09:01:24 i have the same concern as Jose 09:01:36 it's pointless to leave only that script in setup.py 09:01:42 if it's not used by the modules directory 09:02:07 normally releng should install the script and called them from path. As usual, it's cloned and run from working dir. 09:02:16 basic rule. 09:02:41 but now it's intalled by requirements 09:02:48 please read setup.py documentation 09:02:52 which is the right way 09:03:27 I don't want to fix now releng's setup.py I have to finish the framework for the 5th... 09:03:33 Then I will switch to releng 09:03:49 Functest is enough from the time being 09:03:59 ollivier: don't fix that, it's not your job, there are other people as well :) 09:04:20 my view is the new mechanism (requirmeent based) is the right one but it is not needed for fetch_os 09:04:44 if we need external stuff, we should adopt it (i.e. no more cloning as we were used to do) 09:04:54 It must be installed if jobs stop cloning the repo 09:05:18 jjob could start by a simple pip install 09:06:00 that's another story... 09:06:06 it must be installed if jobs stop cloning the repo and if it is used 09:06:30 we need to close.. 09:06:37 we can continue offline 09:06:42 #endmeeting