To Dhananjay,
1. For configuration of devices yes, but the demos don’t use them because the virtual functions are not configured they are hard coded. A real vnf would need to have yang. 2. For the demos, nothing. 3. 3a is a one time thing, it does stuff like populate vim stuff (region and tenant) the expectation in a real cloud is youd fill those in as regions are created. It also creates a subscriber which is basically a customer and would presumably be done upstream in a bss / oss / wherever when they are first created. 3b, 3c and 3e I think there is an enhancement in the works to allow the whole thing to be instantiated at once, mso can confirm. It may already be possible, since we do have the model we know the steps of everything. 3d is a bit of an odd child, its data that is needed to complete the instantiation but which is not provided in the model. Internally we use external systems for a lot of it (ipam etc) and the preload is just what is left of that. The rebase we are testing now should remove the need for this as this info is asked for in vid. 3f mso will do, there is a story open for that. 4. 3b, 3c, 3e are already done in SO (nee MSO), 3a is outside process (you don’t create tenants in openstack when calling nova create server for instance) and 3d and 3f are temporary things that should be going away soon. To Viswa, This decomposition is already done, just not shown in the demo so well, the model and the SO do know the order. And MSO is involved (see response to Dhananjay above). Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: Viswa KSP [mailto:[email protected]] Sent: Thursday, June 01, 2017 1:43 PM To: Dhananjay Pavgi <[email protected]> Cc: [email protected]; ROSE, DANIEL V <[email protected]> Subject: RE: [onap-discuss] Why there is a manual step before deploying a distributed / certified network service? Thanks Daniel. I do have a follow up query. Adding to what Dhananjay has quoted, should the decomposition of network service be taken care automatically by service orchestrator ? If we see Open -O or XOS/CORD, the story remains same . We provide NSD and the master orchestrator takes the burden of decomposing network service requirements, identify dependencies w.r.t infrastructure ( NF -O ) and network ( SDN-O ) , along with life cycle work flow. Is there any reason ( architectururaly ) , why MSO isn't involved here ? BR, Viswa On Jun 1, 2017 9:47 PM, "Dhananjay Pavgi" <[email protected]<mailto:[email protected]>> wrote: Thanks, Daniel. Few related questions as below: 1. When it comes to “Service Instantiation” on VNFs; don’t we need Yang models. 2. i.e. what does finally SDNC send as a payload over Netconf? 3. Also, our understanding of APIs being called is as below (which is right now manual activity in vFW demo): a. Run demo.sh init script (We will share these details but essentially it invokes AAI REST APIs) b. Service Instance Create c. VNF Create d. Run demo.sh preload (We will share these details but essentially it invokes SDNC REST APIs) e. VF Module Create f. Run demo.sh appc script (We will share these details but essentially it invokes APPC REST APIs) 4. Ideally, 3a through 3f above should be handled by “Service Orchestrator”, right? thanks & regards, Dhananjay Pavgi Mobile : +91 98220 22264 [cid:[email protected]] [ONAP_logo_Sig] www.techmahindra.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=eKSSa5svrJJZIBjHGiq0bOAK3KpUelMy_gIEFUd7aXM&e=> Platinum Member. Visit : http://www.onap.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=XGAJqN0REk91XmBABHIg5_3B4vOdE6XO9tZMP59_dZo&e=> From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of ROSE, DANIEL V Sent: Thursday, June 01, 2017 7:54 PM To: Viswa KSP <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] Why there is a manual step before deploying a distributed / certified network service? The demo is specifically just a demo. So the stuff in the demo like the robot scripts will not work for other vnfs. The mechanisms used in the scripts will work with any vnfs however. To give you an example, preload command calls sdnc rest api that loads info like IPs to sdnc so that when you go to vid and instantiate a vnf sdnc knows what data to use. You can call that api yourself to fill in your specific parameters for ANY vnf ( you can add a call to the DG to make a call out to any external system via rest instead of doing the preload also). In the rebase code VID has the option to provide those preloads as part of the GUI to make it a bit easier but even though the flow changes the fact that it applies to all VNFs does not change. Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Viswa KSP Sent: Thursday, June 01, 2017 4:50 AM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Why there is a manual step before deploying a distributed / certified network service? Dear All, We are trying to follow the steps as per tutorial to bring demo vFirewall Network service. While the steps before deploy operation ( i.e creation of license model, design-test-certify cycle for VSP, VF & NS and finally distributing NS for production ) seems to be generic & acceptable for other VNFs, the step for running demo.sh in robot VM to enable "Deploy" in VID seems to very specific to vFirewall NS. I would like to understand if this manual step is expected in any other NS? What if we wanna customize the work-flow i.e say I want to just design my NS and just deploy it right away ( without other steps as per demo work-flow ) , how should I go-about in achieving this? On a very high-level, I would like to know how much we can customize ONAP ? BR, Viswa ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=OA8rnrS-dBDPZLs0KDL3htkm1D9AsYCaCxZoSDkaViw&e=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=wj-P9f9XBIxdpyIqrRsIg4InkRWIvIwz0MSTL3reH3M&s=mOiRMi1aNG1XHwE9Vf78B94NGLAGHOKf_Iy5mdLlchU&e=> internally within TechMahindra. ============================================================================================================================
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
