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 >> >> >> _________________________________________________________________________________________________________________________ >> >> 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 _________________________________________________________________________________________________________________________ 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
