Feature #4383
closed[Docker] upload all docker containers to docker repository, and then add a script to download and run them in one go
100%
Updated by Ward Vandewege about 10 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 about 10 years ago
- Target version set to 2014-11-19 sprint
Updated by Ward Vandewege about 10 years ago
- Status changed from New to In Progress
Updated by Tom Clegg about 10 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 about 10 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 about 10 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 about 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Applied in changeset arvados|commit:5acdc268c662f452de81d2d00766a879c73f8c08.