Arvados

Lucas suggested testing directly on the Rails API. The failure and pass situation are exactly the same:

# export ARVADOS_API_TOKEN=changeme_system_root_token

# curl -q --insecure \
  -H "Authorization: OAuth2 $ARVADOS_API_TOKEN" \
  http://127.0.0.2:8004/arvados/v1/collections

{"errors":["Not logged in (req-68wahompepcj7rqe551b)"],"error_token":"1605795377+19e9c858"}

# export ARVADOS_API_TOKEN=v2/arva2-gj3su-sxldaz37f8h28un/szqnavhypc5wit9k3xrjhlen3ewj504w3f4heb3qc50c6qh6w

# curl -q --insecure \
  -H "Authorization: OAuth2 $ARVADOS_API_TOKEN" \
  http://127.0.0.2:8004/arvados/v1/collections

{"kind":"arvados#collectionList","etag":"","self_link":"","offset":0,"limit":100,"items":[{"href":"/collections/arva2-4zz18-8cykjg5gyxfiv4f","kind":"arvados#collection","etag":"pspmj2vb9voo69q6qy87k7wt","uuid":"arva2-4zz18-8cykjg5gyxfiv4f","owner_uuid":"arva2-tpzed-000000000000000","created_at":"2020-11-19T10:59:40.534588000Z","modified_by_client_uuid":null,"modified_by_user_uuid":"arva2-tpzed-000000000000000","modified_at":"2020-11-19T10:59:40.534969000Z","name":"empty collection","description":null,"properties":{},"portable_data_hash":"d41d8cd98f00b204e9800998ecf8427e+0","replication_desired":null,"replication_confirmed":null,"replication_confirmed_at":null,"storage_classes_desired":["default"],"storage_classes_confirmed":[],"storage_classes_confirmed_at":null,"delete_at":null,"trash_at":null,"is_trashed":false,"version":1,"current_version_uuid":"arva2-4zz18-8cykjg5gyxfiv4f","preserve_version":false,"file_count":0,"file_size_total":0}],"items_available":1}

For the record:

The problem is that the (now old) auth header validation regexp being used on railsAPI was /(OAuth2|Bearer) ([-\/a-zA-Z0-9]+)/, that doesn't include the underscore character, and from that match, the 2nd group was being used to get the token. This means that the token got truncated from the first underscore onwards.

Current code from #16669 already fixes that, but the story isn't currently fully resolved yet so it wasn't included on the latest release.

• When trying the vagrant flavor, the cwl run-test.sh tries to create an ‘admin’ user that already exists, so it fails. I think this is because I logged in as ‘admin’ on workbench before running the cwl test script. I suppose the script could create a user with a random name?
• The Vagrant file changed the vm hostname to “vagrant.local” from “arva2.arv.local”, but instructions on the documentation haven’t changed, I’m not sure if that would produce problems but wanted to mention it just in case.
• If the CWL test files are just a copy from the some on sdk/cwl/, I think it would be convenient to symlink them so they get updated with the originals.
• I’ve re-created the VM without attempting to use the “admin” user on workbench, and test passed OK.

Lucas Di Pentima wrote:

• When trying the vagrant flavor, the cwl run-test.sh tries to create an ‘admin’ user that already exists, so it fails. I think this is because I logged in as ‘admin’ on workbench before running the cwl test script. I suppose the script could create a user with a random name?

At first I did that, however, as Arvados is being installed with "first user that logs in is the cluster's admin" option, if you run the test script before login into the UI, the 'admin' user won't be granted admin powers anymore :D

It's kind of a chicken/egg issue. Probably I can try one of these 2 options to the script:

• add another user, make sure 'admin' is 'admin'
• add 'admin', make sure it does not fail if exists (probably the same with some of the other steps)

• The Vagrant file changed the vm hostname to “vagrant.local” from “arva2.arv.local”, but instructions on the documentation haven’t changed, I’m not sure if that would produce problems but wanted to mention it just in case.

Yes, I needed to do that because Vagrant sets some FQDNs in /etc/hosts and using 'arva2.arv.local' as the Vagrant hostname adds it to the file with IP 127.x.x.x which confuses the docker containers resolver.

That's why I also changed all the 127.0.0.2 entries to <role>.internal, so it's clear everywhere what's expected.

The change should not be a problem for the cluster.

• If the CWL test files are just a copy from the some on sdk/cwl/, I think it would be convenient to symlink them so they get updated with the originals.

Not sure, Nico César gave them to me. I'll check and do as you suggest if that's the case.

• I’ve re-created the VM without attempting to use the “admin” user on workbench, and test passed OK.

Great. I'll merge and push the Saltstack PR and work on the changes you suggested. Thanks

• Merged the salt formula
• Fixed the test script to:
  • add the user defined in the provision.sh script (defaults to admin)
  • verify if the resources already exist (user, token, project), so the script can be run repeatedly without errors.
• the CWL code is not part of the any previous CWL already available in the repo, so I left it as is.

commit e9eaf87ec@arvados, branch 17150-system-root-token

I tried starting a new vagrant instance and this happened:

• Error message at the end of creating a new vagrant instance: arvados: usermod: group 'docker' does not exist (not sure if it was happening before)
• Error when running run-tests script:

Arvados project uuid is 'arva2-j7d0g-u2mosxf9jtnom17'
Uploading arvados/jobs' docker image to the project
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/images/json: dial unix /var/run/docker.sock: connect: permission denied
Traceback (most recent call last):
  File "/usr/share/python3/dist/python3-arvados-python-client/lib/python3.7/site-packages/arvados/commands/keepdocker.py", line 136, in docker_images
    next(list_output)  # Ignore the header line
StopIteration

Reloading the instance didn't fixed the problem

There was a change in a dependency (docker formula was upgraded). Fixed it, commit 11c4d6f00@arvados

LGTM, thanks!