-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad Docker API call if task contains containerImage
that contains tag
#175
Comments
Calling POST /v1.40/images/create?fromImage=python&tag=3.12.5 HTTP/1.1 |
Trivial flow to reproduce issue: id: TRIVIAL_DOCKER
namespace: test
description: Trivial flow to check Docker connectivity
tasks:
- id: trivial_python
type: io.kestra.plugin.scripts.python.Script
#containerImage: ghcr.io/kestra-io/kestrapy
script: print('Hello Kestra') Uncommenting the line results in successful execution. |
Behavior unchanged in the newly released 0.18.5. |
I'm not able to reproduce with Docker based configuration - so probably related to Podman indeed. |
From the API documentation (emphasis mine):
So a call like It seems like the safest thing a client can do is never put a tag in |
tried on 0.18.6 and on 0.19 (develop) id: TRIVIAL_DOCKER
|
@smunteankestra Did you try this with Podman? Docker accepts the API call and just drops the tag in I have not tried 0.18.6 yet. |
First, my team and I love Kestra, and we are grateful for all the work you've put into this project! Unfortunately, we've run into the exact same issues when using podman. I think the culprit might be the general use of docker-java/exemplarily in: https://github.com/kestra-io/kestra/blob/develop/script/src/main/java/io/kestra/plugin/scripts/runner/docker/Docker.java#L737 Internally, the PullImageCmd parameter from docker-java is called "repository" and its name already suggests to not use the fully qualified image name (including tags). Otherwise, the builder method withTag would as well be redundant. Wouldn't it? The Docker API calls are translated accordingly as already stated in #175 (comment) by @vlk-charles. The following sample code works for me with Docker and Podman: PullImageCmd pull = dockerClient.pullImageCmd("hello-world");
pull
.withTag("linux")
.exec(new PullImageResultCallback())
.awaitCompletion(); where PullImageCmd pull = dockerClient.pullImageCmd("hello-world:linux");
pull
.withTag("linux")
.exec(new PullImageResultCallback())
.awaitCompletion(); fails for the latter. As I'm new to and not entirely familiar with the Kestra source code, your thoughts on this matter would be highly appreciated! |
@smunteankestra seems important to the community so let's validate thoroughly and coordinate next steps with @Ben8t 👍 |
Describe the issue
When the
containerImage
property of a task contains a value that contains a tag (specified after:
), the generated API call to the Docker (or in our case Podman) daemon contains something like the following:Notice that the tag is supplied in two places, once in the image name itself (
fromImage
) and once in thetag
parameter. I assume Docker proper handles this more gracefully, otherwise this would have never made it into a stable Kestra release. The Podman daemon however normalizes this toghcr.io/kestra-io/kestrapy:latest:latest
and fails with "invalid reference format". This is logged by the Podman daemon:No further communication between Kestra and the daemon occurs and Kestra fails the task execution. The log in Kestra is not very helpful and only mentions a "broken pipe" in the Docker client:
This can be worked around by explicitly including
containerImage
without a tag such asghcr.io/kestra-io/kestrapy
. A non-latest
tag cannot be used however.This was discovered because the default value changed from a simple
python
toghcr.io/kestra-io/kestrapy:latest
(commit 88b7352).Note that if a tag other than
latest
is provided, it gets reflected in both places in the call:Environment
docker.io/kestra/kestra:v0.18.4
)The text was updated successfully, but these errors were encountered: