luet util unpack should support overriding image platform/arch
jtcressy opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
Problem: when luet encounters a multi-arch image manifest while pulling remote OCI sources, it defaults to pulling the linux/amd64 image from the manifest because google/go-containerregistry defaults to linux/amd64 when platform is not provided as an option to remote.Image().
Further downstream, elemental-cli which uses luet's pkg/util/docker.go also runs into a problem where the pulled image is defaulted to linux/amd64 when the remote image manifest supports multiple architectures (and the user may or may not desire the same architecture).
Describe the solution you'd like
I'd like to be able to pull a specific platform/arch when unpacking a remote docker image with luet util unpack and when using DownloadAndExtractDockerImage in pkg/util/docker.go.
The luet util unpack CLI could host a new argument such as --platform to mimic standard Docker CLI utilities and use ParsePlatform from github.com/google/go-containerregistry/pkg/v1/platform.go then use its result in remote.Image(..., remote.WithPlatform(<platform obj>)) pkg/helpers/docker/docker.go#L161.
Describe alternatives you've considered
Without this, luet package maintainers are forced to create discrete, separate tags for a package of multiple architectures. In fact this issue relates to #302 in that a solution here can help design a greater multi-arch support feature.
Additional context
Additionally, supporting this kind of argument in pkg/util/docker enables elemental-cli to add support for intelligently pulling multi-arch image manifests during elemental install, elemental upgrade or elemental reset with --system.uri=docker:....
The key use case backing this would be that a user of an elemental derivative could point elemental-cli at a single tag and not be concerned with the arch of the system they are running on.
Hi @jtcressy 👋
Thanks for opening the issue, this is definetly wanted. At a first look this looks a dup of #302. However this is currently not being prioritized, as for luet we have already a mechanism to specify arch images via config - but I'm happy to review if someone wants to take a stab at it, help is welcome here :).
For ARM images in the context of elemental it still would require specific platform images depending on the board you want to support, hence why this was never tackled. This is, of course, not the case for generic images, but still wouldn't motivate the effort here. You can track the progress in Kairos about this here: kairos-io/kairos#1061
To note, there was an attempt on this by @frelon here: #303, but I'm not sure why it was closed without interaction.
I hope to take my own stab at this soon with a PR. For my own tracking purposes at least, I wanted to document this issue with tighter scope around the use of luet as a library and less of a package manager.
Better UX when manually upgrading generic ARM systems is absolutely the only push behind this, and from myself. For all Elemental derivatives, I want to better support ARM64 systems that aren't SBC's like the rpi or odroid, such as Apple M1/M2, Ampere Altra A1 and AWS Graviton.
Stay tuned :)