Current Behavior
During update, the Docker runner assumes all images come from the Docker Hub (docker.io) registry.
Despite that, Docker images from other registries still mostly work unless a tag-less image name is given or a build-* tag is given. Either case triggers a different code path:
|
if not tag or is_build_tag(tag): |
|
build_tags = sorted(filter(is_build_tag, tags(repository))) |
|
|
|
if build_tags: |
|
return repository + ":" + build_tags[-1] |
|
|
|
return image_name |
and nextstrain.cli.runner.docker._update ends up trying to enumerate the build-* tags of the non-docker.io image by making requests to the docker.io registry. This understandably results in a 400 Bad Request from the latter. Oops.
Originally discovered in nextstrain/docker-base#148 (comment).
Expected behavior
Ideally the update code would fetch the tags available from the correct registry, but this is often complicated by forbidding of anonymous access and other authz issues.
As a temporary workaround, perhaps we could simply not support updates from other registries for now. This would involve detecting the registry correctly and excluding those which aren't docker.io from the build-* tag handling.
How to reproduce
The manylinux image here is used only as an example. Any image from a registry other than docker.io will have the same issue.
$ NEXTSTRAIN_HOME=$(mktemp -dt) NEXTSTRAIN_DOCKER_IMAGE=quay.io/pypa/manylinux_2_28_x86_64 nextstrain setup docker
Setting up docker…
Traceback (most recent call last):
File "/home/tom/nextstrain/cli/.venv/bin/nextstrain", line 8, in <module>
sys.exit(main())
File "/home/tom/nextstrain/cli/nextstrain/cli/__main__.py", line 19, in main
return cli.run( argv[1:] )
File "/home/tom/nextstrain/cli/nextstrain/cli/__init__.py", line 36, in run
return opts.__command__.run(opts)
File "/home/tom/nextstrain/cli/nextstrain/cli/console.py", line 36, in decorated
return f(*args, **kwargs)
File "/home/tom/nextstrain/cli/nextstrain/cli/command/setup.py", line 59, in run
setup_ok = opts.runner.setup(dry_run = opts.dry_run, force = opts.force)
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 166, in setup
if not setup_image(dry_run, force):
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 186, in setup_image
update_ok = _update(dry_run)
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 308, in _update
latest_image = latest_build_image(current_image)
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 436, in latest_build_image
build_tags = sorted(filter(is_build_tag, tags(repository)))
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 428, in tags
"Authorization": "Bearer %s" % auth_token(repository),
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 423, in auth_token
return GET(url, params = params).json().get("token")
File "/home/tom/nextstrain/cli/nextstrain/cli/runner/docker.py", line 415, in GET
response.raise_for_status()
File "/home/tom/nextstrain/cli/.venv/lib/python3.8/site-packages/requests/models.py", line 1021, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://auth.docker.io/token?scope=repository%3Aquay.io%2Fpypa%2Fmanylinux_2_28_x86_64%3Apull&service=registry.docker.io
Current Behavior
During
update, the Docker runner assumes all images come from the Docker Hub (docker.io) registry.Despite that, Docker images from other registries still mostly work unless a tag-less image name is given or a
build-*tag is given. Either case triggers a different code path:cli/nextstrain/cli/runner/docker.py
Lines 434 to 440 in babc215
and
nextstrain.cli.runner.docker._updateends up trying to enumerate thebuild-*tags of the non-docker.ioimage by making requests to thedocker.ioregistry. This understandably results in a 400 Bad Request from the latter. Oops.Originally discovered in nextstrain/docker-base#148 (comment).
Expected behavior
Ideally the update code would fetch the tags available from the correct registry, but this is often complicated by forbidding of anonymous access and other authz issues.
As a temporary workaround, perhaps we could simply not support updates from other registries for now. This would involve detecting the registry correctly and excluding those which aren't
docker.iofrom thebuild-*tag handling.How to reproduce
The
manylinuximage here is used only as an example. Any image from a registry other thandocker.iowill have the same issue.