It looks like Restconf already exposes some statistics [0], perhaps a Restconf version string can be added there.
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.
On the other hand, integration/distribution may have the most direct version interpretation, but it has no Yang model yet for such additions.
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.
Is it possible to get this fixed by Beryllium-SR2?
> Is it possible to get this fixed by Beryllium-SR2?
>> 1) karaf CLI
It is already there:
feature:repo-list
It outputs a long list, but you can use "| grep <something>" to narrow the list down. For example, current post-SR1 Beryllium snapshots contains these:
odl-integration-0.4.1-SNAPSHOT | mvn:org.opendaylight.integration/features-integration-index/0.4.1-SNAPSHOT/xml/features
odlparent-1.6.1-SNAPSHOT | mvn:org.opendaylight.odlparent/features-odlparent/1.6.1-SNAPSHOT/xml/features
>> 2) REST (or RESTCONF)
>> 3) NETCONF/YANG
The simplest workaround is GET to <host>:8181/restconf/modules and classify modules (and revisions) present there. For example this one is in Beryllium but not in Lithium:
{"name":"aaa-authn-netconf-plugin","revision":"2015-07-15","namespace":"config:aaa:authn:netconf:plugin"}and this one is in Beryllium-SR1 (possibly by an oversight) but not in Beryllium release:
{"name":"instance-identifier-patch-module","revision":"2015-11-21","namespace":"instance:identifier:patch:module"}The downside is that presence of modules depends on features installed.
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.
Hi Vratko,
thanks for the info re Karaf. That's helpful.
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 
Giles
> 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.
I gave it a try anyway.
https://git.opendaylight.org/gerrit/#/c/36311/
You would need odl-restconf, odl-netconf-connector-ssh and the new odl-integration-version feature installed.
Still, it may take some time to merge that, as there are not many committers familiar with Java in integration/distribution.
looks good to me
any value in me reviewing the code?
> any value in me reviewing the code?
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".
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).
> there are several string identifiers visible
I forgot the feature name, currently "odl-distribution-version".
the default-config.xml is hand-generated, right?
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...)
> the default-config.xml is hand-generated, right?
Yes, and further manual edits are expected, as other projects may want to add their version.
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.)
So far I am only trying to make sure that version bumping scripts will bump the value too. https://git.opendaylight.org/gerrit/#/c/36408
> the default-config.xml is hand-generated, right?
Currently, I favor using property values from pom file (where they would get bumped by current version bumping script).
https://git.opendaylight.org/gerrit/#/c/37210/6 (current Boron integration/distribution patch)
https://git.opendaylight.org/gerrit/#/c/39427/1 (required patch in controller)
Merged: https://git.opendaylight.org/gerrit/37210
Still waiting for: https://git.opendaylight.org/gerrit/39427
That is for Boron, backport to Beryllium will be the next step.
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 CONTROLLER-1522 fix still not being merged.
Carbon is on its way to get fixed: https://git.opendaylight.org/gerrit/46198
Boron may take longer time, Beryllium will probably be never fixed.
Carbon is fixed.
Boron: https://git.opendaylight.org/gerrit/48328
Boron change merged, test [0] passes.
As Beryllium will not get fixed, this Bug can be considered FIXED.