Error, when pulling short-named image via docker api #16400
Comments
|
Thanks for reaching out, @fedinskiy. Any chance you can break it down to a reproducer involving podman only? Digging into the code of the reproducer will slow things down considerably. |
|
My guess is that "short names" is a red herring as short names are resolved as Docker does. There's probably some field in the JSON message that testcontainers expect? That's not needed as it's set to true by default. The short-name mode isn't required to be set to |
|
@vrothberg I saw a comment[1] in this repo, which mentions logging of socket operations. I was not able to find anything about it in the docs, but hoped you know something about this option. In that case, I will be able to make a curl version of the reproducer. Also, I believe, there are two problems:
[1] #15306 (comment) |
Thanks a lot for your help, @fedinskiy! One way to get the logs is to run
That may be the important part. I am curious to see the reproducer and compare docker's response with the one of podman.
That is surprising. |
|
I used this command for debugging purposes, to decrease the amount of logs: This is what I get from podman debug logs( |
|
So, I pruned all images and tried to run the request in question: Podman: Docker |
|
@fedinskiy can you point to the test that is failing in testcontainers? I would love to better understand what is being tested. Looking at the source code of the test may help. |
|
@vrothberg : below is a copy of steps from the testcontainer issue:
|
|
@fedinskiy I am entirely unfamiliar with testcontainers. Having a pointer to the code would speed things up considerably. I assume that one test fails that has some source code. |
|
@vrothberg That happens, because this field is null (probably due to unmarshalling of non-existing field from json object): User-facing code of the test looks like that: https://github.com/fedinskiy/reproducer/blob/reproducer/podman-nopull/src/test/java/io/quarkus/qe/AppTest.java#L18 Full java stacktrace is below: |
|
Awesome, thank you very much for the pointers! I'll be traveling this week, but will go back to the issue ASAP. |
|
@fedinskiy @vrothberg FYI, I have also recently discovered that NullPointerException in docker-java-api and I have already filed a report there: docker-java/docker-java#1998 In my case the NPE was triggered when I tried to download from a secured repository to which I had no credentials using podman. I could also provide a PR there, but they haven't responded yet to the issue and I don't want to act prematurely. |
|
It looks like this issue only affects rootless podman. If I use rootlfull podmam[1] everything works as expected [1] |
|
We can not prompt over the protocol so when using podman-remote you either need to set on one entry in the registry, which is what we do for podman-machine (docker.io) or you need to use fully qualified names. |
|
@fedinskiy, can you check whether there's a |
|
@vrothberg all my config entries are in the initial message (the last section). @rhatdan I had an impression, that option |
|
Looks like it is supposed to. |
The fact that it doesn't work rootless strongly suggests there's a config in your $HOME directory. Is that the case? |
|
The reproducer fails for me both rootless and rootful. But I have no idea what the tests do. |
|
@vrothberg it is pretty straightforwardm, and you can see it in my repo[1]. The tests just start and stop containers. Under the hood, there is also image pulling by testcontainers library. |
|
Sorry, I need a working reproducer. I am no Java developer and the provided steps in the issue don't work on Fedora 37 :( |
|
@vrothberg I am on Fedora 36, maybe that is the reason of differences. Do you receive the same error on rootless and rootfull? What kind of error? Does it go away when you pull the images? |
|
I get the following results (with and without the images): |
|
A friendly reminder that this issue had no activity for 30 days. |
|
I also reproduce this (testcontainers, exact same java exception callstack) on Apple Silicon. Podman 4.3.1. |
|
I'd love to help but I need an easier reproducer or logs. For instance, how do the REST API calls look like? |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Since we never heard back, closing this issue, reopen if you have more feedback. |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I have an application, which uses podman socket via test-containers library. When I am using this app to run containers, based on images which have non-qualified names (eg
postgres:9.6.12) and were not yet pulled to the machine, it fails with an error. When I use fully-qualified names (egdocker.io/postgres:9.6.12), or pull images in advance, it works. When the same app uses Docker API, it works for images with any names.Steps to reproduce the issue:
systemctl --user enable podman.socket --nowexport DOCKER_HOST=unix:///run/user/${UID}/podman/podman.sockgit clone [email protected]:fedinskiy/reproducer.git -b reproducer/podman-nopull && cd reproducerpodman rmi --allanddocker rmi --force $(docker images -q)mvn clean verify # failstestcontainers/ryuk:0.3.4,nginx:latestandpostgres:9.6.12mvn clean verify # succeedsdocker.io/postgres:9.6.10) is also worksDescribe the results you received:
See above
Describe the results you expected:
Podman API should be fully compatible with Docker API (https://podman.io/blogs/2020/07/01/rest-versioning.html)
Additional information you deem important (e.g. issue happens only occasionally):
Initially reported here, for test-containers library: testcontainers/testcontainers-java#5998, according to them it is docker-api error.
Output of
podman version:Output of
podman info:Package info (e.g. output of
rpm -q podmanorapt list podmanorbrew info podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: