I love Drone CI. It’s fast and stable.
It is great if Drone CI will support the CPU architectures with arch: ppc64le (PowerPC Little-endian) and arch: s390x (IBM Z) syntax like Travis does.
I saw it would be planed at somewhere of this community pages.
So, I would like to open this ticket to discuss and track the topic.
Could you share the current status?
What is the challenge for Drone CI to start the supports?
We would love to support s390x and ppc64le but would need someone to help us procure and sponsor the cloud infrastructure costs. All of our amd64, arm and arm64 servers are sponsored by Packet.
Yes, I know Packet is sponsoring the arm64 (arm) servers to Drone CI, Travis CI, and Shipable CI as their strategy.
According to the Travis CI’s past tweet in Twitter, IBM is sponsoring the ppc64le and s390x servers for Travis CI. Maybe.
Did you negotiate with IBM?
Here is the IBM contact information to add s390x, I know.
If you’re interested in getting more serious about testing your open source application, perhaps adding a s390x virtual machines to your Continuous Integration system, please reach out to me, Elizabeth K. Joseph at lyz@ibm.com, so we can talk about ways to support your project.
I sent email to the IBM contact email address to ask them to sponsor Drone CI’s ppc64le/s390x servers. When I see the updated news, I will let you know here.
I found the following articles for your reference.
Thanks! I will be interested to hear what the say
What about using qemu? https://developer.ibm.com/linuxonpower/2017/06/08/build-test-ppc64le-docker-images-intel/
these servers do not have kvm available, but if someone wants to try and run qemu in emulated mode inside of a container they can try and report back whether or not it works. I think native hardware would be ideal, though.
Thanks! I will be interested to hear what the say
So far, there is no response from the IBM.
There are tools to run the different architecture’s container on x86_64 host via QEMU installing binfmt_misc files in /proc/sys/fs/binfmt_misc on the host.
Or just install qemu-user-static RPM if the host is RPM base Linux to run the different architecture container. I am not sure which deb package is installed if the host is Debian based Linux. Yeah, the native hardware is ideal.
Or just install qemu-user-static RPM if the host is RPM base Linux to run the different architecture container. I am not sure which deb package is installed if the host is Debian based Linux. Yeah, the native hardware is ideal.
Debian has qemu-user-static deb package too.
Perhaps, the following command might work on the host environment.
$ uname -m
x86_64
$ apt-get -y install qemu-user-statc
$ docker run --rm -t ppc64le/debian uname -m
ppc64le
@junaruga @bradrydzewski greetings, what would be the requirements for a PoC on ppc64le?
greetings, what would be the requirements for a PoC on ppc64le?
@rpsene I do not understand what you mean. You meant what is the possible way to implement the native ppc64le feature on Drone CI?
@junaruga I’m interested on understanding what would be required to add support for ppc64le as part of the runners initially and later in the server.
I’m interested on understanding what would be required to add support for ppc64le as part of the runners initially and later in the server.
@rpsene Please forgive me for my late response. OK. I think it depends on how Drone CI cloud works internally. And I am not really sure, as I am just a user of Drone CI.
We would love to support s390x and ppc64le but would need someone to help us procure and sponsor the cloud infrastructure costs. All of our amd64, arm and arm64 servers are sponsored by Packet
According to @bradrydzewski 's comment, the servers (x86_64) to show the CI’s web UI need to connect to the ppc64le/s390x based remote servers internally.
Maybe on the remote servers, an application like Exec Runner needs to be installed.
I guess as the Drone CI’s tools are mainly written by Golang, if the Golang works on the ppc64le/s390x architectures, the tools work there. So, I guess there is less technical difficulty. But the matter is the cost of the ppc64le/s390x servers.
I can provide free P resources and can talk with Z folks for the same. @bradrydzewski who would be good contact for this discussion? Linux on P and Z are the save as on x86_64. Cross-compiling GO is super easy.
@rpsene let me get back to you on this. I am probably still the person, and would certainly love to have more architectures available.
I’m interested on understanding what would be required to add support for ppc64le as part of the runners initially and later in the server.
First, we need to publish a ppc64le docker image for the runner. The runners no longer have a dependency on cgo which means we should be able to cross-compile on linux, which is what we currently do for arm and arm64.
Next we would need to build and publish a ppc64le docker image for the git plugin at github.com/drone/drone-git and for the docker plugin at github.com/drone-plugins/drone-docker. These are a bit more tricky because they must be built on ppc64le. There is no way to bootstrap, which means we need to do this manually (which is not a big deal, and only needs to be done once).
The only blocker I see is our docker plugin relies on the official docker:dind image, from Docker Inc. They do not appear to publish this image for ppc64le. See hub.docker.com/_/docker. Without the docker:dind image it becomes very difficult for us to support an os or architecture. We need to build most plugin images, and the drone server image, on the native architecture which would not be possible without docker:dind.
I can provide free P resources and can talk with Z folks for the same.
@rpsene Wow, that’s amazing! I am really looking forward to seeing Drone CI supporting the P and Z.
@bradrydzewski Thanks for correcting me, and thanks for your explanation about the process to implement on ppc64le.
These are a bit more tricky because they must be built on ppc64le.
Did you consider to use Docker’s buildx (the blog) that may enable to build ppc64le based images on x86_64 machine? Though, as it is build by QEMU emulation, I guess the building on the native ppc64le might be better than building with buildx on QEMU.
The only blocker I see is our docker plugin relies on the official
docker:dindimage, from Docker Inc. They do not appear to publish this image for ppc64le. See hub.docker.com/_/docker .
Interesting, the docker:dind image is published for arm64 and arm32, but not for ppc64le and s390x. Might the Docker company also have a challenge to build docker:dind on ppc64le and s390x in terms of the cost of the machine resource? I hope IBM or someone collaborates Docker for the challenge.
@bradrydzewski Could you tell me your email?