Open bpradipt opened 1 year ago
So I might be wrong, but my understanding from a quick scan is that skopeo and umoci are built on the 'dev machine' to pull down the pause image, but in the pause image target they aren't built into the peer pod VM's file directory and therefore the image as it shouldn't add this target:
$(SKOPEO): $(SKOPEO_SRC)/bin/skopeo
install -D --compare "$(SKOPEO_SRC)/bin/skopeo" "$@"
to the binary step, so I'm totally fine with skopeo and umoci used for dev (and that's the case in CoCo for adding the pause image to the guest image too.
It just means that I need to be more careful in https://github.com/confidential-containers/cloud-api-adaptor/issues/164 to not remove skopeo and umoci from being built, but just from being added to the binary list as happens in:
ifdef USE_SKOPEO
BINARIES += $(SKOPEO) $(UMOCI)
endif
If I'm correct then I think this issue can be closed as it's probably not worth the effort to get image-rs running standalone during the dev build at this point.
I have to verify if we really need the pause image embedded in the peer pods case when using unmodified containerd and crio. If it's optional then I would add pause to the optional list as well and reduce the build time.
Skopeo and umoci are now only required for embedding the pause image, and are not included in the pod VM image.
When I implemented the support of embedding the pause image, kata-agent failed with an error when no pause image is available in the pod VM image. There was no option to disable it. https://github.com/confidential-containers/cloud-api-adaptor/issues/196#issuecomment-1241524111
The default set of binaries to be included in the podvm image includes the pause image - https://github.com/confidential-containers/cloud-api-adaptor/blob/staging/podvm/Makefile.inc#L45
And that has a dependency on skopeo - https://github.com/confidential-containers/cloud-api-adaptor/blob/staging/podvm/Makefile.inc#L118
I think this needs to be de-coupled to completely switch to image-rs
cc @stevenhorsman @snir911