Morgan, Went through the code for VNF On boarding still trying to understand the logic. Point 1 that you are on boarding the VNF with or without Orchestrator (why not call it nfvo and being opera or orchestra) similarly why juju_vnf and not vnfm as Juju or Tacker or OpenBaton vnfm, looks to abstractions are needed rather than specifics which should be included as internal names.
Nevertheless let me better understand before I add any comments to code, so I did not put a+1 yet to it. We have 7 AM PST TSC and 8 AM PST Release planning meeting. The Functest meeting appears to be mid night for me but will follow up tomorrow based on the minutes of the meeting and bring that to MANO WG call on Wednesday 7 AM PST to collect all the inputs to respond back for both D-Release priority plus the code review to close the VNF On-boarding and testing. Another question, Is there any relation between this and OAI ? May be you can help me on that. Thanks Prakash Prakash Ramchandran [logo_huawei] R&D USA FutureWei Technologies, Inc Email: prakash.ramchand...@huawei.com<mailto:s.c...@huawei.com> Work: +1 (408) 330-5489 Mobile: +1 (408) 406-5810 2330 Central Expy, Santa Clara, CA 95050, USA From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com] Sent: Monday, January 09, 2017 8:54 AM To: Carella, Giuseppe Cc: Yingjun Li; zhao.huab...@zte.com.cn; meng.zhaoxi...@zte.com.cn; by...@etri.re.kr; Narinder Gupta; Yunxia Chen; Olga Havel; Tomasini, Lorenzo; Pauls, Michael; rohit.gu...@eurecom.fr; navid.nika...@eurecom.fr; wlu...@bupt.edu.cn; cs15mtech01...@iith.ac.in; cs15mtech01...@iith.ac.in; Prakash Ramchandran; SULLIVAN, BRYAN L; Jose Lausuch; David McBride; opnfv-tech-discuss@lists.opnfv.org; valentin boucher Subject: Re: [OPNFV] [FUNCTEST] [Danube] VNF OnBoarding Hi Guiseppe I think I got your point As you mentioned we should differentiate 2 things - VNF onboarding: testing the capability to deploy a VNF with or without an orchestrator and test the VNF - Mano stack validation see as a feature available in scenario(s) the proposal was related to the first topic only the idea of the abstraction is to try to harmonize the way we deploy the VNFs, it is also a guide for VNF and/or MANO providers for the intergation and it shall encourage VNF providers to integrate the test suite as part as the VNF to ease an integration in OPNFV scenario(s) for Danube we can see that we should have several orchestrators deploying the vIMS for the second point, I agree with you, it could be considered as a "feature" assuming that a scenario includes an orchestrator then we can define a specific constraint and run any test suites to the MANO stacks related to the scenario as any feature as a feature, functest can triggers the test then the MANO stack testing will be automatically integrated in the reporting page and used to calculate the Functest scenario scoring (http://testresults.opnfv.org/reporting/functest/release/master/index-status-fuel.html) Let's continue discussing it tomorrow /Morgan Le 09/01/2017 à 12:23, Carella, Giuseppe a écrit : Hi Morgan, during the last days we have done a review (not fully complete yet) about the approach you proposed for integrating our test scenario with functest, and we internally agreed that this approach should be enough for us to test the vIMS scenario running on Orchestra. We already have some code which we plan to commit during this week, however it would be good to discuss with you all about some doubts we are having during tomorrow’s call. In the wiki page you sent it is mentioned also that "Functest does not test any MANO stack”. In general, in Orchestra we would be interested in having some integration scenarios which could be useful for covering test cases for MANO frameworks. We have already an upstream project [1] doing something similar, and our initial plan was to integrate this project within OPNFV functest, as already mentioned earlier to Jose. With the approach taken in your abstraction I see that this integration won’t be really easily doable. Main reason is that our integration-test framework already splits the test cases in different steps, while you cover at the moment mainly two steps (deploy VNF and test VNF) * registration of a VIM instance * on boarding a NSD * deployment a NSR using the on boarded NSD from previous step * testing that the NS is really deployed (optional in case of negative testing) * deletion of the NSR * deletion of the NSD * unregistration of the VIM With our framework, it is possible to define a scenario (and the steps which needs to be executed) directly using a configuration file. An example of a scenario can be found here [2], deploying an iperf server and client network service and testing that the client connected effectively with the server (therefore testing that dependencies were correctly configured between VNFs). Although I see that your approach can be further extended to include those additional steps, I would suggest not to have them as part of VNF testing, rather starting creating a new set of test cases which can be part of a MANO group (or maybe including them in the feature tests group?). Nevertheless, coding the test steps in a specific programming language will also limit the integration of existing external frameworks (like the one we already have) MANO providers may already have implemented. In summary, talking about the Orchestra project, we will provide soon the code for testing the deployment of a VNF (vIMS based on OpenIMSCore) implementing the abstract class you provided and following the approach taken for cloudify. However, as we assume that in the future the Orchestra project will be directly integrated with at least one installer, we would like to include some more comprehensive use cases that can execute several (positive and negative) test cases, possibly using already existing frameworks (like the one I mentioned). Would that be feasible within functest? PS: I added myself as reviewer in gerrit ;-) [1] https://github.com/openbaton/integration-tests [2] https://github.com/openbaton/integration-tests/blob/master/src/main/resources/integration-test-scenarios/scenario-real-iperf.ini Cheers, Giuseppe Download Open Baton already today: http://openbaton.org On 06 Jan 2017, at 17:27, morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> wrote: Dear Orchestra, Opera, OAI teams I would like to know the status on VNF onboarding for Danube. My last view was that you all were candidates to integrate a testcase integrating an orchestrator (respectivelly Openbaton, Open-O, Juju for OAI) to deploy a VNF (respectively ??, vIMS, vEPC(OAI)). I created a wiki page to explain how to do it with Functest https://wiki.opnfv.org/pages/viewpage.action?pageId=8687767 a patch is currently pending (including some preconfiguration for you) https://gerrit.opnfv.org/gerrit/#/c/26769/ I was only able to add Open-O team for review (other contributors not found from gerrit) Valentin who created the cloudify_vims showed in Berlin adapted his code to the VNF abstraction we are suggesting (we also provide an abstraction for feature project). This abstraction and more globally the integration in Functest should harmonize the way we are testing VNF from Functest perspective and allow an integration in CI process including test result collection and scenario reporting. Do you want to use Functest framework for Danube? As we are now entering the integration phase, it is important to get your feedback on your plan for Danube. Any comment welcome: framework, abstraction, needs,... We have a weekly meeting on IRC avery Tuesday 8 UTC, I added a slot for next week. Thanks & regards -- Morgan Richomme Orange/ IMT/ OLN/ CNC/ NCA/ SINA Network architect for innovative services Future of the Network community member Open source Orange community manager tel. +33 (0) 296 072 106 mob. +33 (0) 637 753 326 morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> _________________________________________________________________________________________________________________________ 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. -- Morgan Richomme Orange/ IMT/ OLN/ CNC/ NCA/ SINA Network architect for innovative services Future of the Network community member Open source Orange community manager tel. +33 (0) 296 072 106 mob. +33 (0) 637 753 326 morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> _________________________________________________________________________________________________________________________ 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.
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
