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]> 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 > > [image: cid:[email protected]] [image: > ONAP_logo_Sig] > > www.techmahindra.com Platinum Member. Visit : > http://www.onap.org > > > > *From:* [email protected] [mailto:onap-discuss-bounces@ > lists.onap.org] *On Behalf Of *ROSE, DANIEL V > *Sent:* Thursday, June 01, 2017 7:54 PM > *To:* Viswa KSP <[email protected]>; [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:onap-discuss-bounces@ > lists.onap.org <[email protected]>] *On Behalf Of *Viswa > KSP > *Sent:* Thursday, June 01, 2017 4:50 AM > *To:* [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 externally http://tim.techmahindra.com/tim/disclaimer.html > internally within TechMahindra. > > ============================================================ > ================================================================ >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
