Bug #20757
closed
arvados-client binary doesn't seem to sometimes pick up ~/.config/arvados/settings.conf
Added by Lucas Di Pentima about 1 year ago.
Updated 12 months ago.
Release relationship:
Auto
Description
While using a shell node:
shell login: lucasdipentima2
Password: (sent authentication token)
lucasdipentima2@shell:~$ arvados-client user current
{
"can_manage":true,
"can_write":true,
"created_at":"2022-02-18T19:38:28.442053000Z",
...
"username":"lucasdipentima2",
"uuid":"jutro-tpzed-parp8dft47kpewf",
"writable_by":[
"pirca-tpzed-000000000000000",
"jutro-tpzed-parp8dft47kpewf",
"pirca-j7d0g-000000000000000"
]
}
lucasdipentima2@shell:~$ arvados-client shell pirca-xvhdp-bmb06zf8s87ekso
fatal: ARVADOS_API_HOST and ARVADOS_API_TOKEN environment variables are not set
OTOH, arvados-client diagnostics
works fine, so maybe there're just some code paths that aren't using the credentials from settings.conf
.
- Description updated (diff)
- Subject changed from arvados-client binary doesn't seem to sometimes pick up ~/.config/arvados/settings.ini to arvados-client binary doesn't seem to sometimes pick up ~/.config/arvados/settings.conf
- Target version changed from Future to Development 2023-08-30
- Assigned To set to Tom Clegg
- Subject changed from arvados-client binary doesn't seem to sometimes pick up ~/.config/arvados/settings.conf to arvados-client binary doesn't seem to sometimes pick up ~/.config/arvados/settings.conf
- Status changed from New to In Progress
Tom Clegg wrote in #note-5:
20757-ctr-shell-settings @ 70f0fb817d242a804a9e1647b526348742416b52 -- developer-run-tests: #3796 ![](https://ci.arvados.org/buildStatus/icon?job=developer-run-tests&build=3796)
This is good to merge, my two low-priority cents:
In my opinion, reusing the two arvados-client shell
invocations in TestShellGateway
to test the two different connection methods dilutes the value of the test, because now you potentially have to do more work to diagnose a test failure: did it fail because it didn't read the connection parameters properly, or because something went wrong post-connection? I think the tests could provide more useful feedback if these different tests were separated out. But to be sure, this could be said about a lot of our test suite.
A comment about the build step to explain what you wrote here might be nice for future readers.
Thanks.
Good points.
Added a comment about the "go build" step.
Split test into separate funcs and put the "go build" bin in a SetUpSuite, so now instead of
PASS: container_gateway_test.go:48: ClientSuite.TestShellGateway 5.326s
PASS: container_gateway_test.go:36: ClientSuite.TestShellGatewayNotAvailable 0.742s
we have
PASS: container_gateway_test.go:44: shellSuite.SetUpSuite 2.937s
PASS: container_gateway_test.go:94: shellSuite.TestShellGatewayNotAvailable 0.057s
PASS: container_gateway_test.go:154: shellSuite.TestShellGatewayPortForwarding 0.212s
PASS: container_gateway_test.go:106: shellSuite.TestShellGatewayUsingEnvVars 0.164s
PASS: container_gateway_test.go:109: shellSuite.TestShellGatewayUsingSettingsConf 0.181s
PASS: container_gateway_test.go:90: shellSuite.TearDownSuite 0.875s
20757-ctr-shell-settings @ d69e82869d237a5665142cdfe1d783e8fb49d23d -- developer-run-tests: #3803 ![](https://ci.arvados.org/buildStatus/icon?job=developer-run-tests&build=3803)
- Status changed from In Progress to Resolved
Also available in: Atom
PDF