08:01:25 <jose_lausuch> #startmeeting Functest weekly meeting May 2nd 2017
08:01:25 <collabot> Meeting started Tue May  2 08:01:25 2017 UTC.  The chair is jose_lausuch. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:25 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:01:25 <collabot> The meeting name has been set to 'functest_weekly_meeting_may_2nd_2017'
08:01:28 <jose_lausuch> #topic role call
08:01:31 <jose_lausuch> #info Jose Lausuch
08:01:49 <jose_lausuch> #info agenda for today: https://wiki.opnfv.org/display/functest/Functest+Meeting#FunctestMeeting-02/05(8UTC)
08:03:29 <jose_lausuch> morgan_orange: HelenYao juhak
08:04:10 <juhak> #info Juha Kosonen
08:04:20 <boucherv> #info Valentin Boucher
08:04:38 <morgan_orange> #info Morgan Richomme
08:04:40 <HelenYao> #info Helen Yao
08:05:01 <jose_lausuch> hello all :)
08:05:16 <morgan_orange> hello
08:05:29 <jose_lausuch> #topic Hackfest recap
08:06:04 <jose_lausuch> #info The hackfest/plugfest was full of interesting sessions with regards to Testing and CI
08:06:09 <jose_lausuch> #chair morgan_orange
08:06:09 <collabot> Current chairs: jose_lausuch morgan_orange
08:06:12 <jose_lausuch> feel free to comment
08:06:18 <jose_lausuch> we can do a round
08:06:30 <jose_lausuch> juhak: could you do your highlights?
08:06:36 <jose_lausuch> for testing on hardware?
08:07:43 <juhak> we had a good progress in integrating Netronome smartNICs,
08:07:47 <LindaWang> #info Linda Wang
08:08:05 <jose_lausuch> feel free to use #info
08:08:11 <jose_lausuch> #info good progress in integrating Netronome smartNICs,
08:08:11 <morgan_orange> #info on orange side introduction to a new test case based on Power consumption monitoring (linked to CI)
08:08:23 <MatthewLi> #info Jun Li
08:08:29 <morgan_orange> #info good week on load test on vIMS using a commercial loader
08:08:36 <juhak> and find a bug in apex related to DPDK deployment (with the help of Tim Rozet)
08:09:00 <morgan_orange> all the plugfest results are under NDA for 90 days as far as I know... :)
08:09:05 <David_Orange> #info David Blaisonneau
08:09:30 <jose_lausuch> yes
08:09:39 <jose_lausuch> we can't paste the link to the results
08:09:54 <morgan_orange> #info some bugs reported to functest
08:10:26 <jose_lausuch> #info different hardware vendors running Functest
08:10:43 <morgan_orange> #info presentation of Functest to Deutsch Telekom
08:10:45 <jose_lausuch> #info some results reported to the local DB
08:10:49 <jose_lausuch> thanks for that Morgan ;)
08:11:22 <morgan_orange> #info good discussion on Euphrates to build functest roadmap
08:11:34 <morgan_orange> #info discussion on kubernetes support
08:11:38 <jose_lausuch> I will paste the link later
08:12:00 <jose_lausuch> #info Functest will add some tests (similar to vPing) for K8 scenarios (pure containers)
08:12:02 <morgan_orange> #info discussions with sample VNFs
08:12:14 <morgan_orange> #info demo of Kumar's VNF catalogue
08:12:51 <morgan_orange> #info sync with other test project on collaborative work (catalogue, landing page, micro service approach for Euphrates, POD needs)
08:13:27 <morgan_orange> jose_lausuch: did you also follow the mmeting with dovetail? any update?
08:14:17 <jose_lausuch> morgan_orange: will do an update soon, but not today as I don't have the full picture yet
08:14:54 <morgan_orange> juhak: did you run Functest on Nokia OCP (did not see any results in the local DB)
08:15:40 <morgan_orange> #info sync with armband for fuel@aarch64 reporting (separated from fuel@x86)
08:15:41 <juhak> morgan_orange: sorry, no
08:16:21 <juhak> morgan_orange: only dovetail but the results are not in db
08:17:07 <morgan_orange> ok
08:17:12 <jose_lausuch> no problem
08:17:39 <jose_lausuch> #info Functest Euphrates release plan presented
08:17:48 <jose_lausuch> and modified
08:18:08 <jose_lausuch> #link https://wiki.opnfv.org/display/functest/Functest+Euphrates+page
08:18:59 <jose_lausuch> HelenYao: are you there?
08:19:06 <HelenYao> jose_lausuch: yes
08:19:26 <jose_lausuch> we were discussing about docker slicing
08:19:43 <jose_lausuch> the team doesn't think it's one of the priorities for now
08:19:57 <jose_lausuch> but the Functest API is one of the definitive things we need to have for E-release
08:20:20 <HelenYao> sounds reasonable
08:20:31 <HelenYao> I vote for Functest API as well
08:20:36 <jose_lausuch> the first priority is the framework
08:20:42 <jose_lausuch> we need to have it ready by June
08:20:47 <HelenYao> it will make Functest much easier to be used
08:20:55 <morgan_orange> one of the statement was: slicing could be possible once we would have clarify all our dependencies and impose to the other projects our openstack client version
08:21:13 <jose_lausuch> all the modifications and upgrades to the framework must be done in 1.5 months, which is feasible I think (we started working on it already)
08:21:54 <HelenYao> do we settle the tech detail for the rest api? e.g. what is chosen as web server
08:22:27 <HelenYao> I am glad to be part of functest api
08:22:35 <morgan_orange> I think it would make sense to be aligned with yardstick...
08:22:42 <jose_lausuch> yes, sure
08:22:50 <jose_lausuch> we should have similar apis for all the projects
08:22:52 <HelenYao> yeah, yardstick is a good reference
08:23:00 <jose_lausuch> similar schemas/calls
08:23:10 <HelenYao> it makes sense
08:23:23 <jose_lausuch> great
08:23:23 <morgan_orange> they adopt our "yardstick prepare env" in Danube, we can adopt the APi way.. :)
08:23:42 <jose_lausuch> yep
08:23:44 <HelenYao> It's easy for me to reach Jack Chan for the Yardstick API design and implementation
08:23:51 <jose_lausuch> a short topic into this direction
08:24:15 <jose_lausuch> #topic MS1 status
08:24:15 <morgan_orange> #info Functest internal API => reco align with Yardstick
08:24:30 <morgan_orange> #action HelenYao sync with jack Chan for internal API
08:24:43 <jose_lausuch> oops sorry :)
08:25:08 <jose_lausuch> #info Functest MS1: Release plan: https://wiki.opnfv.org/display/SWREL/Summary+of+Release+Plans+for+Euphrates
08:25:28 <jose_lausuch> #info we base the plans on that Wiki and Power point. Jira tickets to be create
08:26:02 <morgan_orange> Shall we include test case / scenario promotion mechanism?
08:26:13 <jose_lausuch> morgan_orange: you mean in the release?
08:26:16 <jose_lausuch> I assumed so
08:26:22 <jose_lausuch> I hope we have the time to work on that
08:26:34 <jose_lausuch> #topic Assignments
08:26:45 <jose_lausuch> do you want to lead that topic?
08:26:51 <jose_lausuch> as you created the algorithm? :)
08:27:11 <morgan_orange> yes I can, there are some dependencies with the scenario object in the test API
08:27:43 <jose_lausuch> #info morgan_orange to lead test case / scenario promotion mechanism
08:28:36 <jose_lausuch> we should also focus efforts on SNAP-arize the code
08:28:39 <jose_lausuch> the test cases
08:28:46 <jose_lausuch> we can distribute the test cases
08:28:53 <jose_lausuch> vping is done by Steve
08:29:04 <jose_lausuch> juhak: would you be happy with tempest/rally?
08:29:16 <morgan_orange> the goal is to get rid off our utils and use SNAPS ones, rught?
08:29:17 <juhak> yes
08:29:21 <jose_lausuch> morgan_orange: yes
08:29:40 <jose_lausuch> #info vPing already started https://gerrit.opnfv.org/gerrit/#/c/25357/
08:30:07 <jose_lausuch> #info Juha: Tempest/Rally with SNAPS
08:30:22 <jose_lausuch> who else?
08:30:43 <David_Orange> I will push a new test case
08:31:06 <jose_lausuch> David_Orange: about ?
08:31:18 <David_Orange> for testing api availability from tenant, to test it before deploying orchestrator
08:32:07 <jose_lausuch> David_Orange: ok, I will create a jira and you can add a description there ok?
08:32:15 <jose_lausuch> #info David_Orange new test: api availability from tenant, to test it before deploying orchestrator
08:32:23 <David_Orange> i will do it using snaps, do you prefer a new patch or i push in 25357 ? Jira-> Sure
08:32:24 <morgan_orange> shall it be a new case in healtcheck test_api or included in snaps_smoke?
08:32:31 <LindaWang> I'd like to work on rally and tempest on SNAP-arize.
08:32:36 <jose_lausuch> I will take SFC and BGPVPN which also use openstack_utils
08:33:05 <jose_lausuch> LindaWang: you can help juhak, but there are also other test cases :)
08:33:23 <LindaWang> Sorry Juha has taken it.
08:33:39 <morgan_orange> some work probably needed for all the VNF related cases (using our utils)
08:33:58 <jose_lausuch> what about onos test cases?
08:34:05 <LindaWang> Sure.
08:34:14 <jose_lausuch> boucherv: how long will you be in
08:34:15 <LindaWang> I will try onos.
08:34:15 <jose_lausuch> ?
08:34:21 <jose_lausuch> LindaWang:  ok
08:34:30 <jose_lausuch> #info LindaWang for ONOS test cases with SNAPS
08:34:36 <morgan_orange> did we not says that we will remove onos_sfc? no scenario supported anymore and pylint score very low compared to all the other feature projects?
08:34:44 <OPNFV-Gerrit-Bot> Helen Yao proposed functest: Fix Opera ims  https://gerrit.opnfv.org/gerrit/34041
08:35:05 <jose_lausuch> morgan_orange: yes, but we still have the basic onos test
08:35:17 <boucherv> jose_lausuch: Until september
08:35:28 <jose_lausuch> boucherv: would you like to work on vIMS SNAPs?
08:35:57 <boucherv> jose_lausuch: to remove the openstack_utils on vims ?
08:36:06 <morgan_orange> jose_lausuch: ok so we can clear onos_sfc...if LindaWang is dealing with onos, maybe she can also clean onos_sfc
08:36:17 <jose_lausuch> boucherv: yes
08:36:31 <OPNFV-Gerrit-Bot> Helen Yao proposed functest: Pack image for bgpvpn testcase to docker container  https://gerrit.opnfv.org/gerrit/34033
08:36:57 <boucherv> jose_lausuch: I can do that
08:37:09 <jose_lausuch> boucherv: great
08:37:23 <jose_lausuch> #info Valentin boucherv for vIMS - SNAPs
08:37:56 <morgan_orange> I know that people from Okinawa labs planned to refactor vyatta vrouter to use vnf onboarding, we shall also ask them to use SNAPS lib
08:37:57 <jose_lausuch> #info jose_lausuch focus on SFC and BGPVPN with SNAPs
08:38:02 <jose_lausuch> yes
08:38:28 <morgan_orange> I can see with orchestra and HelenYao probably with opera
08:38:42 <HelenYao> sure
08:39:12 <boucherv> If vPing implement snap I think is simple to change in our code after that (I hope)
08:39:26 <jose_lausuch> yes, it's about changing the calls
08:39:41 <jose_lausuch> and after that, we won't need openstack_snapshot/openstack_clean
08:41:02 <jose_lausuch> ok
08:41:09 <jose_lausuch> #topic Functest without admin network
08:41:19 <jose_lausuch> LindaWang: you found out something very interesting
08:41:27 <jose_lausuch> I tried your 2 patches in real deployments last week
08:41:33 <jose_lausuch> and they worked without admin network
08:41:45 <jose_lausuch> I tried on our functest server
08:41:52 <jose_lausuch> and also in Doctor guys deployment
08:42:25 <LindaWang> I am working on tempest on external server now.  It is already done. And next is to try snaps testcases.
08:42:53 <jose_lausuch> we should merge those 2 patches and adapt RC files to use public API
08:42:56 <jose_lausuch> for example, in fuel
08:43:05 <jose_lausuch> we need to swtich from internalURL to publicURL
08:43:08 <jose_lausuch> in the RC file
08:43:14 <jose_lausuch> and then it works
08:43:28 <LindaWang> There is one issue here. Ir works for newton, but not for mitaka.
08:43:46 <jose_lausuch> yes, I tried in Windriver deployment which was Mitaka, and Rally gave a problem...
08:44:01 <jose_lausuch> but Functest-Euphrates is targeting Ocata anyway
08:44:11 <jose_lausuch> for Mitaka, we should mandate the access to admin endpoint...
08:44:23 <LindaWang> OK.
08:44:56 <jose_lausuch> good work LindaWang
08:45:14 <LindaWang> jose_lausuch: My pleasure.
08:45:19 <morgan_orange> +1 was a thorn in the foot for a long time...
08:45:44 <jose_lausuch> yes
08:45:57 <jose_lausuch> this will remove some questions from end users
08:46:02 <jose_lausuch> and we will have to update the docs
08:46:14 <morgan_orange> it will simplify the docs..
08:46:20 <jose_lausuch> yep
08:46:36 <jose_lausuch> #topic AoB
08:46:44 <jose_lausuch> anything from anyone?
08:46:47 <MatthewLi> yep
08:47:04 <morgan_orange> yes
08:47:21 <morgan_orange> what about Dnaube 2.0, we merge all the master to Danube...
08:47:30 <jose_lausuch> mmm
08:47:31 <MatthewLi> the dovetail related patches not chery pick to danube, only in master, this will have problem
08:47:32 <morgan_orange> big change but I do not see another option...
08:47:35 <jose_lausuch> wait
08:47:42 <jose_lausuch> morgan_orange: I wouldn' do so
08:48:04 <jose_lausuch> MatthewLi: we can identify which patches are needed for Danube
08:48:05 <morgan_orange> so danube 1.0 = danube 2.0?
08:48:11 <jose_lausuch> I wouldn't cherry pick all
08:48:16 <jose_lausuch> master is working on Euphrates
08:48:35 <jose_lausuch> we started Euphrates development that is not targeted for Danube....
08:48:47 <jose_lausuch> we should cherry pick only bug fixes
08:48:58 <MatthewLi> jose_lausuch: yep .however, this will be a touch progress, since some conflict with olliver 's patch
08:49:16 <morgan_orange> agree, but cherry picking will be very hard => fix/patch directly on Danube then
08:49:34 <MatthewLi> tough I mean...
08:49:35 <jose_lausuch> MatthewLi: can you please point to the patches that you need?
08:50:13 <jose_lausuch> how many of them? how much code?
08:50:26 <MatthewLi> jose_lausuch: yep. however, should cherry pick olliver's patch at the same time and will not predict what will happen
08:50:37 <jose_lausuch> what olliver's patch? there are many :)
08:51:30 <MatthewLi> yep will do some research later
08:51:38 <morgan_orange> #info do not forget to vote for the awards...
08:51:45 <jose_lausuch> MatthewLi: please do, and we can evaluate
08:51:46 <morgan_orange> #action https://www.surveymonkey.com/r/7ZNPMMR
08:52:28 <jose_lausuch> stable branch danube2.0 is to be created on thursday
08:52:35 <jose_lausuch> please let's be quick here
08:52:57 <morgan_orange> regarding danube/euphrates => I modified quickly the reporting page to consider Danube testcases.yaml because otherwise there was a bug due to the format changes :)
08:53:10 <jose_lausuch> ah ok
08:53:12 <jose_lausuch> thanks
08:53:44 <morgan_orange> so to be clear if a bug is detected on Danube: 1) try to fix in master (if it makes sense) 2) if not patch directly danube (because too much divergence)
08:53:49 <morgan_orange> is it correct?
08:54:58 <jose_lausuch> yes
08:55:02 <jose_lausuch> if we see there is too much difference
08:55:16 <jose_lausuch> I prefer to put the change in stable branch directly than cherry picking everything...
08:55:23 <morgan_orange> for examples testcases.yaml today is too different...
08:55:40 <morgan_orange> but ok for me
08:55:51 <jose_lausuch> yes, but if we cherry pick everything, the documentation is also outdated
08:55:55 <morgan_orange> then we should re insist on infra group to be able to have CI on master and Danube
08:55:55 <jose_lausuch> we are not consistent then...
08:55:57 <jose_lausuch> too many changes
08:56:19 <jose_lausuch> I think they have had some discussions on that in the hackfest..
08:56:36 <morgan_orange> Ci on master shows that it is OK, that is why we could have moved all euphrates into Danube (but many differences especially in framework)
08:56:40 <jose_lausuch> but changing everything is also too dangerous
08:57:24 <morgan_orange> HelenYao: for Danube 2.0 we will add the opera case, right?
08:57:39 <HelenYao> I think so
08:57:54 <HelenYao> opera project is expecting the functest opera case
08:57:56 <morgan_orange> are there other changes compared to Danube 1.0?
08:58:21 <HelenYao> there is a bug after the recent framework refactor
08:58:21 <morgan_orange> HelenYao: you can run weekly jobs on compass?
08:58:27 <HelenYao> I submited the patch
08:59:07 <HelenYao> a daily job of opera will be trigger the functest opera case
08:59:47 <jose_lausuch> ok
08:59:47 <morgan_orange> you mean you put opera in daily or you created a specific jobs for opera?
09:00:45 <HelenYao> opera team created the daily job and I supported them to run functest opera case
09:01:39 <morgan_orange> OK we will probably have to think how to manage such cases to give them some CI chance. Can be do through promotion, specific jobs,
09:01:54 <HelenYao> the job will deploy compass env -> deploy open-o -> call functest opera to verify -> submit the result
09:01:57 <morgan_orange> orchestra do not have its own CI resources
09:02:00 <jose_lausuch> I need to leave
09:02:05 <jose_lausuch> let's end the meeting
09:02:09 <jose_lausuch> thanks everyone
09:02:13 <jose_lausuch> #endmeeting