08:01:16 #startmeeting Functest weekly meeting November 15th 2016 08:01:16 Meeting started Tue Nov 15 08:01:16 2016 UTC. The chair is jose_lausuch. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:01:16 The meeting name has been set to 'functest_weekly_meeting_november_15th_2016' 08:01:20 jose_lausuch: hey 08:01:28 #chair morgan_orange, HelenYao, SerenaFeng 08:01:28 Current chairs: HelenYao SerenaFeng jose_lausuch morgan_orange 08:01:33 #topic role call 08:01:36 #info Jose Lausuch 08:01:39 #info Morgan Richomme 08:01:39 #info CristinaPauna (ENEA) 08:01:40 #info SerenaFeng 08:01:42 #info Juha Kosonen 08:01:43 pound in your names 08:01:49 #info Helen Yao 08:01:53 HelenYao: hey :) 08:01:55 #info hideyasu_ool 08:02:03 #info Jie Hu (escalator team) 08:02:06 #info agenda for today here: https://wiki.opnfv.org/display/functest/Functest+Meeting#FunctestMeeting-15/11(8UTC) 08:02:30 #info previous minutes: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2016/opnfv-functest.2016-11-08-08.01.html 08:03:06 #chair juhak 08:03:06 Current chairs: HelenYao SerenaFeng jose_lausuch juhak morgan_orange 08:03:09 #topic Action point follow-up 08:03:41 #info action: HelenYao check what are the versions of the OS python clients related to a stable version of OS (starting with Mitaka) 08:03:57 I think it is related to this other one 08:03:57 #info action: HelenYao detect with lines in the Dockerfile are altering the OS python clients (i.e. tempest, rally, kingbird, ) 08:04:09 #info we will discuss it later, but I created this page showing that info: https://wiki.opnfv.org/display/functest/OpenStack+python+clients 08:04:22 we have a topic for this discussion 08:04:33 #info AP harcoded version of ruby in docker: I contacted valentin, it shall be possible to remove ref to hardcoded ruby version even if it is direcly inherited from Metaswitch test suite, so to be tested...but as we are not running vims a lot (planned for weekly job only), we can remove the dependecy 08:05:02 morgan_orange: ok, can I action you to remove it? 08:05:11 #info patch for the new structure submitted and merged, master branch is now using the new structure 08:05:13 jose_lausuch: yes 08:05:28 #action morgan_orange remove ref to hardcoded ruby version 08:05:43 #info note it was just a basic structure without any changes in the path management and/or file renaming 08:06:03 but that was the task about 08:06:13 after some troubles, we have it running in CI 08:06:15 so good job 08:06:24 #info action: HelenYao SerenaFeng morgan_orange and all check docker slicing proposal and provide comments 08:06:43 i left the comment before the meeting 08:06:50 well, I have an idea for an alternative to docker remote api: docker compose 08:07:10 sorry not a lot of comment from my side, I just discussed offline with Cedric which was thinking to use something that looks better than Ubuntu for what we want to achieve 08:07:12 we could run containers in parallel to run parallel test 08:07:29 #action HelenYao jose_lausuch SerenaFeng check if things could work with docker compose 08:07:49 morgan_orange: yes, he proposed another OS 08:07:54 is cedric in the office today? 08:08:06 jose_lausuch: the thing with // testing -especially for smoke - if it works you saved time, if it fails you have to find the root cause 08:08:18 if we want to deploy the container at the same time, docker compose is one solution 08:08:33 docker remote api could be used to deploy container on demand 08:08:34 you can create dependencies between containers as well 08:08:40 for some tests, it makes sense parallelization 08:08:43 for others it doesnt 08:08:45 jose_lausuch: yes - I planned to have lunch with him today. Unfortunately he was assigned with internal project at least until beginning of december 08:08:50 for the blocking tests, we can setup dependencies 08:09:00 for the other (tempest/rally/fetures) we can run in parallel 08:09:07 but we need to change the openstack cleanup logic 08:09:13 otherwise we will wipe everything 08:09:19 oh, he is here 08:09:21 ollivier: hi 08:09:24 for example on tempest we moved to serial , it fixed some issues that were not easy to troubleshoot 08:09:34 jose_lausuch: hello 08:10:01 is the decision whether docker slicing is to be done or not settled? 08:10:01 ollivier: I have proposed to have a look at docker compose to see if we could benefit from the slicing, instead of remote api 08:10:12 ollivier: what OS did you propose for the container instead of ubuntu? 08:10:41 HelenYao: it is not settled, it's a difficult decission I think, and we need to have a prototype and demo it to see if it works as expected 08:10:43 if yes, I don't need to investigate virtualenv further and there is a patch about virtualenv if you are interested 08:10:55 jose_lausuch: Alpine? https://hub.docker.com/_/alpine/ 08:11:01 HelenYao: virtualenv for rally could make sense though 08:11:07 ollivier: what do we gain with Alpine? 08:11:26 It's built around musl libc 08:11:34 space 08:11:38 ok 08:11:43 we can try 08:11:46 to save some MB 08:11:57 ubuntu base image takes around 200 MB I think 08:12:07 yes there is no rush but we should have a look too it 08:12:07 according to the page Alpine 16MB versus Ubuntu 232MB 08:12:21 but need to see if we can use it for our needs... 08:12:23 we should save space for every package 08:12:31 would that change a lot the way we install things? 08:12:44 if it stop installing docs ... 08:12:53 docs? 08:13:24 #info ollivier proposes to use Alpine https://hub.docker.com/_/alpine/ (~16MB base image) instead of ubuntu (~200MB base image) 08:13:36 when you install a deb, there are other files than libs and binaries. For instance docs locales 08:13:46 ok 08:14:05 #action jose_lausuch HelenYao have a look at building the docker image with Alpine 08:14:13 ollivier: also you if you have time :) 08:14:15 ok 08:14:21 we didn't start a topic for this 08:14:30 let's start with the first topic 08:14:31 #topic New JIRA assignments 08:14:55 I've been cleaning up JIRA 08:14:55 jose_lausuch: I would like to work it. but I can't niw. 08:15:01 and creating the sprints 08:15:04 ollivier: ok, no problem 08:15:27 #link https://jira.opnfv.org/browse/FUNCTEST-558?filter=11115 08:15:43 I created an epic for the intern projects we have 08:15:44 ollivier: good to know Alpine, it's a new way of looking at docker slicing 08:16:00 security groups, api evolution, unit tests 08:16:12 and by the way 08:16:15 in this EPIC https://jira.opnfv.org/browse/FUNCTEST-541 08:16:33 you will find all the tasks related to all the adaptation to TestCaseBase that ollivier did 08:16:49 this is some work to do, so feel free to pickup whatever you feel like :) 08:17:04 #action all: contribute to the testcase adaptation EPIC: https://jira.opnfv.org/browse/FUNCTEST-541 08:17:11 I may ad an Epic on the reporting evolution or I can use the CI evolution Epic 08:17:20 I tihkn if everyone of us contribute a bit with this epic, we can get it done soon 08:17:53 morgan_orange: ok 08:18:04 as you wish 08:18:10 #link https://wiki.opnfv.org/display/functest/_Functest-Danube+release+schedule 08:18:19 I created 7 sprints, starting from first of this month 08:18:24 yep that is for adopting what ollivier did and illustrated for ODL, makes sense to adapt our existing test cases 08:18:33 so the first sprint is finishing this week 08:18:51 I did this way to finish the 7th sprint on the release date 08:18:54 plans might change 08:18:58 it would also make sense to create a Vnfbase or something like that to offer an abstraction for VNF onboarding as we have feature onboarding now 08:18:58 but I think it's ok for now 08:19:04 take 1 minute to go though the wiki 08:19:07 and the calendar 08:19:41 morgan_orange: that task is already created 08:19:43 great JIRA job! 08:20:14 jose_lausuch: I can see, this is a real Epic with lots of tasks... 08:20:16 morgan_orange: https://jira.opnfv.org/browse/FUNCTEST-535 08:20:23 jose_lausuch: I have to say, you are good at wiki page presentation 08:20:42 hehe Thanks!! 08:20:42 :) 08:20:46 he is good at everything... 08:21:00 come on, don't make me blush :p 08:21:04 +1 08:21:21 +2 08:21:30 thanks :) 08:21:47 although I don't have the real power to +2 :-P 08:21:49 so, whenever you start with a task, put the current sprint 08:21:52 so shall we share the load on current test case adaptation 08:22:05 https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=59&quickFilter=125 08:22:09 this is a view of the current sprint 08:22:26 so, it would be nice that ever one fixes the sprint in your current tasks 08:22:30 to have a nice view here :) 08:22:46 morgan_orange: yes, we can start with vping/tempest/rally 08:22:55 I can volunteer for tempest 08:22:55 it's awesome to have kanban, hooray 08:22:58 for https://jira.opnfv.org/browse/FUNCTEST-336, it will be the core of the internship 08:23:00 juhak: would be you ok with rally? 08:23:05 adding unit tests in functest utils... 08:23:09 I will work on vping soom 08:23:22 I suppose i could take doctor, promise and domino 08:23:35 and parser 08:23:50 I can work on whatever left 08:23:57 jose_lausuch: yes, sure 08:24:21 #info SerenaFeng will work on vping adaptation https://jira.opnfv.org/browse/FUNCTEST-540 08:24:41 #info juhak will work on rally adaptation https://jira.opnfv.org/browse/FUNCTEST-543 08:25:00 #info jose_lausuch will work on tempest adaptation https://jira.opnfv.org/browse/FUNCTEST-542 08:25:02 BTW (other topic) on Colorado, all the CI runs are failing due to Rally ... 08:25:26 #info morgan_orange will work on doctor/copper/domino/copper 08:25:48 morgan_orange: right, but at least we don't have problems with the functest env prepare 08:25:49 https://build.opnfv.org/ci/view/functest/job/functest-fuel-baremetal-daily-colorado/580/console 08:25:52 morgan_orange: didn't know that, I'll take a look 08:26:18 juhak: it seems an error with some code: File "/home/opnfv/repos/functest/testcases/OpenStack/rally/run_rally-cert.py", line 243, in get_output duration = line.split(': ')[1] 08:26:26 but apparently it happens only in stable branch! 08:26:29 that's weird 08:26:30 juhak: probably a config issue, issue introduced yesterday and similar whatever installer/scenario 08:26:42 but right only on stable 08:26:49 we should test line.split(': ') before [1] 08:27:10 #action juhak troobleshoot new errors on rally launch on stable branch 08:27:16 #action look at the existing error in Rally test for Colorado jobs 08:27:19 morgan, if you ok, i try doctor. 08:27:19 #undo 08:27:19 Removing item from minutes: 08:27:20 :) 08:27:38 hideyasu: that would be great, morgan_orange do you agree? 08:27:41 and space should be remove ! 08:27:42 sure 08:27:53 ok , 08:28:07 #info hideyasu will work on doctor adaptation 08:28:22 #info morgan will work on promise/domino/copper 08:28:50 #info SerenaFeng will work on Parser adaptation 08:28:55 BTW hideyasu we will have to work on the abstraction for vnf onboarding, we probably need to do it together - probably in next Sprint 08:29:07 I assigned those tasks to you 08:29:09 with integration of your vrouter suite + OAI 08:29:30 SerenaFeng: I need to create a task for parser 08:29:53 jose_lausuch: if you agree I closed https://jira.opnfv.org/browse/FUNCTEST-336 and the internship will create new tasks related to the unit test Epic 08:30:03 I close... not closed yet 08:30:05 I can create it after the meeting 08:30:08 SerenaFeng: done https://jira.opnfv.org/browse/FUNCTEST-565 08:30:13 ok 08:30:17 ok, you ar so fast 08:30:20 morgan_orange: sounds good 08:30:38 SerenaFeng: I trained a lot with my left hand, so I am like 2 persons in 1 now :p 08:31:04 jose_lausuch: you are a talent for multi-tasking 08:31:09 morgan_orange: maybe we can move the tasks to the other epic about unit tests 08:31:11 Superman 08:31:34 HelenYao: well, that doesn't work so good, doing 2 things at the same time is tough... only women can do that! 08:31:35 :D 08:31:53 ok, moving on 08:31:54 #topic OpenStack client versions follow up 08:31:58 interesting thoery 08:32:17 #info this wiki created to keep track of the discussion: https://wiki.opnfv.org/display/functest/OpenStack+python+clients 08:32:22 #info there is a table that shows the client versions according to the openstack release versions. 08:32:53 it's great to have the clear picture 08:33:00 #info created this patch to uplift the client versions corresponding to newton https://gerrit.opnfv.org/gerrit/#/c/24237/ 08:33:26 I took a while to complete the table looking at the release notes, but this way it is much clearer to me what versions we should use 08:33:27 however 08:33:33 when we install our requirements.pip 08:33:47 they are overwritten by other commands after that one 08:33:51 for example, rally 08:33:57 snaps 08:34:08 but snaps is using Newton clients, so it should be fine 08:34:13 what's our plan for Newton support? is upgrading client enough for it or we will have further plan? I sent a mail about the proposal 08:34:32 and most of the requirements don't use exact versions, they use '<=' '>=' instead 08:34:45 HelenYao: no, I think we need to touch the code as well 08:34:51 i am running virtualenv and this problem will be resolved 08:34:54 HelenYao: yes, I neeed to read it 08:35:18 #info the requirements dependencies can be resolved in some cases with virtual envs, like the rally case 08:35:31 i tested in vitualenv and all requirements even the toughest kingbird does not cause chaos 08:35:39 #info HelenYao working on venv 08:35:50 that sounds good 08:35:57 I think it's our way forward for now 08:36:23 there is another discussion ongoing in the community for Danube: should we release OpenStack Ocata or Pike ? 08:36:31 I will have to vote for Functest 08:36:36 I need your opinion :) 08:36:39 even Pike? 08:37:01 sorry no 08:37:04 Newton or Ocata 08:37:17 the question is: shall we support Newton or Ocata? Or both ? 08:37:33 do we have enough resource to take the rush? 08:37:45 #info discussion in the community about Danube OpenStack release to support: Newton vs Ocata or both 08:37:45 is it a question for Functest? All the test projects will have the same questions... 08:37:57 no, it's a question for al the ptl's ... 08:37:58 supporting two version sounds aggressive 08:38:16 do you know guys how stable Ocata is nowadays? 08:38:31 I would vote Newton only, but I',m not sure 08:38:44 David is asking the same question... 08:38:45 i think Newton is not stable enough, not to mention Ocata 08:38:59 hujie: yes, that question comes directly from David :) 08:39:12 probably in March Newton will be stable enough 08:39:19 shall I vote for Newton only? 08:39:28 it's what I had in mind ... 08:39:36 +1 08:39:36 ollivier: ? 08:39:43 I would vote for Newton only +1 08:39:47 ok 08:39:50 SerenaFeng: ? 08:39:53 juhak: ? 08:39:57 Newton +1 08:40:02 N +1 08:40:05 newton +1 08:40:08 ok 08:40:10 thanks guys :) 08:40:36 #Agreed Functest will support only Newton in Danube 08:40:49 #info Functest will vote for OpenStack Newton only support for Danube release 08:41:01 Ocata is not released yet, it's very risky to support it as the schedule would be very tight 08:41:07 morgan_orange: you are always faster :) 08:41:24 releasing with Ocata would mean moving the milestones 08:41:47 this is the message from David: 08:41:47 OpenStack Ocata releases approximately one month before the planned release of OPNFV Danube.  In order to integrate Ocata with Danube, we would need to slip the scheduled release date for Danube at least one month.  Alternatively, we could release OPNFV Danube, per the existing schedule, using OpenStack Newton, then skip Ocata altogether.  For the OPNFV E-release, we would plan to intersect the OpenStack Pike release.  Another thing to consi 08:41:49 it will impact all opnfv projects 08:42:05 ok 08:42:13 anything else do we need to do for this topic? 08:42:18 we have APs 08:42:21 and work to do 08:42:26 let's see if we fix that soon 08:42:33 and combine it with the docker slicing if it makes sense... 08:42:49 moving to the next topic 08:42:55 #info Answer to bitergia 08:43:07 morgan_orange: do you wan to drive this topic? 08:43:33 #info after meeting in Barcelona, Jesus sent us some proposals 08:43:33 hujie: we will talk about escalator after this 08:43:48 no problem 08:43:51 #topic Answer to bitergia 08:44:02 #info it is up to us to say what we do and do not do 08:44:20 can you summarize in 1 sentence the 2 proposals? 08:44:57 1) let me copy them from the email 08:45:04 #info bitergia can just work from the Test API (do everything) / let us do the Elasticsearch consolidation / let us do the kibana definition 08:45:09 ok, sorry 08:45:22 SerenaFeng: has the best view on this 08:45:35 jose_lausuch: hard to vote. We could switch at least to the OpenStack current stable. 08:45:41 We can start by putting the results Dashboard on bitergia as Jesus suggested 08:45:48 regarding our load, I would suggest to ask them to consume the API 08:46:28 Whatever we choose, what bitergia is doing is always open source 08:46:37 so we will not lose the controls of the dashboard 08:46:37 will cost be a consideration point :-) 08:46:41 yes 08:46:51 bitergia has already a contrcat with linux Foundation 08:47:01 so these aspects have also to be taken into account 08:47:19 do we have to consider that outselves? 08:47:20 the more they work, the more we have to pay 08:47:41 do we have to justify our decission? 08:47:58 the most important thing is, how much control we want for the issue 08:47:59 HelenYao: sure but they are very skilled and if they take 1h when we need 1 day...assuming that there is already a contract... 08:48:16 I think we hshould first focuse on what we want technically and ask Ray if he approves it 08:48:41 and what do we want technically? :) 08:49:01 yeah, from technical point of view 08:49:32 in my opinion we already make the decision during the summit that we let Bitergia do all the work 08:49:58 and we make the requirements 08:50:07 is it not the case? 08:50:07 not all the work...we do the API that they consume + the requirements 08:50:24 the api is our task and responsability, right? 08:50:30 we should maintain it 08:50:35 yes 08:50:42 by handing over all stuff to bitergia, the communication effort will rise enormously if we want to update the data. my cents are, we can keep control of the data and let them work on visualization as they are the experts 08:50:44 yes, testspi is our responsibility 08:50:58 as to the visualization, they take almost all the work 08:51:03 so we should answer to jesus mail and indicate that our option is that they start consuming the API to display the results 08:51:28 yes, I think Jesus's opinion make sense 08:51:31 #info answer to bitergia: our option is that they start consuming the API to display the results 08:51:51 #info we keep responsability and maintain the API 08:51:54 we can start with implementing dashboards similar in functionality to the current ones 08:52:08 yes 08:52:11 ok 08:52:14 they can start with implementing dashboards similar in functionality to the current ones 08:52:14 [16:52:20] yes 08:52:21 morgan_orange: can I action you on the answer? 08:52:29 sorry wrong type 08:52:36 or SerenaFeng? 08:52:37 #action morgan_orange answer bitergia 08:52:44 ok thanks 08:52:54 let's move to the last topic before we finish 08:53:02 #topic Escalator testcases integration 08:53:03 thanks 08:53:11 #info Escalator team wants to participate the Danube release and provide son functional tests 08:53:17 #info They want support upgrading all OPNFV environments deployed by various Installers 08:53:21 #info To avoid re-inventing wheels, Escalator try to reuse the function of the installer. 08:53:28 #info The very first steps are reusing Daisy4NFV installer for experimental 08:53:37 hujie: please share the info you want 08:53:45 so that we have an undestanding of what you need 08:53:53 Hi Functesters! 08:54:14 hey 08:54:27 We have shared this idea in https://wiki.opnfv.org/download/attachments/5046455/Escalator%20Refreshing%20your%20OPNFV%20environment%20with%20less%20troubles%20v4.pptx?version=1&modificationDate=1466671406000&api=v2 08:54:46 #info liknk https://wiki.opnfv.org/download/attachments/5046455/Escalator%20Refreshing%20your%20OPNFV%20environment%20with%20less%20troubles%20v4.pptx?version=1&modificationDate=1466671406000&api=v2 08:54:52 #undo 08:54:52 Removing item from minutes: 08:54:55 #link https://wiki.opnfv.org/download/attachments/5046455/Escalator%20Refreshing%20your%20OPNFV%20environment%20with%20less%20troubles%20v4.pptx?version=1&modificationDate=1466671406000&api=v2 08:55:27 hujie: what kind of testing would you need? 08:55:36 an upgrade is not the usual thing we do :) 08:55:37 Escalator will use the deploy function to replace the version files on nodes. 08:56:40 To aviod service outage, Escalator will try to communicate with VIM to move VMs from the nodes. 08:57:21 so, it's a test case about VM migration? 08:57:45 Yes 08:58:07 hujie: is there a specific scenario about it? 08:58:13 1.Installing OpenStack via Daisy4NFV on scenarios "os-nosdn-nofeature-ha" 08:58:13 2.Query the version information of target nodes and VMs running on them 08:58:13 3.Live-migrating VMs from target compute nodes to spare nodes 08:58:38 is Daisy a new installer different from Fuel/Apex/Compass/Joid ? 08:58:56 ok my undestanding is that 1,5: run Functest on fresh install + test case that will be helpful to check that we kept probablyt the data 08:59:07 hujie: normally the deployments have 3 controllers and 2 computes. Are 2 computes ok for your tests? 08:59:14 3.5 re run functest, check it is still OK and see if data are still there 08:59:26 Escalator will submit the description of the testcase to Functest before next Monday 08:59:46 #info 1.Installing OpenStack via Daisy4NFV on scenarios "os-nosdn-nofeature-ha" 08:59:52 #info 2.Query the version information of target nodes and VMs running on them 09:00:02 #info 3.Live-migrating VMs from target compute nodes to spare nodes 09:00:17 #info Escalator will submit the description of the testcase to Functest before next Monday 09:00:22 I think 2 computer nodes can be HA. 09:00:45 hujie: the HA deployments in CI are with 2 computes 09:01:01 jose_lausuch Daisy is a new installer 09:01:08 SerenaFeng: ok, thanks 09:01:22 It is OK, we will find a solution in this configuration. 09:01:28 ok, we will wait for the proposal and provide comments to the team 09:01:31 fro Openstack which upgrade will it manage? from Newton to ocata?... 09:01:32 thanks 09:01:38 if so we do not support Ocata client :) 09:01:49 it should be backwards compatible ... 09:01:52 Newton, I think. 09:01:54 but you are right 09:02:01 so Liberty to Newton? 09:02:10 oops 09:02:12 Mitaka to Newton 09:02:37 yep even if skipping one version was also a pain points reported by the EUAG 09:03:06 We plan to support OpenStack upgrade, and others as well. 09:03:08 a side question, what is EUAG 09:03:09 so Functest will be used to test before and after migration + a new test case specific to escalator to garantee the persistance of data? 09:03:19 HelenYao: End User Advisory group 09:03:27 morgan_orange: thx 09:03:36 that changes the way we execute things 09:03:39 HelenYao: https://www.opnfv.org/about/opnfv-end-user-advisory-group 09:03:44 nice picture Morgan 09:04:18 Do you guys have more questions on Escalator? 09:04:18 I have to drop 09:04:24 time is over 09:04:26 thank you all 09:04:33 Thanks.... 09:04:35 hujie: no, we will follow up by email when you have the proposal to us 09:04:45 OK. 09:04:45 #endmeeting