[ODLPARENT-259] Expose distribution information from karaf4-parent Created: 27/Mar/18 Updated: 30/May/23 |
|
| Status: | Confirmed |
| Project: | odlparent |
| Component/s: | Karaf |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0 |
| Type: | New Feature | Priority: | Medium |
| Reporter: | Jamo Luhrsen | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
There is an old version feature we had in the integration/distribution project where we could do some tricks/configs/feature-installs and then with a REST GET we could query the "version" (e.g. Carbon SR2) would be in the response. This feature is stale now and will be removed in Fluorine. We are wondering if this is something we can add to infrautils going forward. It can be just as basic as a new servlet with an endpoint to hit and returns the contents of a file that is generated by our autorelease process. Or whatever smarter tricks, bells and whistles people think of. One idea floated at the ONS 2018 (LA) DDF was that we could add this to our servicestatus feature, maybe even figuring out the packaged projects git sha1 ids to return. |
| Comments |
| Comment by Daniel Farrell [ 27/Mar/18 ] |
|
It would also be cool if we could get the hashes of the repos that built the distro. These are in a file in the root of every distro. |
| Comment by Jamo Luhrsen [ 02/Apr/18 ] |
yes, vorburger, I forgot about this when we sat together to talk this one through. There is a file at the root of the distro (created by autorelease. they are not there in snapshot distros) that looks like this: [centos@jamo-rc701 karaf-0.7.2]$ pwd /home/centos/odl/karaf-0.7.2 [centos@jamo-rc701 karaf-0.7.2]$ cat taglist.log autorelease 9413cb37bc2f04dfd75e13608869b36d2ff18c41 Nitrogen aaa 2165023f247c4bd79ed1014262c6755f09a291b8 Nitrogen alto 7983f3fcad754f77be52e0ca83562c30c6d330e4 Nitrogen bgpcep a53fd0a4cbd703523f8e835f37acc8a04c78c6e5 Nitrogen bier 54613b43284c1a823485c6bd112089cb164b950c Nitrogen cardinal 98e49bf8e790d94fdaf8d78431d6d261f4e268f1 Nitrogen coe 1bb5b23861bec42a428219c65e51d62a230088ff Nitrogen controller 68661ad77730c10b3c2ac7db0ea036968da96195 Nitrogen daexim 263d399ec96b7c3c4265d9b9d1886a1392fc1472 Nitrogen dlux f36b88456e7716e5997db827d387fde102f25ca0 Nitrogen dluxapps f0b2903871a585882a9348960270817d9c037eac Nitrogen eman 586b709832245b85001bb1ba7d6138687340d6d4 Nitrogen faas 197e1ee832d600f80a7b4e9f2bcc9f1c0ec69a74 Nitrogen genius 5630daa8e236bfd8382e144bb4e5e3d264ecd3fb Nitrogen groupbasedpolicy 8edb19b8acec892a4ebb53d1f7c52fb15df8d5f6 Nitrogen honeycomb/vbd 127abff4a73e7d1d9700d32ae9e3d52eca044796 Nitrogen infrautils c16ed41723eea8092687005d41f206c0fb9a8b74 Nitrogen integration/distribution 167465faf318490dec24b4939f65dfdb161df58f Nitrogen l2switch 402c734f0802ad180646c20284e0e85af5910edd Nitrogen lispflowmapping 4d9a7cf217d301b9c1223202e2161a4f5f58bfd5 Nitrogen mdsal 13c0d0ea63a15e51f3cc3b7c4c976d77a2652fbf Nitrogen nemo 561839e7e1862bde8adc303e0f6459a6a7bb4fa7 Nitrogen netconf 85591665ccfc514a10e405d9e96ab916d252d507 Nitrogen netvirt c677a25b5d9b729c10da310f28eb30f96a46b412 Nitrogen neutron 367cc0d5011c5ebb3899729879781ff97c4615ef Nitrogen nic 14f28a44cab71f5d0820ebc949b379d19eb46e96 Nitrogen ocpplugin 9ae60d1e528c6f1e2c7e870806adc30e7b45de68 Nitrogen of-config 861ad83dbaa165ea9d8da7b6356eb79f650d5f94 Nitrogen openflowplugin c9499016f225110c3dcb1824d490edcd28e15737 Nitrogen ovsdb 7a5c1f14ef06c631ee820f231f3b65e583191c2b Nitrogen packetcable 6eddb1de51f02e819b31d5fa75ea7d0843a5e6d8 Nitrogen sfc 972595f99ec2c591259684e487c91e3e86eb74cb Nitrogen snmp 02cf37694731cbb7aee70f0211556428b524fccd Nitrogen snmp4sdn 93199fe394a8919edf9369fa1ab505d4ee84b9cd Nitrogen sxp ccb931f444adc5e031f45dd6c4e0642b7ff28f4e Nitrogen topoprocessing ce919426b3bae6193e0e6dc6bf9a7a60c65dcf8f Nitrogen ttp a66f5b28b9e1bf5ee29b353c046267ceeb661fa4 Nitrogen unimgr eed7fce812f5a53a72ffd1258a8c962fbeff0d78 Nitrogen usc fa53ebd773b149091b9111a5ce1ab6786749dbb9 Nitrogen vtn 0201abac45046d7817a748ddb0cf138dc6b70f3f Nitrogen yangtools 3806c462a329a3599ccf86d0d06adfaa3713092e Nitrogen [centos@jamo-rc701 karaf-0.7.2]$ |
| Comment by Michael Vorburger [ 03/Apr/18 ] |
|
[Adding skitt who may also have views to chime in on exactly how/where to best go about building this idea.] How about instead of reading magic files in distribution, which may or may not be there, and which won't work in Karaf built locally by projects (such as netvirt) instead of integration/distribution, we build this by scanning for and peeking into the META-INF/git.properties file we have in each of the ODL JAR? FYI: When I (many moons ago) originally contributed git.properties to odlparent, based on https://github.com/ktoso/maven-git-commit-id-plugin, I always thought one fine day we were going to exploit in an "about" CLI and/or HTTP GET /about ... Looking into any such git.properties, I'm not 100% sure our "release name" is easily obtainable from it.. thoughts? There is an e.g. git.closest.tag.name=release/nitrogen-sr1 but I'm not 100% sure this is right and what we would want? jluhrsen you verbally mentioned something about the build adding a "fake commit" on release which would break this? We should probably clarify this first, before we sink any coding work into this. Do any known downstream builds "sanitize" or modify the content of the META-INF/git.properties files in JARs? |
| Comment by Stephen Kitt [ 03/Apr/18 ] |
|
Looking at our own downloads, I see the following (taken from Genius’ alivenessmonitor-impl-protocols-0.4.0.jar): #Generated by Git-Commit-Id-Plugin #Tue Mar 20 23:57:39 UTC 2018 git.build.user.email= git.build.host=prd-centos7-autorelease-4c-16g-196762.vexxhost.net git.dirty=true git.remote.origin.url=git\://devvexx.opendaylight.org/mirror/genius git.closest.tag.name=release/carbon-sr3 git.commit.id.describe-short=021764e-dirty git.commit.user.email=jenkins-releng@opendaylight.org git.commit.time=20.03.2018 @ 18\:30\:56 UTC git.commit.message.full=Release Oxygen git.build.version=0.4.0 git.commit.message.short=Release Oxygen git.commit.id.abbrev=021764e git.branch=origin/stable/oxygen git.build.user.name= git.closest.tag.commit.count=1308 git.commit.id.describe=021764e-dirty git.commit.id=021764ef7393c9387b2f5a05a14ca07859171e7f git.tags= git.build.time=20.03.2018 @ 23\:57\:39 UTC git.commit.user.name=jenkins-releng So the closest tag name is useless (which makes sense, with our current process the release tag doesn’t exist when the release is built), but it should be possible to use the commit message because that will always be “Release ...”. |
| Comment by Robert Varga [ 24/Sep/21 ] |
|
Okay, so odlparent's karaf4-parent needs to understand the distribution version and it should be registering a simple JMX bean exposing the appropriate property. The content of can also be published in OSGi Service Registry and HTTP Whiteboard – hence if will be properly available in the appropriate contents. integration/distribution's pom.xml needs to only ensure correct information is supplied in that file. |