Feature #4383
closed[Docker] upload all docker containers to docker repository, and then add a script to download and run them in one go
Updated by Ward Vandewege over 9 years ago
- Subject changed from upload all docker containers to docker repository, and then add a script to download and run them in one go to [Docker] upload all docker containers to docker repository, and then add a script to download and run them in one go
Updated by Ward Vandewege over 9 years ago
- Target version set to 2014-11-19 sprint
Updated by Ward Vandewege over 9 years ago
- Status changed from New to In Progress
Updated by Tom Clegg over 9 years ago
At 611a332...
A more complete set of tests could be worthwhile to verify the interaction between the two auto flags:[[false, 'foo@example.com', true, false], [false, 'bar@example.com', false, true], [true, 'foo@example.com', true, false], [true, 'bar@example.com', true, true], [false, false, false, false], [true, false, true, false] ].each do |auto_admin_first_user_config, auto_admin_user_config, foo_should_be_admin, bar_should_be_admin| # In each case, 'foo' logs in first, then 'bar', then someone else. test "auto admin with auto_admin_first=#{auto_admin_first_user_config} auto_admin=#{auto_admin_user_config}" do ... # foo arrives assert_equal foo_should_be_admin, foo_user.is_admin ... # bar arrives assert_equal foo_should_be_admin, foo_user.is_admin assert_equal bar_should_be_admin, bar_user.is_admin ... # baz arrives assert !baz.is_admin end end
- Even if you don't go that far, at least the last case -- ensuring that the first user is not automatically made admin when the flag is false -- seems like a worthwhile thing to protect with a test.
curl|bash
method and it seems to have brought up the containers properly, but writing settings.conf failed (I assume) because arvdock assumes cwd is {arvados-tree}/docker:
***************************************************************** You can access the Arvados workbench at http://localhost:9899 ***************************************************************** cat: api/generated/superuser_token: No such file or directory To stop the containers, run ./arvdock stop tom@arvados:~$ cat ~/.config/arvados/settings.conf ARVADOS_API_HOST=172.17.0.105 ARVADOS_API_HOST_INSECURE=yes ARVADOS_API_TOKEN=
I thought it was a bit odd that it left an arvdock program in whatever my cwd happened to be when I ran curl|bash
. Perhaps this should go in a more predictable place, like $HOME/bin
or /tmp
-- or perhaps the "quick installation" instructions should tell me to cd ~/bin
(or /tmp
) before running curl|bash
?
Updated by Ward Vandewege over 9 years ago
Thanks for the review - I've added the extra tests (that thought had crossed my mind, too). I've also stopped arvdock from trying to install ~/.config/arvados/settings.conf if it doesn't have a token to put in there.
As for arvdock - I've added a more explicit note to the install instructions that it is being stored in the current working directory.
Updated by Tom Clegg over 9 years ago
At 7ff4966
LGTM.
This shouldn't hold up the merge, but one more thing worth noting in the docs: The "quick install" method currently assumes you're doing this on your workstation -- or, more precisely, it assumes your web browser and arvdock run on the same host. (If you run Docker in a VM somewhere, you'll be able to connect to Workbench, but the "log in" button (and websockets) won't work out-of-the-box because API server thinks it's at 172.16.*.* and that routing probably isn't set up on your network.)
Updated by Ward Vandewege over 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Applied in changeset arvados|commit:5acdc268c662f452de81d2d00766a879c73f8c08.