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/INTDIST-37 integration-distribution <p>We need a mechanism to get the ODL version from:<br/> 1) karaf CLI<br/> 2) REST (or RESTCONF)<br/> 3) NETCONF/YANG</p> <p>I'm not sure where this should live - odlparent, controller (does that still exist as a project post-Lithium), or md-sal (but then you need to have md-sal to make this work - though does a controller with no md-sal make sense?)</p> <p>Operating System: All<br/> Platform: All</p> INTDIST-37

need mechanism to get ODL version

Bug Resolved Done Unassigned Giles Heron Fri, 11 Sep 2015 12:00:35 +0000 Fri, 20 Oct 2017 10:22:51 +0000 Wed, 4 Jan 2017 11:39:11 +0000 unspecified Version 0 2 <p>It looks like Restconf already exposes some statistics <span class="error">&#91;0&#93;</span>, perhaps a Restconf version string can be added there.</p> <p>Netconf is the most sure place to put such addition. Odlparent does not depend on mdsal, so there is no easy way to expose anything.<br/> On the other hand, integration/distribution may have the most direct version interpretation, but it has no Yang model yet for such additions.</p> <p><span class="error">&#91;0&#93;</span> <a href="https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=opendaylight/restconf/sal-rest-connector/src/main/yang/opendaylight-rest-connector.yang;h=c6c7c87115956d0324de34cbe0942043330f0e84;hb=refs/heads/master#l63" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=opendaylight/restconf/sal-rest-connector/src/main/yang/opendaylight-rest-connector.yang;h=c6c7c87115956d0324de34cbe0942043330f0e84;hb=refs/heads/master#l63</a></p> <p>The concept of 'the ODL version' makes sense in terms of a Simultaneous Release, and thus can be exposed only by the leaf (distribution) project. All other projects have independent versioning.</p> <p>Is it possible to get this fixed by Beryllium-SR2?</p> <p>&gt; Is it possible to get this fixed by Beryllium-SR2?</p> <p>&gt;&gt; 1) karaf CLI</p> <p>It is already there:<br/> feature:repo-list<br/> It outputs a long list, but you can use "| grep &lt;something&gt;" to narrow the list down. For example, current post-SR1 Beryllium snapshots contains these:<br/> odl-integration-0.4.1-SNAPSHOT | mvn:org.opendaylight.integration/features-integration-index/0.4.1-SNAPSHOT/xml/features<br/> odlparent-1.6.1-SNAPSHOT | mvn:org.opendaylight.odlparent/features-odlparent/1.6.1-SNAPSHOT/xml/features</p> <p>&gt;&gt; 2) REST (or RESTCONF)<br/> &gt;&gt; 3) NETCONF/YANG</p> <p>The simplest workaround is GET to &lt;host&gt;:8181/restconf/modules and classify modules (and revisions) present there. For example this one is in Beryllium but not in Lithium:</p> {"name":"aaa-authn-netconf-plugin","revision":"2015-07-15","namespace":"config:aaa:authn:netconf:plugin"} <p>and this one is in Beryllium-SR1 (possibly by an oversight) but not in Beryllium release:</p> {"name":"instance-identifier-patch-module","revision":"2015-11-21","namespace":"instance:identifier:patch:module"} <p>The downside is that presence of modules depends on features installed.</p> <p>As integration/distribution projects does not currently contain any yang models or config files, it is not probable to have a more straightforward solution before Beryllium-SR2.</p> <p>Hi Vratko,</p> <p>thanks for the info re Karaf. That's helpful.</p> <p>re REST and NETCONF/YANG yes, I've already suggested that people use the method you suggested. However it does feel like something of a hack to have to find a module that is in e.g. Beryllium but not in Lithium, and as you say it depends on features installed. So far I'm using ietf-inet-types <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Giles</p> <p>&gt; As integration/distribution projects does not currently contain any yang<br/> &gt; models or config files, it is not probable to have a more straightforward<br/> &gt; solution before Beryllium-SR2.</p> <p>I gave it a try anyway.<br/> <a href="https://git.opendaylight.org/gerrit/#/c/36311/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/36311/</a><br/> You would need odl-restconf, odl-netconf-connector-ssh and the new odl-integration-version feature installed.</p> <p>Still, it may take some time to merge that, as there are not many committers familiar with Java in integration/distribution.</p> <p>looks good to me <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>any value in me reviewing the code?</p> <p>&gt; any value in me reviewing the code?</p> <p>Yes, there are several string identifiers visible, and I am not sure my chosen values are systematic enough. This includes module name "odl-distribution-version", XML namespace "urn:opendaylight:params:xml:ns:yang:integration:distribution:version", type identity "odl-version", leaf name "version", config file name "odl-version.xml" and the two config-module names defined in it "odl-distribution-version" and "odl-odlparent-version".</p> <p>I should also find someone who is familiar with config subsystem to decide whether I got all the dependencies right (or whether it only works by accident).</p> <p>&gt; there are several string identifiers visible</p> <p>I forgot the feature name, currently "odl-distribution-version".</p> <p>the default-config.xml is hand-generated, right?</p> <p>is there any way to auto-generate it? that way there'd be no risk of the versions being out of sync between what we report and what we've actually built (if that makes sense...)</p> <p>&gt; the default-config.xml is hand-generated, right?</p> <p>Yes, and further manual edits are expected, as other projects may want to add their version.</p> <p>I am not expert enough to figure a way to make config-parent do replacements from defined properties (such as ${feature.odlparent.version}) before packaging the config file into the jar bundle. (I can open improvement Bug when this gets merged.)</p> <p>So far I am only trying to make sure that version bumping scripts will bump the value too. <a href="https://git.opendaylight.org/gerrit/#/c/36408" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/36408</a></p> <p>&gt; the default-config.xml is hand-generated, right?</p> <p>Currently, I favor using property values from pom file (where they would get bumped by current version bumping script).</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/37210/6" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/37210/6</a> (current Boron integration/distribution patch)<br/> <a href="https://git.opendaylight.org/gerrit/#/c/39427/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39427/1</a> (required patch in controller)</p> <p>Merged: <a href="https://git.opendaylight.org/gerrit/37210" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/37210</a><br/> Still waiting for: <a href="https://git.opendaylight.org/gerrit/39427" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/39427</a><br/> That is for Boron, backport to Beryllium will be the next step.</p> <p>So, Beryllium-SR3 and (almost surely) Boron do have the most of functionality, but user has to edit config file (or use restonf at runtime) to modify version values, due to <a href="https://jira.opendaylight.org/browse/CONTROLLER-1522" title="config-parent: Substitute properties in the default config file" class="issue-link" data-issue-key="CONTROLLER-1522"><del>CONTROLLER-1522</del></a> fix still not being merged.</p> <p>Carbon is on its way to get fixed: <a href="https://git.opendaylight.org/gerrit/46198" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/46198</a><br/> Boron may take longer time, Beryllium will probably be never fixed.</p> <p>Carbon is fixed.<br/> Boron: <a href="https://git.opendaylight.org/gerrit/48328" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/48328</a></p> <p>Boron change merged, test <span class="error">&#91;0&#93;</span> passes.<br/> As Beryllium will not get fixed, this Bug can be considered FIXED.</p> <p><span class="error">&#91;0&#93;</span> <a href="https://jenkins.opendaylight.org/releng/view/distribution/job/distribution-csit-1node-userfeatures-only-boron/lastSuccessfulBuild/robot/distribution-userfeatures.txt/Version/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/distribution/job/distribution-csit-1node-userfeatures-only-boron/lastSuccessfulBuild/robot/distribution-userfeatures.txt/Version/</a></p> Blocks CONTROLLER-1522 Development External issue ID 4296 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01lj3: