-
-
Notifications
You must be signed in to change notification settings - Fork 466
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
[BUG] Image imports failing #1072
Comments
Any update on this? we are building a tool based on k3d, we meet this problems too. And BTW, is there any way around to import image in arm64 ? |
Help |
I have the same problem with a mac M1 pro, any updates ? |
Not sure if related, but we sporadically get this in our Github actions workflows with [email protected].
I'd prefer a os.Exit in that case, but it doesn't happen too often. |
I'm seeing this as well.
And then when I try to run the app, it sees the images is there, but then a kubelet error:
The image does not have that sha in the registry. k3d must have changed it??? |
Same here, running on M1. Please consider improving UX by possibly returning error explicitly and stopping execution. Successful messages after failing conditions are misleading. Cheers! |
It seems that the image gets imported, but with a different hash. So there may have been an initial error, but it seems to have imported something in the end. Perhaps there is a tiered set of instructions to load, and the top tier may have failed. But changing the hash of the image is not acceptable.
…Sent from my iPhone
On Nov 24, 2022, at 10:04 AM, Jakub Jarosz ***@***.***> wrote:
Same here, running on M1. Please consider improving UX by possibly returning error explicitly and stopping execution. Successful messages after failing conditions are misleading. Cheers!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
Still happening:
What's strange too is that it happens when I pull the image from a cloud registry, not when I build the same image in local. |
The absaoss/k3d-setup action does not install the latest k3d version, instead a ["default" version is used](AbsaOSS/k3d-action#45). This bumps k3d to 5.4.7, so we can get more input on the ['import images' errors](k3d-io/k3d#1072).
@iwilltry42 I'm seeing this issue on ubuntu when upgrading from k3d 5.3.0 to 5.4.1.
I'm seeing output like:
One thing that jumps out: the code in
importWithToolsNode()
that logs these failures when copying images swallows errors without returning them to the caller:k3d/pkg/client/tools.go
Lines 125 to 127 in 852df77
Compare that to this other k3d code to import images into clusters (rather than nodes) which fails if any individual image fails to import:
k3d/cmd/image/imageImport.go
Lines 75 to 86 in 7b1b416
Or even this code in the same
importWithToolsNode()
method that returns errors if any image fails to save:k3d/pkg/client/tools.go
Lines 114 to 116 in 852df77
Should
importWithToolsNode()
return an error whenever any image installations encounter an error? That would at least mean that image installation errors are reported as overall install errors: that doesn't fix the install errors themselves, but it seems more appropriate than treating them as successes.Originally posted by @CodingCanuck in #954 (comment)
The text was updated successfully, but these errors were encountered: