Closed cboylan closed 3 years ago
Thanks for your report. Yes, containers/image uses the same syntax, and we’d prefer not to diverge; there are various corner cases / ambiguities (and, sadly, way too many manual parsers) already.
I think that using an IPv6 address is a perfectly valid use-case, fully supported by URI spec. The only trick here is that we would need to normalize it before using it.
I've had some time to think about this and wonder if the solution may be to accept two different location input formats. The first would be the existing legacy docker format. Then add support for http urls so that I can do https://[2607:ff68:100:54:f816:3eff:fef2:fc69]:5000/zuul/nodepool:latest
.
Or maybe https is too generic and the protocol identifier should be more specific but that would be the general idea. Essentially keep the docker protocol but with a new different protocol specifier that allows for parsing with ipv6 address literals.
Note also that the the containers-storage:
transport uses a leading […]
syntax for graph driver options, so just allowing IPv6 address literals without changing the mechanism “pulls” map remote registry references to local image names would break.
It’s certainly not something that’s impossible to solve, but any design for changing the accepted syntax of docker/distribution references must take this situation into account.
We believe this is too complicated a change and too risky. Since this can easily be worked around by using names rather then address, I am going to close.
When a local registry is used, it has no name but an address:
docker run -d --restart=always --name registry \
-e REGISTRY_STORAGE_DELETE_ENABLED=true \
-e REGISTRY_HTTP_ADDR=:80 registry:2
# Get the address to the registry;
docker inspect registry | jq -r .[0].NetworkSettings.GlobalIPv6Address
fd00:8000::242:ac11:2
Running a command like:
We get:
Ideally we would be able to use properly escaped ipv6 address literals with a port specified and still have skopeo function.
Chances are this is related to https://github.com/docker/distribution/pull/2899 and its related bug as I'm guessing skopeo pulls in that set of regexes to validate the url. Unfortunately that means that while docker is broken so is skopeo. I'm hoping that my PR there will end up in docker being fixed, but am also wondering if it is possible for skopeo to handle this properly even if docker doesn't?