CCv0: Modify Kata CI to generate and test a tarball with the artefacts required

[stevenhorsman]

I chatted with @fidencio about the confidential-containers first release CI/CD requirements and this was one of the items that we felt is required. We are also eager for feedback from @wainersm once he get back from the beach!

Description

At the moment lots of the components in the Kata CI pipeline are built and then installed with code in the tests repo e.g. install_qemu.sh. Instead we could use the kata-deploy script to build a tarball and update the CI process to install and test the binaries in that tarball. As well as reducing duplication of build logic it would help ensure that we aren't potentially testing a different version of these components to the version that we release. We can then use this created tarball as the payload that the co-co operator will use.

We think this will be a good change to main as well, but we can use CCv0 as the test playground for it. install_cloud_hypervisor.sh is a good example of a component that has moved in this direction already.

This work might be related to https://github.com/kata-containers/kata-containers/issues/3992 ?

Questions:

• Will we switch to build the single tarball that contains everything then extract just the components we need to install during testing, or run the static build for each component required individually?
• Where is the best place to store the build artefact that we can use it in the operator? IIRC the operator gets the payload image from quay.io?

[fidencio]

Will we switch to build the single tarball that contains everything then extract just the components we need to install during testing, or run the static build for each component required individually?

I'd say we can ensure we use the same scripts that we use as part of the release process as the first step. Later on, we can decide whether we build each component or a full tarball, as the code that we have already can do both.

Where is the best place to store the build artefact that we can use it in the operator? IIRC the operator gets the payload image from quay.io?

Quay.io is the place, as we already do with Kata Containers normal released daemonset.

[wainersm]

Hi @stevenhorsman ! While on the beach I was only concerned about CoCo-nute! :)

@fidencio told me about this issue. It always bothered me we are using different build paths for CI and kata-deploy (i.e. shipped code), so I agree 100% with your proposal.

Today I started working on that. As I am not much familiar with kata-deploy scripts, I picked the install_kata_kernel.sh first, I will send a pull request soon so we can discuss there the implementation details.

[fitzthum]

I agree that it's kind of weird that we have different codepaths for the kata tests and the operator/kata deploy, but when we talk about combining them, are we staying that we're going to upload a new payload image to quay every time we run the Kata tests? That doesn't seem optimal.