Multi Arch Support

[smehta99]

Pull Request Template

Thank you for your contribution! Please ensure the following before submitting:

Checklist

• My code follows the style guidelines of this project
• I have added/updated comments where needed
• I have added tests that prove my fix is effective or my feature works
• I have run make test (or equivalent) locally and all tests pass
• DCO Sign-off: All commits are signed off (git commit -s) with my real name and email
• REUSE Compliance:
  • Each new/modified source file has SPDX copyright and license headers
  • Any non-commentable files include a <filename>.license sidecar
  • All referenced licenses are present in the LICENSES/ directory

Description

Please include a summary of the change and which issue is fixed.

• Made it so when the images are pushed they are pushed with arch names example: rocky-linux:latest-x86_64.
• Creates and pushes manifests so multiple archs can be supported.

Also include relevant motivation and context.
Interest in exploring manifests

Fixes #15

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

---

For more info, see Contributing Guidelines.

[synackd]

Thanks for the contribution. I didn't see a description so before this is marked as ready for review, can you provide testing instructions with expected results using a minimal working example? That would expedite the testing process.

[smehta99]

There isn't much testing to do here (especially, when I don't have any aarch64 hardware). Main thing to check is that the generated image can be pulled without having to specify the arch and that its pointing to the correct image:

$ podman pull --tls-verify=false 172.16.0.254:5000/openchami/rocky-base:latest
Trying to pull 172.16.0.254:5000/openchami/rocky-base:latest...
...
74d3412e4d4fbdcbc3e0586c997af4e57995c2444aeab2b09f3256bdfd3f8b65

$ podman pull --tls-verify=false 172.16.0.254:5000/openchami/rocky-base:latest-x86_64
Trying to pull 172.16.0.254:5000/openchami/rocky-base:latest-x86_64...
...
Copying blob 9c82532b6ba7 skipped: already exists  
...
74d3412e4d4fbdcbc3e0586c997af4e57995c2444aeab2b09f3256bdfd3f8b65

The other thing to check is that the subsequent images that are being built off of the "scratch" image pulls the correct image and pushes images with correct manifest when finished building. Which it seems to do:

ERROR - Trying to pull 172.16.0.254:5000/openchami/rocky-base:9.5...
...
ERROR - Copying config sha256:74d3412e4d4fbdcbc3e0586c997af4e57995c2444aeab2b09f3256bdfd3f8b65

$ podman pull --tls-verify=false 172.16.0.254:5000/openchami/compute-base:rocky9.5
Trying to pull 172.16.0.254:5000/openchami/compute-base:rocky9.5...
...
Copying blob 9c82532b6ba7 skipped: already exists  
Copying blob df14b69e031b done   | 
...
66bd5936e786cd51549621fddcec84b6c2365950ef5f112f83b101a3b63f76ef
$ podman pull --tls-verify=false 172.16.0.254:5000/openchami/compute-base:rocky9.5-x86_64
Trying to pull 172.16.0.254:5000/openchami/compute-base:rocky9.5-x86_64...
...
Copying blob df14b69e031b skipped: already exists  
Copying blob 9c82532b6ba7 skipped: already exists  
...
66bd5936e786cd51549621fddcec84b6c2365950ef5f112f83b101a3b63f76ef

[smehta99]

This PR is ready for review. Please let me know if I missed a test case.

[alexlovelltroy]

Looks great! I don't see that we can control multi-arch via a commandline arg. Am I missing something?

[smehta99]

I don't see that we can control multi-arch via a commandline arg. Am I missing something?

Possibly. Maybe I misunderstood the request.

1. Are you saying that it should only do multi-arch manifests if a user passes a command line argument? Or
2. Are you saying "build images for these archs" when passed in with a command line argument? i.e. --arch=amd64,arm64

If its the second option, I spoke with @travisbcotton and it seems should only be doing "build + push" of host arch. I guess we could use QEMU. I will need to explore how that works before I can implement it.

[alexlovelltroy]

I was concerned that we'd be adding multi-arch (with qemu) to all future builds with this change. Sounds like that was never part of the intention. How do we envision matching the x86 and arm builds of the same image to make the manifest include both?

[smehta99]

This PR uses "name" + "published_tag" to name the manifest and then points to the correct image.

I slightly modify the name of the image, previously it was "name" + "published_tag" (same as the manifest name now) but I add "-{arch}" to it. Then I say "add this image to this manifest" which captures the arch.

When a x86_64 image is pushed, it pushes it to rocky-base:8.10-x86_64 and an arm64 gets pushed to rocky-base:8.10-arm64 but manifest name remains unchanged rocky-base:8.10 when I add an image to manifest, it captures the host arch and starts making a manifest list. When a user wants an image, they pull the manifest, which returns the correct image based on their host arch.