Buildah: Build quay.io/buildah/stable:latest for power(multi-arch)

[bkhadars]

This task is to build buildah image for ppc64le and create Multi-arch Manifest
Githhub link: https://github.com/containers/buildah/tree/master/contrib/buildahimage

We need ppc64le image for running openshift e2e test on power platform

[TomSweeneyRedHat]

I'll confess I barely know what ppc64le is, not something I've played with much. I'm not sure we could manage to do a stable image, but I'm pretty sure we could do an upstream version if we did something like this. @rhatdan or @lsm5 I'm thinking we could use the Dockerfile.upstream, but I'm not sure what to chunk into the FROM statement there or what steps to do after the from to convert the image to 'le'. Thoughts?

[rhatdan]

I would think we need a contribution from a ppc64le box, so the build can be done. @nalind WDYT?

[bkhadars]

I'll confess I barely know what ppc64le is, not something I've played with much. I'm not sure we could manage to do a stable image, but I'm pretty sure we could do an upstream version if we did something like this. @rhatdan or @lsm5 I'm thinking we could use the Dockerfile.upstream, but I'm not sure what to chunk into the FROM statement there or what steps to do after the from to convert the image to 'le'. Thoughts?

we have a buildah docker image already built and tested in our local environment for ppc64le arch, to build the buildah stable image for ppc64le platform dockerfile doesn't need any changes as the parent image fedora:latest docker image is already available as multiarch from dockerhub..

docker image:

[root@ip9-114-192-159 ~]# podman images | grep buildah
localhost/buildah-ppc64le   stable   750fd32a0209   3 days ago    329 MB

# podman exec -it  buildahctr /bin/sh
sh-5.0# buildah from alpine

Getting image source signatures
Copying blob cd18d16ea896 done
Copying config 803924e7a6 done
Writing manifest to image destination
Storing signatures
alpine-working-container
sh-5.0#
sh-5.0# buildah images
REPOSITORY                 TAG      IMAGE ID       CREATED       SIZE
docker.io/library/alpine   latest   803924e7a6c1   3 weeks ago   6.83 MB
sh-5.0#

[yselkowitz]

Actually, this is needed for s390x too for the same reason. quay.io now supports manifest list images for all projects, and Fedora has base images for all its arches, so this is just a matter of changing how you build and push your images to cover these arches as well.

[rhatdan]

Anyone in the community willing to help on this? I am not sure we can easily build s390x images from Quay.io?

[yselkowitz]

cc @james-crowley wrt community access to P&Z resources

[james-crowley]

@yselkowitz Thanks for tagging me.

@rhatdan Sorry for the delay. I had an extended power outage! 👎

Getting Buildah access to ppc64le and s390x resources is no problem. What kind of CI/CD pipeline is the project currently using to build the images?

There are a couple ways to give Buildah access to ppc64le and s390x resources. One is integrating your build pipeline into Travis CI. That might not the best solution if you are currently using another CI/CD provider.

The second way is using resources at Oregon State University via the OSU Open Source lab, https://osuosl.org/services/ibm-z/ & https://osuosl.org/services/powerdev/. They have access to s390x and ppc64le in a couple different ways. The most common way of using their services is via their Jenkins server to enable an CI/CD pipeline.

The last way is getting the project direct access to VMs on a s390x and ppc64le machines. With the VMs you can integrate them into your pipeline anyway you want.

Let me know what way works best for Buildah and we can take it from there!

[rhatdan]

CI/CD is currently using cirrus. We dropped travis a while ago. @cevich WDYT?

[cevich]

It sounds like the details of the automation framework doesn't matter much. Assuming this is _only_ for building images, having VMs on standby somewhere we could ssh into and run commands...Errr, hmmm, actually that seems fairly fragile, esp. if the state of the VM somehow changes unexpectedly :confused:

The _easiest_ way (for us) is if someone else sets up a Jenkins pipeline :smile:

I'm happy to create and provide service credentials that will permit Jenkins to push images to one/more of our quay.io namespaces. I'm not a Jenkins expert, but IIRC, it can watch a github repo. for changes on a branch or a new tag, and trigger a build from that, eh?

Another idea is we could tickle a webhook somewhere from our CI setup, providing details necessary for a native container build (i.e. git url, sha, tag, branch, etc.).

Lastly, I'm sure Red Hat has this hardware as well, so it's conceivable we could have our own internal automation drive something to do the builds, but gosh that seems like a lot of work.

Hmmm...what's the easiest (for everyone) way forward?

[james-crowley]

@cevich I like the idea of the Jenkins server. That is how the OSU Open Source lab works. They maintain the Jenkins server and builds are only triggered via commit to a branch/new tag.

The service is free and Buildah would need to apply. Once accepted you can set it up to build the images and push them to quay.io.

[cevich]

Oh, it's that open? Neat! Though this seems like the best way forward, I was hoping I could hand over some quay.io keys and somebody familiar with the howtos would make 'er chooch :smile: I've not messed with Jenkins in a very long time, and am afraid it might take me ages to do even a simple thing.

@rhatdan I'm assuming there's no way to cross-build images, it's got to be done native, ya?