Le 10/01/2017 à 08:27, Prakash Ramchandran a écrit : > > 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. > we will suggest an ad hoc meeting Functest/ VNF on boarding / MANO features not easy to find a convenient time slot for everybody... :) I f needed we can organize 2 meetings > > > > Another question, Is there any relation between this and OAI ? May be > you can help me on that. > OAI was candidate with their vEPC deployed through Juju (some documentation on the wiki) but I saw that Rohit who was leading the activity left OAI, so I do not have anymore info If @anyone from OAI in the thread could give us an update, it will be appreciated
> > > Thanks > > Prakash > > > > > > *Prakash Ramchandran* > > logo_huawei* R&D USA* > > *FutureWei Technologies, Inc* > > Email:[email protected] <mailto:[email protected]> > > Work: +1 (408) 330-5489 > > Mobile:+1 (408) 406-5810 > > 2330 Central Expy, Santa Clara, CA 95050, USA > > > > > / / > > / / > > > > > > *From:*[email protected] [mailto:[email protected]] > *Sent:* Monday, January 09, 2017 8:54 AM > *To:* Carella, Giuseppe > *Cc:* Yingjun Li; [email protected]; [email protected]; > [email protected]; Narinder Gupta; Yunxia Chen; Olga Havel; Tomasini, > Lorenzo; Pauls, Michael; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; Prakash > Ramchandran; SULLIVAN, BRYAN L; Jose Lausuch; David McBride; > [email protected]; 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, [email protected] > <mailto:[email protected]> 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 > [email protected] <mailto:[email protected]> > > > > _________________________________________________________________________________________________________________________ > > 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 > [email protected] <mailto:[email protected]> > _________________________________________________________________________________________________________________________ > > 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 [email protected] _________________________________________________________________________________________________________________________ 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 [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
