Bug #13543
closed
[Workbench][API Server] Version reporting broken
Description
On cloud.curoverse.com, both the workbench version and API server version are being reported as the empty string
Updated by Tom Morris over 6 years ago
- Subject changed from [Workbench] Version reporting broken to [Workbench][API Server] Version reporting broken
The discovery document is returning the following version related info from https://qr1hi.arvadosapi.com/discovery/v1/apis/arvados/v1/rest
discoveryVersion: "v1",
id: "arvados:v1",
version: "v1",
revision: "20131114",
source_version: " ",
generatedAt: "2018-05-29T12:44:47+00:00"
Updated by Tom Morris over 6 years ago
- Target version changed from To Be Groomed to 2018-07-03 Sprint
Updated by Tom Clegg over 6 years ago
- Status changed from New to In Progress
qr1hi configuration (/etc/arvados/api/application.yml) has
source_version: "<%= `apt-cache policy arvados-api-server |grep Installed |cut -f2 -d: |cut -f4 -d.` %>"
This probably worked when debian package version numbers were 0.1.$timestamp.$gitcommit, but it now returns the empty string when a stable release is installed.
This line should be removed from the config. The default config (false) reads the version from $railsroot/git-commit.version, which has the correct content.
(Confirmed this fix works on 9tee4, which has a different version variant of the same problem, reporting version "20180620132525-8 ".)
Updated by Nico César over 6 years ago
Tom Clegg wrote:
qr1hi configuration (/etc/arvados/api/application.yml) has
[...]
This probably worked when debian package version numbers were
0.1.$timestamp.$gitcommit, but it now returns the empty string when a stable release is installed.This line should be removed from the config. The default config (false) reads the version from
$railsroot/git-commit.version, which has the correct content.(Confirmed this fix works on 9tee4, which has a different
versionvariant of the same problem, reporting version"20180620132525-8 ".)
Nice catch!
So should build scripts override applications.default.yml's source_version when packaging? Does it sound as a good idea?
Updated by Tom Clegg over 6 years ago
The only thing that needs to change is qr1hi, 9tee4, and probably some other clusters need to have the "source_version" line removed from their config files. That will cause them to start using the default behavior, which is correct.
Updated by Tom Clegg over 6 years ago
- Status changed from In Progress to Feedback
Updated by Tom Clegg over 6 years ago
- Status changed from Feedback to Resolved
Checked 4xphq, c97qk, qr1hi, su92l, 9tee4 -- all fixed.