This message was deleted.
# harvester
a
This message was deleted.
πŸ‘ 1
g
this image is an image created at runtime and only contains internal artefacts and is packaged within the iso
during the install process, we copy images and extract them for rke2
i have seen in some scenarios when using iso, the extract can fail silently, likely because image extraction took over 30 mins, in which case you can see node boot and complain about the missing image
best option would be to retry iso install or try a PXE based install, which downloads iso locally onto node, and runs into less issues during the image extract
i hope this helps
f
Thanks for the explanations, we will retry the install. May I ask why this image is not available publicly in a registry ? What is the benefit of only packaging it in the iso and not give access to it by registry ?
We were able to finish the install by extracting the
harvester-cluster-repo
image manually from the iso and importing it with docker on the machine we installed Harvester on. @great-bear-19718 if you can provide an explanation about why the image is not in a public registry I'd be glad.
g
its only use is to hold individual helm charts for some of the core components already published as separate releases
f
But why not uploading it to a public registry (like docker.io or registry.suse.com) ? As it could prevent installation failures ? Is it vendor proprietary or something like that ?
g
one it will not work in air-gapped env, and issue is to figure out why extraction is failing silently
k
issue is to figure out why extraction is failing silently
You are correct πŸ™‚: we can create an issue out of this Slack conversation if you want.
one it will not work in air-gapped env
The question is not wether you should embed or not the container images in the harvester ISO: of course you should embed all the needed container images in the Harvester ISO file. The question is to allow people to audit and review the container images that are embedded in the ISO. This is exactly what is done on the k3s github: there are files called "k3s-airgap-images-amd64.tar*", which anyone can review and audit and then use in their own k3s airgap installation 😊. The image "*harvester-cluster-repo*" is nowhere to be found, exept in the harvester ISO. We do not know where and how the ISO is fabricated. We do not know where and how the container image is fabricated. Does this mean it is a rancher vendor/proprietary container image, and not an open source container image? Are there other container images that follows the same behaviour (for RKE2)? What is the licensing behind Harvester?
g
if you have docker on x86 just run
make build-iso
k
[edit link] Thank you, this helps πŸ™‚. Can you confirm that this image
rancher/harvester-cluster-repo:v1.1.1
corresponds to this Containerfile? β€’ https://github.com/harvester/harvester-installer/blob/c75e7922ac789c8bd725b894395219806da0e689/package/harvester-repo/Dockerfile β€’ https://github.com/harvester/harvester-installer/commit/9d237eb9caa816b69b75c7d55d60fc0f6683a246
Thanks to your help, I also discover the rancher tool "wharfie", which seems to have the same sort of features than "`crane export`" or "`podman/docker save`" or "`skopeo copy`". https://github.com/rancher/wharfie