Hi, Some of the questions below refers to SDNC managed devices YANG schemas , which ODL gets from the devices once the device is mounted. Are we planning to allow getting customized version of those schemas from SDC for allowing fixing problems on the managed devices yang?
Some of the answers referred to the yang models which are being used to define SDNC NB interfaces (Service RPC+ data model + storage schema) As Dan explained today these are required in compile time and for that there is no sense of getting in runtime via SDC. In APPC we do allow getting YANG schema from SDC in runtime , we are using these to define the structure and the storage schema of the specific VNF APPC Is managing. Loading NB yang schema dynamically to ODL is tricky , mainly as ODL is not providing API for that and forces you to upload a synthetic OSGI bundle with yang schema embedded. I have started the engagement with ODL community for adding this support while back , if SDNC has the same interest (which makes a lot of sense to me.) maybe its good time to revive this discussion. Avi, From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of TIMONEY, DAN Sent: Saturday, July 8, 2017 4:03 AM To: ROZIN, EDEN <er4...@intl.att.com>; Thomas Nadeau <thomas.nad...@amdocs.com>; FREEMAN, BRIAN D <bf1...@att.com>; NOSHPITZ, CLAUDE <cn5...@att.com>; LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format All, The YANG.XML artifact type name is perhaps a bit confusing. The actual artifact itself is in XML format. The YANG.XML designation indicates that the structure of the file is defined by a Yang model. The Yang model itself isn't distributed by SDC. In the case of SDNC, we need to have the Yang model available to us at compile time so that we can use it to generate the code to parse XML files defined by that model. So, right now there really wouldn't be much use at least to SDNC in distribution of the Yang model itself via SDC. In the longer term, though, we are looking into being able to handle Yang models more dynamically. So when we get that working, we may very well be very interested in receiving Yang models from SDC. But that would not be in scope for release 1. Hope this helps, Dan Sent from MyOwn, an AT&T BYOD solution. ________________________________ From: "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com>> Date: Thursday, July 6, 2017 at 12:50:05 PM To: "Thomas Nadeau" <thomas.nad...@amdocs.com<mailto:thomas.nad...@amdocs.com>>, "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>>, "NOSHPITZ, CLAUDE" <cn5...@att.com<mailto:cn5...@att.com>>, "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>, "Kedar Ambekar" <ake...@techmahindra.com<mailto:ake...@techmahindra.com>> Cc: "WRIGHT, STEVEN A" <sw3...@att.com<mailto:sw3...@att.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. The artifacts types are configurable, so there is a way to add 'YANG' as another type for artifacts upload. All the artifacts are located inside the distributed CSAR that contain all the relevant Service information. If SDN-C would like to get the artifacts, they can. Eden From: Thomas Nadeau [mailto:thomas.nad...@amdocs.com] Sent: Thursday, July 06, 2017 12:26 AM To: FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>>; NOSHPITZ, CLAUDE <cn5...@att.com<mailto:cn5...@att.com>>; Lando,Michael <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; Rozin, Eden <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: RE: [onap-discuss] YANG.XML format +1 While I'd love for all the new features in 1.1 to be available, the bottom line is as Brian said: actual production device support which in my estimation will take a bit longer. --Tom From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, July 5, 2017 4:12 PM To: NOSHPITZ, CLAUDE <cn5...@att.com<mailto:cn5...@att.com>>; LANDO, MICHAEL <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; ROZIN, EDEN <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format The industry is still on yang 1.0 so I would focus on that version for now. Yang 1.1 is emerging and ODL Carbon has limited support for it but its very new. I only know of one device that supposedly supports yang 1.1. 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 NOSHPITZ, CLAUDE Sent: Wednesday, July 05, 2017 4:08 PM To: LANDO, MICHAEL <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; ROZIN, EDEN <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Is there a normative set of RFCs/standards that we plan to adhere to for the YANG work in ONAP? I'm asking as an observer (without specific YANG expertise :-) wanting to make sure we pave the way for a coherent developer experience moving forward. The ONAP Wiki references RFC 6020<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6020.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI&e=> (YANG 1.0) -- is this superseded (?) by RFC 7950<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6991.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA&e=> (YANG 1.1)? And then there's the JSON encoding proposed in RFC 7951<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7951&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI&e=>. It would be useful to consolidate around a consistent representation, given that different toolchains/consumers may need to interoperate. Is there a need to reference the various core data models (RFCs 6991<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6991&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0&e=>, 7223<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y&e=>, 7317<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM&e=>, and all their friends), or is their use otherwise clearly implied? There was discussion along these lines in the "VNF Management Requirements for OpenECOMP" document<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Reference-2BDocuments-3Fpreview-3D-252F1015849-252F1017888-252FVNF-2BManagement-2BRequirements-2Bfor-2BOpenECOMP.pdf&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=_eTL0pDKKxFtg2kDy6IvwGjgoKdsfMZ9Xb7y9xOsnvs&e=>, which is seeded into the VNF Requirements project. Maybe the questions I'm asking (and those that Kedar posed previously) just ought to be referred to that workstream... Thanks! --Claude From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>> Date: Wednesday, July 5, 2017 at 11:09 AM To: Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>, "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. +Edan BR, Michael Lando Opensource & Frontend Team Lead, SDC AT&T Network Application Development * NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago *************************************************************************** Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kedar Ambekar Sent: Thursday, June 08, 2017 4:17 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format Hi Michael, Couple of questions around YANG. 1. If I have YANG model from VNF Vendor in JSON format, can I use it in SDC ? Or it accepts only in XML format ? 2. Not remember where, but I read that ONAP SDC does not distribute YANG model to SDNC. Is this correct ? 3. If # 2 is correct, can YANG be fed directly to SDNC by invoking any API ? ODL API ? Thank you.. From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Lando,Michael Sent: Monday, June 5, 2017 3:56 AM To: Law, Owen <owen....@team.telstra.com<mailto:owen....@team.telstra.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format The current guide line is that the file be a valid xml and that the file ending be.xml. No additional requirements/validations are done for this artifact. BR, Michael Lando Opensource & Frontend Team Lead, SDC AT&T Network Application Development * NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago *************************************************************************** Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] YANG.XML format Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition - is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen ============================================================================================================================ 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=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY&m=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4&s=zuxLhU26Z-QENdqYywiQxyoHugmT9np_hi_N4HnJWyQ&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=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY&m=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4&s=XDy5dphHs4UEWk4Bd5WeR54dPgl9d7QZlpbj6JOwzJ4&e=> internally within TechMahindra. ============================================================================================================================ This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=5dr94prXH2Bs3fZkzpVsASPcH93hpNUM-tY-Nz-yrlM&m=a5Mu7ykPu6M_rOwLL6yWqlWReJQVgEfHqKbxHi7_G7Y&s=WnDfWiG0Uh9AB5PXzffBB-H89gwP_91GmgCfY13bItw&e=> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss