Hello, Thanks a lot Brian for this clarification.
Could you please give additional information about the following points? (3) "DG Builder builds the logic for processing rpc requests that are in yang models. 1 rpc == 1 DG" ? The sliapi Yang data model includes an execute-graph rpc that have other rpc as attribute Is the execute-graph rpc should be considered as a "meta" rpc with DG "rpc" as attribute? (5) "it is procedural logic meant to run to complete quickly and deal with devices" if a full rollback to the initial state is required in case of failure on any device, should the roll back procedure be explicitly designed in the directed graph or is it automatic with some kind of "all or nothing" global transaction integrity ? Thanks, Olivier Augizeau De : [email protected] [mailto:[email protected]] De la part de FREEMAN, BRIAN D Envoyé : mercredi 5 juillet 2017 20:50 À : Arun Arora (c); [email protected] Objet : Re: [onap-discuss] SDN-C Code flow Queries Some replies inline. Brian From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Arun Arora (c) Sent: Wednesday, July 05, 2017 10:14 AM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] SDN-C Code flow Queries Hi There, We are trying to understand the SDN-C code flow from its Northbound interface to Southbound Controllers which manage the controlled devices. Following is our understanding till now (build from ONAP Wiki and code reading): 1) SDN-C is based on ODL framework >> yes 2) ONAP has added SLI which understands the network configuration workflow >> yes 3) The DG builder builds different models (using YANG, XML). These models are then converted into SVC Recopies [Recipies] >> not quite. DG Builder builds the logic for processing rpc requests that are >> in yang models. 1 rpc == 1 DG >> 1 DG can call other DGs as needed to keep the size of any single DG manageable and to create re-useable DGs 4) SLI consumes into SVC Recopies to execute the network configuration workflow contained in the recipe >> yes the RPC in the yang model is a service recipe - the "input" data is the >> minimum data set needed for the service. >> the directed graph would then execute to fill out the rest of the containers >> in the model in the right sequence including assigning resources and >> calculating attributs as needed. Finally the DG at the ends of the branches >> would convert/map network data to the device specific attributes in config >> nodes. 5) Effectively the workflow is passed to one of he underlying Network Adaptors which actually configure the necessary network resources >> I hesitate to call it a workflow - it is procedural logic meant to run to >> complete quickly and deal with devices not people and uses in some cases >> network signaling protocols like BGP >> it is the adapters that do the real work of "safe changes in state" of the >> network which includes things like applying engineering rules to the >> resource assignments and calculated network attributes (think calculating >> static routes from newly assigned ip addresses for example) 6) The update (success/ failure) is sent to MSO and AAI once the request is complete >> yes. Although the response is to MSO. AAI is updated on success or failure >> as appropriate. SDNC is the source of truth for network data in AAI that is >> set/configured/assingned by SDNC. Following are the code modules we know till now: 1) From MSO mso-sdn-adaptor calls VNFAPIProvider() in SDNCAdpaterRest.java 2) VNFApiProvider() - receives the request and invokes the activate/configure services >> the VNFApiProvider is the simplest case of MSO-SDNC interaction and really >> is used for dealing with L4-L7 VNFs that have a need for resource assignment >> but not any controller configuration. Questions: 1. We have seen multiple entry pointers across SDN-C/SLI, dmaplisterner, uebClient, admportal and dgbuilder. But the interaction of these with each other, VnfAPIProvider() and southbound interfaces is not clear >> you need to separate design time / onboarding vs run time. >> dgbuilder is used as design time to create directed graphs. It is not used >> during run time. In fact we dont deploy it in production SDNC instnaces we >> use the desktop version and check the json strings into git. >> admin portal is only used to load/modify directed graphs and interact with >> mysql at design time if needed. >> uebclient is deprecated and it will go away - it was replaced with the >> dmapplistener >> dmaaplistener is used during onboarding when new models are distributed from >> SDNC >> SDNC/SLI is the run time component that is called when a REST RPC request is >> sent into the controller. A provider class is called by the rpc and this in >> turn pulls the xml form of the directed graph from mysql and calls the >> "execute" function othe SvcLogic object. 2) Post, VnfAPIProvider() how the allocateResourceL3SDN()and later the Southbound Adpator APIs are called is not known >> SDNC is nto demonstrating them in this release. The southbound adapter of interest in SDNC is probably the aai adapter. You can see how the DG updates AAI in the activate and delete sub-direcged graphs >> I would also point you to the tutorial on the wiki on the creating a netconf mount on APPC from SDNC's VNF API DG. While we are trying to understand the code further, if anyone can give some pointers or explain the codeflow on a broader level, it would be extremely helpful. Thanks, Arun Arora _________________________________________________________________________________________________________________________ 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.
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
