Bug #15516: arvados-api-server and arvados-workbench packages dependent on arvados-server - Arvados

Bug #15516

arvados-api-server and arvados-workbench packages dependent on arvados-server

Added by Peter Amstutz over 2 years ago. Updated almost 2 years ago.

Status:

Resolved

Priority:

Normal

Assigned To:

Ward Vandewege

Category:

Target version:

2019-08-14 Sprint

Start date:

08/13/2019

Due date:

% Done:

100%

Estimated time:

(Total: 0.00 h)

Story points:

Release:

Arvados 2.0 - Early 2020

Release relationship:

Auto

Description

arvados-api-server and arvados-workbench both have a hard dependency on arvados-server, which they use to read the new arvados config file. When installing or upgrading, arvados-server must be installed or upgraded before arvados-api-server post-install or service startup scripts are run. Base on the pattern of breakage on the dev clusters, this doesn't seem to be happening.

Subtasks

Associated revisions

Revision 4031e38a
Added by Ward Vandewege over 2 years ago

Merge branch '15516-fix-arvados-server-dependencies'

closes #15516

Arvados-DCO-1.1-Signed-off-by: Ward Vandewege <wvandewege@veritasgenetics.com>

History

#1 Updated by Ward Vandewege over 2 years ago

Project changed from OPS to Arvados
Status changed from New to In Progress
Assigned To set to Ward Vandewege

Ready for review @ 2522f92cc25e55e57a31af7a59ebdbb066743445 on branch 15516-fix-arvados-server-dependencies

#2 Updated by Ward Vandewege over 2 years ago

Target version set to 2019-08-14 Sprint

#3 Updated by Ward Vandewege over 2 years ago

Removed unnecessary --force-test call in build/run-build-test-packages-one-target.sh, pushed updated d823e6afbd6a2287469da909f95976da79692e72

#4 Updated by Nico César over 2 years ago

currently running https://ci.curoverse.com/job/build-packages-ubuntu1604/1357/console

#5 Updated by Nico César over 2 years ago

I see:
00:10:31.428 Error: /tmp/tmp.MuRDh1DKom/bin/arvados-client=/usr/bin/arvados-client: Unable to figure out package name from fpm results:
00:10:31.428
00:10:31.429 {:timestamp=>"2019-08-12T17:54:53.807627+0000", :message=>"Invalid package configuration: Cannot package the path '/tmp/tmp.MuRDh1DKom/bin/arvados-client', does it exist?", :level=>:error}

#6 Updated by Ward Vandewege over 2 years ago

Nico César wrote:

I see:
00:10:31.428 Error: /tmp/tmp.MuRDh1DKom/bin/arvados-client=/usr/bin/arvados-client: Unable to figure out package name from fpm results:
00:10:31.428
00:10:31.429 {:timestamp=>"2019-08-12T17:54:53.807627+0000", :message=>"Invalid package configuration: Cannot package the path '/tmp/tmp.MuRDh1DKom/bin/arvados-client', does it exist?", :level=>:error}

That was caused by a genuine bug in the new code. The govendor call in calculate_go_package_version() generates STDOUT when it is downloading data (but not when it doesn't have to do anything), and that output was returned with the result of calculate_go_package_version(). Meh, bash, yuck, functions returning data via stdout...

I've switched calculate_go_package_version() to take a variable name as part of its command line, and then set that variable to the output from the function. This uses a bash 4.3+ feature called namerefs. This way, any stdout generated in calculate_go_package_version() won't corrupt the value it returns anymore, which avoids future problems of this type. I've given the get_complete_package_name() function the same treatment.

Fix pushed in 366a2efdd0ac4630f4381f3b47d70ef155ed2df4