Morgan, See in-line.
Chris From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Friday, August 24, 2018 at 8:12 AM To: Yunxia Chen <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Chris Donley <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Gary Wu <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Yang Xu (Yang, Fixed Network)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: DEBEAU Eric IMT/OLN <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [ONAP] E2E VNF functional testing Hi Chris thanks for the reply comments, answers and questions in the mail /Morgan Le jeudi 23 août 2018 à 20:46 +0000, Christopher Donley (Chris) a écrit : Most of your wishlist items are in the VNFSDK roadmap. ok does it mean that - Testsuite deals with tests of ONAP (which may include canonical VMs) as a solution - VNFSDK deals with ONAP compatible VNF tests. yes VNFSDK name was a bit misleading for me as the goal is not to provide a toolkit to develop but to validate and integrate in CI/CD chains. It's a long story dating back to its origination in Open-O… However the description of the project is clear :)"build an ecosystem for ONAP compatible VNFs by developing tools for vendor CI/CD toolchains and developing validation and testing tools" Does it mean that you plan to develop VNF, leverage OPNFV VNF project, develop tests in addition of testing tools? We're not developing the VNFs, but we are developing packaging tools in addition to the tests. We haven't been working with OPNFV VNFs. #3 on your list is already part of VNFSDK (dovetail-integration repo). ok I had a quick loop, it looks like python + yaml templating but covers the same areas than robot + python extention script from testsuite it is already dockerized an inherited stuff from dovetail I need to test it :) Regarding #2, we have been focusing on packaging tests, but recently updated the functional tests (functest repo) in Beijing. Lifecycle tests have been dormant since OPEN-O, but we can resurrect as soon as we have resources. One prerequisite is a small test version of ONAP (ONAP-lite?). Ideally, we should be able to quickly instantiate it in a cloud environment, run our tests, and tear it down. We should talk about your Python framework. regarding packaging, I created a docker integrating the demo and the vvp/validation repos within a xtesting docker this 45 Mo docker (https://hub.docker.com/r/morganrol/xtesting-onap-vnfpkgcheck/) checks the different heat template available in the demo repos (traces attached) VNFSDK has been focusing on TOSCA. We should discuss whether it makes sense to incorporate these for HEAT – we're currently using VVP tests. regarding the Python Framework Our first idea was to create python client for the components (like in Openstack); we used theses components to onboard then instantiate some simple opensource VNFs Our goal was to include daily instantiation of simple VNFs (vIMS, vAAA - much simpler than the demo VNF including proprietary VNFs but integrable into CI/CD chains (open source VNFs)) We can sync during a VNFSDK / Integration / ad-hoc meeting if you want Sounds good We're cleaning up our test engine this release to make it easier to run Java, Python, or shell tests. xtesting includes natively the possibility to run bash, python, junit or robot tests. it also runs VNFs through a python vnf abstraction developed in OPNFV and used with open-o, cloudify, juju, openbaton, heat (currently heat/cloudify+clearwater IMS, cloudify+vyos vrouter and juju+vEPC previously we had also open-o/openbaton + clearwater IMS and openbaton = openIMS) Prior to now, we had a number of test engines coming in from different sources, using different languages. I expect by the end of Casablanca to have a stable test framework so we can focus more on the tests in Dublin. I would say that Robotframework is a very stable test framework :) We're already using Robot as part of the function test repo ;-). The python frameworks are also probably stable... Yes, we're using Tox… From Amsterdam to Beijing, the only unstability I can see is due to API & data model changes in the components Somehow the diversity of the test frameworks reflects the stability of the SUT and the community testing vitality. The issue we're facing is the challenge of test development…We're trying to refactor to simplify test creation. It is not surprising to see several initiatives. It is a richness for a community and it becomes a real added value when synergies occur. I will be at ONS, and happy to meet while we're there. Let's plan a slot to discuss these different aspects. great Chris From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, August 23, 2018 at 5:33 AM To: Yunxia Chen <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Chris Donley <[email protected]<mailto:[email protected]>>, Gary Wu <[email protected]<mailto:[email protected]>>, "Yang Xu (Yang, Fixed Network)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: DEBEAU Eric IMT/OLN <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [ONAP] E2E VNF functional testing Hi, a topic was dedicated to vCPE automation during Integration meeting today. I think that E2E VNF testing automation is key to stabilize ONAP For me automation means the ability to - check packaging - onboard the model - instantiate the VNF - check that resources are propely created on the target infrastructure - perform functional tests (e.g. SIP tests on a vIMS VNF) - clean the resources - report the results Automation shall be replicable on any ONAP platform without big effort except configuration file changes It means decoupling use cases/ONAP installation (no hardcoded values in ONAP installation, no lab manual specific configuration) Proprietary VNFs due to licensing models are very hard to integrate in CI/CD chains (which shall not prevent ambitious use cases to integrate such VNFs) It is clearly challenging As far as I know there are currently several initiatives aiming to provide ONAP VNF E2E automatic testing 1) integration project with the different cases including vCPE (integration team) https://git.onap.org/testsuite/tree/robot https://git.onap.org/demo/tree/ https://git.onap.org/integration/tree/test Using Robot you can already onboard and instantiate several VNFs (vLB, vFW, vVG, vCPE): https://git.onap.org/testsuite/tree/robot/testsuites/model-distribution.robot Some tests were integrated in CI and even use for some robustnes tests (I did not find the jenkins url corresponding to daily runs of there testcases) 2) VNFSDK/VPP as part of VNF certification program (contact C.Donley) information shared during LFN C&C meeting - the idea is to work on a verification program for VNF as the one initiated on the infrastructure by OPNFV VNFs have been announced for September only packaging check are planned for Casablanca as a first step but onboarding/lifecycle tests/functional tests are mentioned in the roadmap dovetail framework is mentioned as the tooling to launch the tests 3) Amdocs demo shared during last ONS summit (contact: Moshe Hoadley) It is also linked to 2) as a poc of ONAP Life cycle testing through dovetail https://wiki.onap.org/display/DW/VNFTEST+integration+with+DOVETAIL?preview=/28377754/28377756/onap-opnfv-collaboration-demo-21_march_2018.mp4 I did not find de code associated to the demo 4) OTF - Open Test Framework (contact: Kevin Wan) https://wiki.onap.org/display/DW/OTF+-+Open+Test+Framework project in progress / still no official repo 5) Light python framework shared during last ONS (contact: Morgan Richomme) This is a python framework allowing to onboard and instantiate VNFs. It can be used with Clearwater vIMS, vMRF (proprietary), vAAA (freeradius), ONAP vFW The code is available here: https://gitlab.com/Orange-OpenSource/onap-tests The plan is to integrate it in xtesting project (as robot healthcheck tests have been integrated) xtesting (https://xtesting.readthedocs.io/en/latest/) is a light framework to harmonize the way of launching the tests (launch, get results, report results), supporting Robot, python, bash, junit based tests. it is used in OPNFV and easy to integrate in CI chains (we use it internally from our gitlab pipelines). 6) Postman collection can be used for automation 7) ... As we can see there are several solutions adressing the same goals It probably would make sense to see if possible synergies are possible Would it make sense to plan a f2f meeting during next ONS summit? /Morgan _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12058): https://lists.onap.org/g/onap-discuss/message/12058 Mute This Topic: https://lists.onap.org/mt/24929469/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
