08:01:42 <jose_lausuch> #startmeeting Functest weekly meeting November 7th 2016 08:01:42 <collabot`> Meeting started Tue Nov 8 08:01:42 2016 UTC. The chair is jose_lausuch. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:42 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic. 08:01:42 <collabot`> The meeting name has been set to 'functest_weekly_meeting_november_7th_2016' 08:01:50 <jose_lausuch> #topic role call 08:02:24 <jose_lausuch> #info Jose Lausuch 08:02:41 <HelenYao> #info Helen Yao 08:02:45 <morgan_orange> #info Morgan Richomme 08:02:57 <bertys__> #info Bertrand Souville 08:03:10 <juhak> #info Juha Kosonen 08:03:13 <jose_lausuch> #info agenda for today here: https://wiki.opnfv.org/display/functest/Functest+Meeting#FunctestMeeting-08/11(8UTC) 08:03:19 <jose_lausuch> #info previous minutes: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2016/opnfv-functest.2016-10-18-08.00.html 08:04:47 <jose_lausuch> we have a long agenda today 08:04:47 <jose_lausuch> let' 08:04:50 <jose_lausuch> let's start 08:04:57 <jose_lausuch> #topic OpenStack summit recap 08:05:08 <jose_lausuch> #info we had productive meeting during the summit where many contributors from Functest were present 08:05:23 <jose_lausuch> #info participants: Morgan, Cedric, Juha K., Serena, Helen, Steve and myself 08:05:26 <jose_lausuch> do I miss anyone? 08:05:34 <SerenaFeng> #info SerenaFeng 08:05:39 <jose_lausuch> #info presentation that I used to follow the agenda points https://docs.google.com/presentation/d/15SzJ4NmhrxoVx5LfZ4hPYsDifKoNCLmVA7-oK4abyzw/edit?usp=sharing 08:05:43 <rohitsakala> #info rohitsakala 08:06:08 <jose_lausuch> #info we covered the main topics that we want to work for Danube: Framework refactor, CI evolution, Docker slicing and integration of SNAPS (which can be renamed). We missed some other smaller tasks, but they are for sure as important as these. 08:06:25 <jose_lausuch> #info there was another important session with Bitergia (Jesus) about integration of our results in their Dashboard. 08:06:39 <jose_lausuch> Morgan, do you want to elaborate that last thing a bit better? :) 08:07:04 <morgan_orange> yes 08:07:09 <morgan_orange> but we have a slot for that 08:07:21 <morgan_orange> #info sync with bitergia, we showed what we did so far 08:07:36 <morgan_orange> #info we described our different data sets (functest, yardstick) 08:07:42 <jose_lausuch> let' 08:07:48 <jose_lausuch> let's talk about it later then 08:07:49 <morgan_orange> #info bitergia proposed several scenarios to help us 08:07:53 <jose_lausuch> thanks 08:08:31 <jose_lausuch> as a summary it's perfect, thx 08:08:40 <morgan_orange> :) 08:08:43 <jose_lausuch> anything else to share about the summit? 08:08:56 <morgan_orange> I reference the meetup deck in the Danube page https://wiki.opnfv.org/display/functest/Functest+Danube 08:09:25 <morgan_orange> interesting discussion during the EUAG, seems that it is still not always easy to understand what we are doing 08:09:39 <HelenYao> It was nice talking to you F2F at the summit:) 08:09:48 <HelenYao> you = everyone 08:09:48 <morgan_orange> I initiated a discussion at TSC on priority for Danube 08:10:18 <jose_lausuch> #info initiated a discussion at TSC on priority for Danube 08:10:24 <jose_lausuch> HelenYao: it 08:10:35 <jose_lausuch> HelenYao: it's always great to have F2F from time to time 08:10:55 <jose_lausuch> please forgive my dummy finger pressing enter key... 08:10:58 <jose_lausuch> :) 08:11:17 <jose_lausuch> ok 08:11:22 <jose_lausuch> nex topic 08:11:26 <jose_lausuch> we have something to announce 08:11:32 <jose_lausuch> #topic Internships announcements 08:11:53 <jose_lausuch> #info we will have for sure 3 interns in Functest for Danube release. 1 is still pending. 08:12:08 <jose_lausuch> #info paper work is still ongoing, but they will be able to start soon. 08:12:43 <jose_lausuch> #info Ashish Kumar will work on Unit tests with Helen as mentor 08:12:51 <jose_lausuch> #link https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Functest+unit+tests 08:13:04 <jose_lausuch> #info Rohit Sakala will work on the test api project with Serena as mentor 08:13:20 <jose_lausuch> #link https://wiki.opnfv.org/display/DEV/Intern+Project%3A+testapi+evolution 08:13:48 <jose_lausuch> rohitsakala: congrats :) 08:13:55 <jose_lausuch> #info Girish Sukhatankar will work on the security groups test case mentored by David 08:14:01 <jose_lausuch> #link https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Security+groups+test+case+in+Functest 08:14:09 <rohitsakala> Thank you for the opportunity. 08:14:15 <morgan_orange> bertys__: on VNF catalog we should also have an intern...we suggest it to a student and got a second candidature... 08:14:32 <morgan_orange> that is the one pending mentioned by Jose 08:14:39 <bertys__> morgan_orange: thanks 08:14:41 <jose_lausuch> rohitsakala: very welcome ! 08:14:45 <juhak> something just came up, I have to leave the meeting now, sorry 08:14:46 <morgan_orange> yep welcome rohitsakala 08:14:55 <jose_lausuch> juhak: ok, no prob 08:15:04 <bertys__> great news indeed 08:15:08 <morgan_orange> juhak: we will action everything to you :) 08:15:27 <jose_lausuch> :p 08:15:39 <SerenaFeng> welcome rohitsakala 08:15:53 <morgan_orange> and our third mentor is also on the chan now 08:16:24 <jose_lausuch> morgan_orange: SerenaFeng maybe we could have a chat with rohitsakala about the task when he starts 08:16:57 <SerenaFeng> hangout? 08:17:09 <morgan_orange> jose_lausuch: SerenaFeng David_Orange as soon as the papers are signed, let's organized a "practice" session 08:17:10 <rohitsakala> Yes. Sure 08:17:13 <jose_lausuch> yes, why not 08:17:34 <HelenYao> how about Ashish Kumar 08:17:35 <SerenaFeng> okey, then I need to fix it as soon as possible :( 08:17:37 <David_Orange> morgan_orange: +1 08:17:49 <jose_lausuch> HelenYao: I think he is not here, but the same applies of course 08:18:21 <HelenYao> I might need some training about how to be a good mentor 08:18:31 <SerenaFeng> me too 08:18:41 <SerenaFeng> mentor for the first time 08:18:42 <jose_lausuch> HelenYao: I'm mentoring someone and I'm terrible ... 08:18:53 <jose_lausuch> but let's have a hangouts 08:18:57 <jose_lausuch> to talk about that 08:18:58 <SerenaFeng> sorry rohitsakala 08:19:09 <SerenaFeng> I hope I will be a good mentor 08:19:21 <HelenYao> jose_lausuch: you might have lessons to tell :-P 08:19:23 <jose_lausuch> I would like to postpone the topic about JIRA assignments sicne I haven't had the time to clean it up 08:19:23 <SerenaFeng> and I will try to be a good mentor 08:19:40 <rohitsakala> and I will try to be a good intern. 08:19:45 <morgan_orange> :) 08:19:50 <jose_lausuch> ok, that is very positive! :) 08:20:10 <jose_lausuch> #action Jose: clean up and make clearer our JIRA backlog, and send an email to all. Postpone topic for next week 08:20:27 <HelenYao> I like the energy here 08:20:39 <jose_lausuch> bertys__: as soon as I get an answer from the 4th intern, I'll let you know 08:20:53 <bertys__> jose_lausuch: thanks jose_lausuch 08:20:54 <jose_lausuch> otherwise, we can also run another interview if you like 08:21:10 <morgan_orange> #info 3rd intern is on security group / Mentor: David_Orange 08:21:28 <morgan_orange> #undo 08:21:50 <jose_lausuch> I infoed already, right? 08:21:56 <morgan_orange> yes 08:22:06 <jose_lausuch> ok:) 08:22:08 <jose_lausuch> #topic libraries and dependencies installed in Functest image 08:22:12 <jose_lausuch> hot topic now 08:22:22 <jose_lausuch> let me explain the background of this 08:22:25 <jose_lausuch> and let's comment 08:22:32 <jose_lausuch> #info We are having problems in CI due to failed Docker builds 08:22:40 <jose_lausuch> #info I have detected the problem and created this JIRA to keep the track 08:22:48 <jose_lausuch> #info things like pip install requirements try to install the same python modules but with different versions, specially the openstack clients 08:23:04 <jose_lausuch> #info this causes a loss of control over what we are installing 08:23:13 <jose_lausuch> #info for example, the problem of the image build in CI is kingbird requirements "RUN cd ${repos_dir}/kingbird && pip install -e ." 08:23:20 <jose_lausuch> #info we MUST be aware of what we install in the image. 08:23:37 <jose_lausuch> #info we should install the openstack clients that belong to the same openstack release, and not use random versions without any special reason. 08:23:54 <jose_lausuch> #info my proposal: centralize all the requirements installed by any project to a central requirements file and remove all the others (this will also save some lines in the Dockerfile) 08:23:58 <jose_lausuch> thoughts? 08:24:22 <HelenYao> I am with the idea of centralization 08:24:47 <SerenaFeng> agree 08:24:54 <morgan_orange> same for me butĀ could we reach a state where projects requirements would not be compatible 08:24:57 <jose_lausuch> HelenYao: how is OpenStack handling the versions? 08:24:57 <HelenYao> openstack runs into the same situation just like us. they have a project : https://github.com/openstack/requirements 08:25:22 <jose_lausuch> aha 08:25:37 <jose_lausuch> I think we could just have a flag to install the os clients 08:25:42 <jose_lausuch> like we do for the repos 08:26:00 <jose_lausuch> but the versions of the python clients are not all the same 08:26:06 <jose_lausuch> can some one dig into that? 08:26:08 <jose_lausuch> for example 08:26:15 <jose_lausuch> installing mitaka client versions 08:26:24 <jose_lausuch> something that we can update later on 08:26:24 <SerenaFeng> or maybe we can install the requirements when the feature project is executed 08:26:30 <HelenYao> we might need to do a general scanning for all the projects 08:26:31 <jose_lausuch> for newton or ocata for example 08:26:34 <jose_lausuch> just changing a flag 08:26:47 <HelenYao> i can work on this 08:26:53 <jose_lausuch> I detected some lines in the 08:26:58 <jose_lausuch> Dockerfile doing that 08:27:07 <jose_lausuch> tempest, rally, kingbird 08:27:15 <jose_lausuch> sfc (but I already removed that) 08:27:24 <jose_lausuch> ok, thanks 08:27:29 <HelenYao> i saw we hardcoded the project tag info in dockerfile, how is that value decided? 08:27:53 <jose_lausuch> #action HelenYao check what are the versions of the OS python clients related to a stable version of OS (starting with Mitaka) 08:28:18 <jose_lausuch> HelenYao: it's not decided, we lost the control of that 08:28:28 <jose_lausuch> I think we started having the right versions in Brahmaputra 08:28:37 <jose_lausuch> but now it's a mess of versions 08:29:09 <HelenYao> we have to restrict functest to a stable 3rd project to avoid their messy change 08:29:23 <jose_lausuch> #action HelenYao detect with lines in the Dockerfile are altering the OS python clients (i.e. tempest, rally, kingbird, ) 08:29:31 <jose_lausuch> yes 08:29:45 <HelenYao> the kingbird version change was introduced in Sep and our build failed after then 08:29:47 <jose_lausuch> and also, for some other common libraries, like scp for example 08:29:50 <morgan_orange> could it be manage through the abstraction created by Cedric trhough a prepare_env() or similar 08:29:58 <jose_lausuch> sometimes we install scp with a fix version and other projects install it and upgrade it 08:30:07 <morgan_orange> then we would check the project needs and centralize the requirement 08:30:08 <jose_lausuch> it would be nice to detect that as well, but it's not so critical 08:30:49 <jose_lausuch> morgan_orange: yes, if needed, but if we can have something common for everyone, it would be perfect, no extra effort, we just need to agree on the versions 08:31:04 <jose_lausuch> and I think we should use the clients that correspond to the System Under Test 08:31:12 <jose_lausuch> if we are testing mitaka, then use the mitaka clients 08:31:13 <jose_lausuch> and so on 08:31:42 <morgan_orange> jose_lausuch: makes sense 08:32:02 <HelenYao> taking the kingbird for example, it requires neutron > 5 and most of the projects only need 4. how can we pursude kingbird? 08:32:14 <morgan_orange> so first thing => audit of the existing and centralizsation somewhere with lib aligned with the target version 08:32:23 <HelenYao> there is a chance that, for mikata, version 4 is enought 08:32:54 <jose_lausuch> HelenYao: ok, feel free to propose a patch updating the versions of our requirements file 08:33:26 <jose_lausuch> we could create a requirements_os.pip or something like that 08:33:30 <jose_lausuch> only for the OS clients 08:34:17 <HelenYao> yeah, os clients are heavily used among projects 08:34:53 <jose_lausuch> good 08:34:54 <HelenYao> most of the version problems seem like client-stuff 08:35:09 <jose_lausuch> yes, at least in the build process 08:35:20 <jose_lausuch> we need to have more control about what pip install does 08:35:25 <jose_lausuch> good discussion 08:35:25 <jose_lausuch> which brings us to the next topic 08:35:33 <jose_lausuch> #topic Docker follow-up discussion and possible decision 08:35:53 <jose_lausuch> #info I created this patch to show how we could slice the image in the different categories https://gerrit.opnfv.org/gerrit/#/c/23729/ 08:36:00 <jose_lausuch> please all have a look and comment 08:36:15 <jose_lausuch> I posted the sizes of the image building in the associated JIRA 08:36:54 <jose_lausuch> sorry, not in JIRA, in the wiki 08:36:56 <jose_lausuch> #link https://wiki.opnfv.org/display/functest/Docker+images+slicing 08:37:40 <HelenYao> https://thepasteb.in/p/Q1hBnqPB4RjS8 08:37:55 <HelenYao> one trivial question about dockerfile, for ruby, we hardcoded a line with version 1.9.3 and it warned that the version is no longer maintained 08:38:08 <jose_lausuch> HelenYao: for that, we need to ask Valentin 08:38:15 <jose_lausuch> that is used for vIMS I think 08:38:20 <jose_lausuch> morgan can you contact him? 08:39:00 <morgan_orange> #action morgan_orange contact valentin regarding hardcoded ruby version that triggers warning 08:39:18 <morgan_orange> I think it is for the test in vIMS 08:39:41 <morgan_orange> we should remove the hardcoded version anyway 08:39:45 <morgan_orange> and adapt the script after 08:39:57 <HelenYao> that would be great 08:40:18 <morgan_orange> at the moment we run vIMS only manually (it is planned for weekly jobs that are currently never ru) 08:40:22 <HelenYao> jose_lausuch: did you push the image w/o kingbird to functest:latest? 08:40:34 <morgan_orange> so we can remove this I think 08:40:35 <jose_lausuch> HelenYao: yes, I did 08:40:59 <HelenYao> i tried with the latest and the neutron problem is still there 08:41:10 <HelenYao> the installer build is still failing 08:41:11 <jose_lausuch> morgan_orange: is valentin still allowed to commit ? :) 08:41:36 <jose_lausuch> HelenYao: really? 08:41:37 <jose_lausuch> mmm 08:41:44 <jose_lausuch> can you check what keystone version is installed? 08:41:49 <jose_lausuch> anyway, we can discuss it later 08:42:15 <jose_lausuch> #action HelenYao SerenaFeng morgan_orange and all check docker slicing proposal and provide comments 08:42:25 <jose_lausuch> need to move to next topics unfortunatelly 08:42:41 <jose_lausuch> or maybe we can spend 5 more minutes 08:43:10 <OPNFV-Gerrit-Bot> vijayendra radhakrishna proposed functest: Restructure SFC-ODL test cases https://gerrit.opnfv.org/gerrit/23969 08:43:24 <jose_lausuch> #action complete the slide with the "+" and the "-" about the docker slicing impacts 08:43:35 <jose_lausuch> #undo 08:43:35 <collabot`> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x215f610> 08:43:44 <jose_lausuch> #action jose_lausuch complete the slide with the "+" and the "-" about the docker slicing impacts 08:44:38 <jose_lausuch> HelenYao: you were working on a script to update the docker daemon, right? 08:44:52 <HelenYao> yeah. the script is ready 08:45:15 <jose_lausuch> is it in gerrit? 08:45:30 <HelenYao> no. i can commit it 08:45:48 <HelenYao> where/which folder shall i put it 08:45:59 <jose_lausuch> yes, please, although we still haven't a decission, it's ok to have it in gerrit, like mine with the Dockerfiles 08:46:04 <jose_lausuch> in /docker 08:46:17 <HelenYao> sure. i will commit it after the meeting 08:46:33 <jose_lausuch> ok, thanks 08:46:44 <jose_lausuch> i can test it on my local env as well 08:47:04 <jose_lausuch> ok 08:47:09 <HelenYao> awesome 08:47:11 <jose_lausuch> #topic Unit tests (repo structure/logger issues) 08:47:15 <jose_lausuch> morgan? 08:47:21 <morgan_orange> yep 08:47:21 <jose_lausuch> #chair morgan_orange 08:47:21 <collabot`> Current chairs: jose_lausuch morgan_orange 08:47:32 <morgan_orange> #info introduction of unit tests done in CI 08:47:52 <morgan_orange> #link https://build.opnfv.org/ci/view/functest/job/functest-verify-master/ 08:48:03 <HelenYao> the coverage report seems good 08:48:12 <morgan_orange> #info only ODL test today but system working locally and in Jenkins including coverage 08:48:42 <morgan_orange> #info however coverage is limited to the first tests we have (we clearly should extend) and I had to twist the config to make it work 08:48:46 <morgan_orange> #info 2 main issues 08:49:03 <jose_lausuch> #info only applied for master branch 08:49:09 <morgan_orange> #info 1 the repo structure: all our code is at the root level => issue with modules 08:49:35 <morgan_orange> #info we need to create a functest subdirectory in our repo to be sure that we will always have the same structure 08:49:44 <morgan_orange> today to make it work I need to cd .. 08:50:18 <jose_lausuch> what is the advantage of creating the functest dir then? 08:50:26 <pma> please have a look at (after meeting) https://build.opnfv.org/ci/view/functest/job/functest-docker-build-push-master/lastFailedBuild/console 08:50:28 <morgan_orange> #info 2 in some of our util class, we use the logger that logs in harcoded file 08:51:22 <morgan_orange> jose_lausuch: if we create a functest dir in our repo we can be sure we will have always the same tree 08:51:37 <morgan_orange> at the moment on verify we clone the repo as functest-verify-master 08:51:49 <morgan_orange> with the __init__.py at the root of the repo 08:51:56 <morgan_orange> we do not have functest.core ... 08:52:05 <jose_lausuch> can't we clone it just as "functest" ? does it make sense? 08:52:29 <morgan_orange> no because you can clone as you want..we cannot force people to always clone as functest 08:52:38 <morgan_orange> if they clone differently unit tests will not work 08:52:39 <jose_lausuch> aha ok 08:52:46 <morgan_orange> if we use functest subdir, it will always work 08:52:57 <jose_lausuch> well, we though of that only working for our container 08:53:03 <jose_lausuch> if we do it outside the container it doesnt work 08:53:07 <morgan_orange> yes 08:53:14 <HelenYao> About the advantage, by creating a functest folder inside and make it as a module, it will not run into the case morgan mentioned. also, by looking at other projects, opnfv and openstack, they are following the pattern we proposed 08:53:16 <jose_lausuch> but functest was though at the beginning to work only inside the container 08:53:17 <morgan_orange> and CI gating is done out of our containeur 08:53:46 <morgan_orange> jose_lausuch: also the unit tests? 08:53:48 <jose_lausuch> and then our python path variable will point to the functest root dir right? 08:53:55 <morgan_orange> jose_lausuch: yes 08:53:55 <SerenaFeng> but unittest will not run under container 08:54:04 <jose_lausuch> no, now it's a new thing 08:54:14 <jose_lausuch> so ok 08:54:18 <jose_lausuch> we need to do it 08:54:21 <jose_lausuch> to be safe 08:54:22 <morgan_orange> unittest shall be runnable anywhere.... 08:54:28 <HelenYao> +1 08:54:36 <morgan_orange> and we will just follow OpenStack and other project pattern 08:54:54 <jose_lausuch> #info decission on creating functest root dir and move all the tests and tools inside 08:55:04 <jose_lausuch> where do we put unit tests? 08:55:14 <jose_lausuch> does it make sense to put it also in /functest? 08:55:18 <jose_lausuch> or separate root dir? 08:55:24 <jose_lausuch> as you proposed 08:55:24 <morgan_orange> yes (last discussion initiated by helen) 08:55:29 <SerenaFeng> functest/tests/unit 08:55:32 <HelenYao> how about funtest -> tests -> units 08:55:49 <morgan_orange> just a question on shall it be functest/tests/unit-tests, functest/unit-tests, functest/tests/units 08:55:53 <HelenYao> units -> unit 08:55:53 <jose_lausuch> we already have a testcases dir 08:56:13 <jose_lausuch> I would like to avoid confusion 08:56:20 <SerenaFeng> I think it's ok 08:56:21 <HelenYao> i think the name of testcases is a bit confusing 08:56:36 <SerenaFeng> all OpenStack project put unit tests under xxx/tests/unit 08:57:00 <SerenaFeng> it seems like tests/unit is defined to be unit test 08:57:01 <jose_lausuch> ok, if we say functest/tests/unit, where do we put the testcases? 08:57:10 <morgan_orange> yes but OpenStack projects are not test projects as we are... 08:57:16 <morgan_orange> Rally follow the same rule? 08:57:17 <HelenYao> yeah, agree with Serena. I am going for functest/tests/unit 08:57:41 <jose_lausuch> what about this 08:57:43 <SerenaFeng> to functest, testcases is a module 08:58:00 <SerenaFeng> not a tests 08:58:11 <jose_lausuch> we move all the testcases into functest/tests/ 08:58:39 <morgan_orange> just check rally follow the same design pattern tests/ci tests/functional tests/unit 08:58:42 <HelenYao> the tests fold is meant to include the script to verify the project itself. we might need to work out a new name for 'testcases' as it is about the project biz 08:59:06 <jose_lausuch> morgan_orange: +1 08:59:36 <SerenaFeng> no for move all testcases into functest/tests 08:59:53 <HelenYao> no + 1 09:00:08 <jose_lausuch> SerenaFeng: then, where do we put them? 09:00:16 <morgan_orange> no + 1 = -1 ? :) 09:00:20 <SerenaFeng> thinking 09:00:30 <jose_lausuch> https://github.com/openstack/rally 09:00:31 <HelenYao> my bad :-P 09:00:44 <jose_lausuch> https://github.com/openstack/rally/tree/master/tests 09:01:11 <morgan_orange> https://github.com/openstack/tempest 09:01:23 <morgan_orange> no tests folder in tempest :) 09:01:36 <morgan_orange> oops 09:01:39 <morgan_orange> no 09:01:47 <morgan_orange> https://github.com/openstack/tempest/tree/master/tempest 09:01:50 <jose_lausuch> yes, there is https://github.com/openstack/tempest/tree/master/tempest/tests 09:02:18 <OPNFV-Gerrit-Bot> Merged functest: Restructure SFC-ODL test cases https://gerrit.opnfv.org/gerrit/23969 09:02:21 <SerenaFeng> they have tests folder 09:02:29 <morgan_orange> yes my bad :) 09:02:38 <jose_lausuch> then? 09:02:45 <jose_lausuch> what do we agree on? :) 09:03:12 <morgan_orange> I would say follow the OpenStack way create tests/unit 09:03:14 <HelenYao> to me, the 'testcases' is similar to 'services' in rally 09:03:17 <morgan_orange> push unit tests here 09:03:25 <morgan_orange> and think if we should rename/move testcases 09:03:38 <SerenaFeng> agree 09:03:38 <morgan_orange> but I am in line with Helen 09:03:43 <jose_lausuch> ok 09:03:49 <jose_lausuch> #info agree to rename testcases 09:03:51 <jose_lausuch> rename to what 09:03:54 <jose_lausuch> services? 09:03:55 <morgan_orange> so we can agree on just creating tests/unit 09:04:00 <SerenaFeng> don't know how to express my thinking in English 09:04:06 <SerenaFeng> rename would be great 09:04:13 <jose_lausuch> we agree on creating /functest/ and /functest/tests/unit 09:04:15 <HelenYao> +1 on tests/unit 09:04:55 <jose_lausuch> /tests/unit or /functest/tests/unit ? 09:05:03 <jose_lausuch> is "tests" root? 09:05:04 <morgan_orange> ollivier: I think you missed the Daylight saving time change :) 09:05:06 <SerenaFeng> functest/tests/unit 09:05:13 <morgan_orange> yes 09:05:26 <jose_lausuch> ok 09:05:29 <SerenaFeng> put tests under subdir functest 09:05:42 <morgan_orange> who is doing the change.. 09:05:55 <ollivier> morgan_orange: oops... sorry 09:05:56 <HelenYao> functest/tests/unit. i was just a bit lazy to input the full path:( 09:05:57 <jose_lausuch> #action morgan_orange propose a patch with the new dir structure as initiated by email 1) Create /functest 2) create /functest/tests/unit 09:06:09 <morgan_orange> jose_lausuch: ok 09:06:33 <HelenYao> i can work on the change 09:06:44 <jose_lausuch> ok 09:06:45 <ollivier> tests/unit is redundant if we don't add functional tests, isn't it? 09:06:53 <jose_lausuch> we are over time 09:06:57 <morgan_orange> ollivier: for the moment yes 09:07:04 <morgan_orange> but we just follow OpenStack pattern 09:07:15 <jose_lausuch> morgan's idea and mine was to have /functest/tests/unit /functest/tests/functional/ 09:07:17 <morgan_orange> and may add additional tests later... 09:07:20 <HelenYao> we have to leave the door open for other level of tests 09:07:43 <ollivier> there are functional tests in OpenStack... I don't think we will add them. But we can follow these guidelines. 09:08:18 <morgan_orange> ollivier: yep there was a discussion on are our testcases functional tests or services if we consider OpenStack naming 09:08:26 <morgan_orange> so far for me it is more services 09:08:35 <morgan_orange> we do not have functional tests on the framework itself 09:08:41 <jose_lausuch> but the name "services" is more confusing that "testcases" ? 09:08:55 <morgan_orange> no rush for renaming... 09:09:07 <HelenYao> yeah, no rush for renaming 09:09:09 <ollivier> #agree 09:09:13 <jose_lausuch> then we will have 2 dirs "tests" and "testscases" :) 09:09:17 <SerenaFeng> agree, we can come up with a better name later 09:09:39 <SerenaFeng> naming is always a headache 09:09:48 <HelenYao> #agree 09:09:50 <ollivier> maybe testcases should be renamed instead. 09:09:59 <jose_lausuch> ollivier: yes, we were saying that 09:10:09 <jose_lausuch> 1 porposal is renamed it to "services" 09:10:22 <HelenYao> a good name might occur while taking a bath:-P 09:10:44 <jose_lausuch> HelenYao: that's a great idea... 09:10:59 <jose_lausuch> #action jose_lausuch follow up discussion on dir structure and naming 09:11:21 <jose_lausuch> ok 09:11:27 <jose_lausuch> we have 1 topic left, but I think there is no time 09:11:31 <jose_lausuch> and morgan_orange already said some words 09:11:35 <jose_lausuch> do you want to add something else? 09:11:50 <HelenYao> i may work on the structure over the time before next meeting 09:12:21 <jose_lausuch> HelenYao: perfect, propose a patch and we can review it and follow up the discussion there 09:12:22 <jose_lausuch> thanks 09:12:29 <HelenYao> sure 09:13:29 <jose_lausuch> #action jose_lausuch move bitergia discussion for next weekly 09:13:33 <jose_lausuch> #endmeeting