Closed stevenhorsman closed 2 months ago
I think the kata guest components are too specific to be used in peerpods. but maybe we can use parts of it, attestation-agent will have hardware dependencies, e.g you need tdx guest attester libraries that are only available ox 86_64 naturally, otoh the peerpods TEEs (tpm, se) require openssl and are not compatible with musl.
but we can maybe build and push specific binaries in the guest-components repo (think: .../guest-components:$sha-glibc-x86_64 and .../guest-components-$sha-glibc-s390x)
I think the kata guest components are too specific to be used in peerpods. but maybe we can use parts of it, attestation-agent will have hardware dependencies, e.g you need tdx guest attester libraries that are only available ox 86_64 naturally, otoh the peerpods TEEs (tpm, se) require openssl and are not compatible with musl.
but we can maybe build and push specific binaries in the guest-components repo (think: .../guest-components:$sha-glibc-x86_64 and .../guest-components-$sha-glibc-s390x)
Yeah, I was coming to the same conclusion with this PR, hence leaving it in draft. It would be nice to remove all the rust related code from this repo, but agree that we need the different flavours built and cached and guest-components make sense as the place to do that and then the kata rootfs code can consume the variants it needs there too.
I'll close this PR for clarity - we can also re-open it later if needed. Thanks!
podvm: Pull the guest-components from cache To reduce time in the podvm build, rather than compiling the guest-components binaries each time, we can just re-use the cached version that the kata-containers CI build publishes.
Note: This adds a restriction that means we can only use versions of guest-components that have been included in a kata-containers build. I think this is okay as we want to stay in sync with them anyway
Fixes: https://github.com/confidential-containers/cloud-api-adaptor/issues/1816