refactor: adds GCP support, refactors machine, kernel and image configuration #20
Conversation
fnerdman
force-pushed
the
machine_refactor
branch
from
ffbbbf5
to
f506b32
Compare
You can check on how we achieved this in the meta-custom-podman layer |
| #DISTRO_FEATURES:class-native = "${CVM_DISTRO_FEATURES_NATIVE} tpm2" | ||
| #DISTRO_FEATURES:class-nativesdk = "${CVM_DISTRO_FEATURES_NATIVE} tpm2" |
There was a problem hiding this comment.
instead of commenting them out, we can remove them right?
| # enable mdev/busybox for init | ||
| #POKY_INIT_MANAGER:cvm = "mdev-busybox" | ||
| DISTRO_EXTRA_RDEPENDS = "date-sync ca-certificates" | ||
| DISTRO_EXTRA_RDEPENDS:append = '${@bb.utils.contains_any("IMAGE_FEATURES", [ "debug-tweaks" ], " dropbear", "",d)}' |
There was a problem hiding this comment.
Maybe we should consider making the dropbear (ssh access) not tightly coupled with debug-tweaks in the image features in case we want to have ssh access to the machine but not necessarily building it with debug tweaks.
Do you know by change what debug-tweaks add to the image when adding it to the IMAGE_FEAUTRES?
I mean beside giving root access without password? It probably sets the image in debugging state and add some debugging info and symbols to the image, which in practice would have "some" impact on the performance.
There was a problem hiding this comment.
instead of copying these file and the recipe of the linux yocto tiny version 6_10, can't we just use them from the meta-openembedded-core they are coming from instead ?
https://git.openembedded.org/openembedded-core/commit/?id=0b47b5900df9b808a7fe47b8c5054164b579ec00
I mean, we could add the layer and use that recipe directly, right?
There was a problem hiding this comment.
Yes, the best way would be to upgrade to poky 5.1, which includes this 6.10 kernel recipe.
Upgrading to 5.1 means we're leaving the LTS branch, so this is something we should consider and discuss.
IMO we have so many dependencies having close dependencies to upstream (i.e. reth usually depends on latest rust) that we can't afford to stay put on yocto LTS. But it will mean there's going to be more integration work moving yocto versions from time to time.
This PR adds support for creating GCP VM images.
The previous setup defined 2 machines (
tdxandsev-snp) plus one image (cvm-image-azure)Over time a lot of things have been added, such that a lot of features had been added without feature flag, even though they're not needed, or added behind the wrong feature flag.
This refactor aims to resolve most of these issues by creating a clear machine, kernel and image configuration.
Machines created:
[ "tdx-gcp", "tdx-qemu", "tdx-azure", "sev-snp-azure" ]The machine configurations are simple and heavily lend from common include files, i.e. tdx-guest.inc
The cvm-image-azure was removed and replaced by .bbappending the default "core-image-minimal" and "core-image-tiny-initramfs"
Most of the kernel configuration was moved into the specific machine or distro configuration, creating a lean kernel config.
Debug tweaks are now again enabled by adding "debug-tweaks" to the EXTRA_IMAGE_FEATURES env var. this will automatically pick up the dropbear dependency.
This refactor will break stuff in other layers depending on this layer. As a next step, the goal is to refactor these layers as well and make them more conformant with yocto design principles as well.
What I haven't achieved is hide recipe based kernel configuration behind recipes, i.e. disk-encryption.scc should only be added to the kernel if disk-encryption is added as part of the image.