-
Notifications
You must be signed in to change notification settings - Fork 61
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
ImportImageFailed: Failed to import 2 image(s) #1742
Comments
@rcerven PTAL |
I didn't find logs in those 2 mentioned tasks, but I've found them in : Firefox flatpak: https://koji.fedoraproject.org/koji/taskinfo?taskID=80953059 First of all, you are using 2 years old atomic-reactor and osbs-client :( From logs I can see that images are pushed to : candidate-registry.fedoraproject.org because you have have different source_registry and registries in reactor-config-map what is relation between those registries? since other builds are passing my guess is that you have some kind of synchronization between those 2 registries so the import is failing because image wasn't synced yet to 'registry.fedoraproject.org' registry from 'candidate-registry.fedoraproject.org' registry |
Thanks a lot for your investigation. I'm not an administrator of the infrastructure so I cannot update the packages and my knowledge of the pipeline is limited to a user perspective. I'm just trying to find someone who can fix it because I'm not able to build container images for weeks now. To answer your question. |
so from that firefox flatpak build, I can see that stable and latest tags are actually there: https://registry.fedoraproject.org/v2/firefox/tags/list but openshift still reports 404, so openshift is having issue with checking that registry you can verify if imagestream tag import is working with oc image-import command, which is exactly what is osbs doing via API |
It indeed is erroring:
I've asked the folks who know more about this setup to look too, they should hopefully see this tomorrow eu time. |
As @frenzymadness mentioned, OSBS only pushes the images to our candidate-registry, then the image maintainer creates an Bodhi update which once pushed to "stable" copies the container image from the candidate-registry.fp.o to registry.fp.o. I can't remember why we use registry.fp.o in the imagestream, I guess this is because it is where all "stable" images eventually ends up. But maybe it would be better to actually have OSBS look only at the candidate-registry ? |
well osbs uses source_registry for the imagestream and also as default registry if you omit registry in FROM pullspec imagestreams are created for autorebuilds, if you aren't using that feature it doesn't really matter |
Yeah we don't use the autorebuilds, since the fedora base image is not built by OSBS (we don't have all the arch available for that) |
So it looks like we had to disable the It looks like the orchestrator_customize was ignored, not sure why tho |
that seems like bug, that it uses worker_customize I remember that support customize configs was dropped at some point but you can always just remove it from orchestrator_inner:6.json but anyway that is just workaround for your infra issue, where ocp can't connect to that registry |
Hello.
I have a problem building my python3 image in Koji, see these tasks for example:
The builds itself are fine but the orchestrator is not:
Reported on fedora-infra as well two weeks ago: https://pagure.io/fedora-infrastructure/issue/10437
The text was updated successfully, but these errors were encountered: