Depends on the service. Today we do MPLS VPN provisioning on a per vPE/PE basis and rollback just that vPE/PE.
When we have multiple devices in one SDNC transaction we make the DG handle the consistent application of the change or rollback as needed. We would generally avoid your use case since we tend to bring up new links on vPE's without touching the existing vPE's connections , but if we decided to do something like change 4 vPE's in one customer order we would pass in an array of the vPE changes and the DG would process the transaction using one of two mechanism. i) Careful booking of transaction and success and rollback (btw this is why we separate current md-sal data from input md-sal data) ii) Netconf-lite where the adaptor would do a netconf session to each device and only after all have check-commit successfully do we do the commits and unlocks. iii) In the end we would usually only touch one vPE at a time and on failure respond back to SO that orchestration has to be involved since generally we dont want to rollback the other 3 successfully configured vPE's. From: olivier.augiz...@orange.com [mailto:olivier.augiz...@orange.com] Sent: Thursday, July 06, 2017 11:48 AM To: FREEMAN, BRIAN D <bf1...@att.com>; Arun Arora (c) <aroraa...@vmware.com>; onap-discuss@lists.onap.org Subject: RE: SDN-C Code flow Queries Hello, My question related to the roll back mechanism was not related to each specific network adaptor but global to a DG execution. (Of course if a network adaptor cannot implement an "atomic" integrity we cannot have a global integrity) . Let's take as example a VPN provisioning involving 4 PMLS PE routers with the same Netconf adaptor. If the SDN-C can configure 3 PE and fails for the 4th --> how the global network configuration consistency is guaranteed ? Is the DG execution state stored and resumed later, is there a global roll-back? Or is it a DG design concern to handle each failure exception? Best regards, Olivier De : FREEMAN, BRIAN D [mailto:bf1...@att.com] Envoyé : jeudi 6 juillet 2017 16:23 À : AUGIZEAU Olivier DTSI/DERS; Arun Arora (c); onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Objet : RE: SDN-C Code flow Queries Responses below. Brian From: olivier.augiz...@orange.com<mailto:olivier.augiz...@orange.com> [mailto:olivier.augiz...@orange.com] Sent: Thursday, July 06, 2017 3:16 AM To: FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>>; Arun Arora (c) <aroraa...@vmware.com<mailto:aroraa...@vmware.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: RE: SDN-C Code flow Queries 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? >> They both have rpc attributes. If you look at the vnf-topology-operation DG >> it has an rpc called vnf-topology-operation. The vnf-topolog-operation DG >> has "call" nodes that refer to the sub-tending DG's like vnf-topology-assign >> (<call module='VNF-API' rpc='vnf-topology-assign' mode='sync' >) . the >> vnf-topology-assign rpc's etc do not need to be an rpc in the VNF-API.yang >> file since they aren't accessed via the REST API on the northbound side >> ([sdnc/northbound.git]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=VXIwVF_tiF9Uz59HYwZU52VdWZOSlqFlUFzgXu-Jrf8&e=> >> / >> vnfapi<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bf-3Dvnfapi-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=AbzV_bdXiC0m_tqe71TOv4gJLvhUOkKilHBsLbCKotY&e=> >> / >> model<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bf-3Dvnfapi_model-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=SZ8vHYliDvGaYZjCQmmP3cAUISUYHai3xg7T8MJ17Dc&e=> >> / >> src<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bf-3Dvnfapi_model_src-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=YrrEX4zYbliLLf4a5ueu9rT5wrxgauvfYlnzGQzy6Yk&e=> >> / >> main<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bf-3Dvnfapi_model_src_main-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=GN_SPbxsU5ou1d60FUY5w95q0sI4dcSUCgaOJOSzhyU&e=> >> / >> yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dtree-3Bf-3Dvnfapi_model_src_main_yang-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=iAJfjo5Pbxa95wRgJidf6Lfh4WUhhQECmXwM1yCrbOc&e=> >> / >> VNF-API.yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Dsdnc_northbound.git-3Ba-3Dblob-5Fplain-3Bf-3Dvnfapi_model_src_main_yang_VNF-2DAPI.yang-3Bhb-3Drefs_heads_release-2D1.0.0&d=DwMFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=ljASFxbEc5d1HogFJWN2v-THS1_j6GMcgrZaq6jCVIU&s=WDc3E47w06TnSyVOA70sGQFO5hUh7asbXXcCpVFsOOQ&e=>) (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 ? >> the DG needs to handle rollback - that depends on the adaptors since some >> adaptors have specific rollback capablity (like a netconf adaptor or BGP >> Flowspec - withdraw route) but others the DG will need to handle the >> rollback with a sub-graph (like cli/ssh where the DG needs to remember what >> the original config was - one of the reasons we are trying to get away from >> CLI as an industry) Thanks, Olivier Augizeau De : onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] De la part de FREEMAN, BRIAN D Envoyé : mercredi 5 juillet 2017 20:50 À : Arun Arora (c); onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Objet : Re: [onap-discuss] SDN-C Code flow Queries Some replies inline. Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Arun Arora (c) Sent: Wednesday, July 05, 2017 10:14 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> 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. _________________________________________________________________________________________________________________________ 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 onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
