-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encapsulate OCI images across architectures #5100
Comments
Well this would be trivial if we'd embedded the arch in the commit metadata...it looks like we tried to do that but never did. It's only there as
Yes, I think that's what is needed. (In the more medium term of course, a better fix is to switch the order of things; build a container image, and then unpack it into the ostree repo) |
I would like to have a shot at resolving this (at least the short-term fix). Would you prefer a flag passed to container-encapsulate which accepts the arch, or do you think extracting the arch from a common label, such as "basearch", would be better? I completely agree that long-term it would be best to have a "container-first" approach. |
I don't think we have anything like that in this process at the moment; it was a bad design choice for ostree not to try to standardize the architecture as part of the commit metadata. It's only encoded in the ref names conventionally, and parsing that would be possible but quite ugly.
I think it has to be this in the short term. However there is a different fix: patch rpm-ostree to add The patch for that on the ostree-ext side should just look like:
(untested) |
Just realized the powerpc handling there is wrong, we can't reference compile-time endianness of course. Edited. |
Took another look at this, and while I'm not 100% sure where this should fit in, or how to test this without an ARM machine, it somewhat makes sense to do the following on the rpm-ostree side:
This sets a variable for ostree.architecture to either the treefile's basearch (if set) or the value of the "basearch", which appears to be computed from the host's machine. I know it compiles and the variable is being set with the correct KV pair, but not whether this is the right approach |
Unfortunately the patch to ostree-rs-ext doesn't work as expected.
I know the arch is getting set correctly since the debug println displays so:
|
The aim is to get
rpm-ostree compose container-encapsulate
to work when trying to bundle AARCH64 commits to an OCI while on an AMD64 machine. Possibly by introducing a new--arch
flag.This should resolve the current issue in the Silverblue OCIs built on Fedora's infra where the ARM images contain the AARCH64 contents (i.e. packages), however the image manifest declares the architecture as AMD64. I think this is due to the script being used runs on AMD64 for all architectures.
In theory, the image contents are all built for AARCH64, so given the correct image configuration, it should "just work" ™️ .
I can see that the ImageConfiguration struct from oci-spec-rs has a field to store the architecture, so I believe we just need to feed the correct value through to there.
From my 10 minutes of investigation, I am hoping we may be able to update ostree-ext-rs's Config struct to accept an architecture, extract the architecture from the struct in build_oci and feed it into the imgcfg object.
Once that is updated, we will have ostree-rs-ext exposing the options required for passing in an architecture to the build in the encapsulate function. Now we can update this repo to accept the
--arch
flag and pass it to the config which ends up being used in the call to ostree-ext-rs's encapsulate functionAs mentioned previously, I do not know if this will work as I am intending it to, or if there are any other limitations which may prevent this but I'm hoping someone here does 😄
The text was updated successfully, but these errors were encountered: