https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-3 netconf <p>It's needed to add functionality to ODL - getting yang model (in yin format) via rest API from physical net elements with info about datastorage - config or operational.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-3

Export schema information for data subtree

Improvement Resolved Done Unassigned Lucia Pargacova Tue, 20 May 2014 13:29:23 +0000 Fri, 15 Mar 2019 22:22:09 +0000 Fri, 12 Oct 2018 07:45:11 +0000 restconf-nb 0 7 <p>Maybe Restconf API explorer can be somehow used in this (<a href="https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf_API_Explorer" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf_API_Explorer</a>)</p> <p>Are you asking for returning YIN version of YANG data?</p> <p>So there are two things we can do:</p> <p>1) implement yang-monitoring in MD-SAL, as Tony suggested</p> <p>2) expose current schemacontext as a REST-rooted document</p> <p>There are upsides and downsides to both and I think we really want to do both. The upside of 1) is simplicity and existing model of model. The downside is that it gives you only module-level visibility, not how things fit together.</p> <p>Option 2 requires a custom REST endpoint, but it gives you the properly cross-referenced view of how the data world looks like from the perspective of the controller, e.g. all augments are properly resolved, all uses are inlined, etc.</p> <p>In regard to option 1/ (at least for our needs), single module visiblity wouldn't be a problem, because we already working with it (we are already processing uses/grouping and augment statements)</p> <p>Move to NETCONF project</p> <p>YIN export is available from the yangtools project. RESTCONF needs to project these exports via the protocol &#8211; I think yang library should cover this.</p> <p>Described functionality should be present both in RFC8040 and Bierman02 RESTCONF implementations.</p> <p> </p> <p>Bierman02: See SchemaRetrievalService.java API, you should be able to get ODL and mountpoints schemas at:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> /modules/module/{identifier:.+}/schema</pre> </div></div> <p>where identifier is module name and revision (ODL schemas) or mountpoint id and module name with revision (mountpoint schemas).</p> <p> </p> <p> </p> <p>Please see following examples,</p> <p>ODL schema resource:</p> <p> </p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> restconf/modules/module/ietf-netconf/2011-06-01/schema </pre> </div></div> <p>mountpoint schema resource:</p> <p> </p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> /restconf/modules/module/network-topology:network-topology/topology/topology-netconf/node/netconf-node/yang-ext:mount/ietf-netconf/2011-06-01/schema </pre> </div></div> <p> </p> <p>For RFC 8040 implementations, you should be able to get schemas at:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> /rests/modules/{identifier:.+} </pre> </div></div> <p>where identifier is again module name with its revision or for mountpoint schemas you need to add also mountpoint id.</p> <p> </p> <p> </p> <p>Both YANG and YIN formats are supported (you can specify them in accept HTTP header).</p> Development External issue ID 1049 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i01vuv: