Bug #13543

[Workbench][API Server] Version reporting broken

Added by Tom Morris over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-
Release:
Release relationship:
Auto

Description

On cloud.curoverse.com, both the workbench version and API server version are being reported as the empty string

History

#1 Updated by Tom Morris over 2 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"

#2 Updated by Tom Morris over 2 years ago

  • Target version changed from To Be Groomed to 2018-07-03 Sprint

#3 Updated by Tom Clegg over 2 years ago

  • Assigned To set to Tom Clegg

#4 Updated by Tom Clegg over 2 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 ".)

#5 Updated by Nico C├ęsar over 2 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 version variant 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?

#6 Updated by Tom Clegg over 2 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.

#7 Updated by Tom Clegg over 2 years ago

  • Status changed from In Progress to Feedback

#8 Updated by Tom Clegg over 2 years ago

  • Status changed from Feedback to Resolved

Checked 4xphq, c97qk, qr1hi, su92l, 9tee4 -- all fixed.

#9 Updated by Tom Morris over 2 years ago

  • Release set to 13

Also available in: Atom PDF