Project

General

Profile

Actions

Bug #13543

closed

[Workbench][API Server] Version reporting broken

Added by Tom Morris over 4 years ago. Updated over 4 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

Actions #1

Updated by Tom Morris over 4 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"

Actions #2

Updated by Tom Morris over 4 years ago

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

Updated by Tom Clegg over 4 years ago

  • Assigned To set to Tom Clegg
Actions #4

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

Actions #5

Updated by Nico César over 4 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?

Actions #6

Updated by Tom Clegg over 4 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.

Actions #7

Updated by Tom Clegg over 4 years ago

  • Status changed from In Progress to Feedback
Actions #8

Updated by Tom Clegg over 4 years ago

  • Status changed from Feedback to Resolved

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

Actions #9

Updated by Tom Morris over 4 years ago

  • Release set to 13
Actions

Also available in: Atom PDF