Yelp/dumb-init

Adding Z(s390x) binaries to releases page

james-crowley opened this issue ยท 15 comments

Just like #161, I am trying build "fluentd" dockerfile, but running into a 404 issue when it tries to grab https://github.com/Yelp/dumb-init/releases/download/v1.2.1/dumb-init_1.2.1_s390x.

This process would be easy if Travis did support s390x, but they do not. If/when Travis does I am happy to help set up a Travis build just like @ghatwala did for power.

In the meantime I am open to suggestions. I usually recommend to open source projects, to sign up for the LinuxONE Community Cloud which will give you access to a Linux instance hosted on a s390x platform.

It is total free and will not cost you anything. The only downside is I think it has 90 or 120 day limit. If you are interested in this, let me know and I can see if we can extend the day limit.

So I lied, there is another way to build against s390x and it might be a better fit then using the LinuxONE Community Cloud. Oregon State University offers a CI pipeline you can use. More info can be found here. Sign up for the services is here. Once again this is all free, it will not cost you guys anything.

I had a chat with @chriskuehl and we're in support of enabling something like this -- perhaps this weekend we'll have some time to set some of this up ๐Ÿ‘

Great, let me know what you need from me and where I can help!

@asottile Were you able to look at getting access to the s390x build environment? If you have any trouble let me know.

I totally forgot about this oops, I just filled out the OSU form so we'll hopefully hear back soon! -- I added @chriskuehl on the github usernames list there

Hey @james-crowley, we were granted access and I spent a bit of time clicking around in the Jenkins UI. It looks like we were able to successfully build: https://ibmz-ci.osuosl.org/job/dumb-init/8/ (this build was a failure but it copied over artifacts from the previous, successful, build).

Need to spend a bit of time tomorrow fixing the job config, but are you able to verify if those artifacts work for you? There's both a Debian package and a statically-linked binary available for use.

If those work we can fix up the build and upload those to the regular "Releases" tab like all the other architectures.

Another thing I just thought of: because Debian supports s390x and dumb-init is an official Debian package, you could also get a build from them if desired: https://packages.debian.org/buster/dumb-init

It won't be statically linked though.

@chriskuehl Let me verify those builds today and get back to you.

Another thing I just thought of: because Debian supports s390x and dumb-init is an official Debian package, you could also get a build from them if desired: https://packages.debian.org/buster/dumb-init

Currently, I am using dumb-init 1.2.1 from the Debian packages, but the application I am trying to build, https://github.com/vmware/kube-fluentd-operator, which calls for dumb-init 1.2.0.

@chriskuehl Sorry for the delay, but I just tested the build:

root@d18a38426379:/# wget https://ibmz-ci.osuosl.org/job/dumb-init/lastSuccessfulBuild/artifact/dist/dumb-init_1.2.2_s390x.deb
--2019-08-01 15:54:34--  https://ibmz-ci.osuosl.org/job/dumb-init/lastSuccessfulBuild/artifact/dist/dumb-init_1.2.2_s390x.deb
Resolving ibmz-ci.osuosl.org (ibmz-ci.osuosl.org)... 140.211.9.22
Connecting to ibmz-ci.osuosl.org (ibmz-ci.osuosl.org)|140.211.9.22|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 42658 (42K) [application/x-debian-package]
Saving to: 'dumb-init_1.2.2_s390x.deb'

dumb-init_1.2.2_s390x.deb                                   100%[=========================================================================================================================================>]  41.66K  --.-KB/s    in 0.09s

2019-08-01 15:54:35 (469 KB/s) - 'dumb-init_1.2.2_s390x.deb' saved [42658/42658]

root@d18a38426379:/# dpkg -i dumb-init_1.2.2_s390x.deb
Selecting previously unselected package dumb-init.
(Reading database ... 6809 files and directories currently installed.)
Preparing to unpack dumb-init_1.2.2_s390x.deb ...
Unpacking dumb-init (1.2.2) ...
Setting up dumb-init (1.2.2) ...
root@d18a38426379:/# dumb-init --version
dumb-init v1.2.2
root@d18a38426379:/# arch
s390x
root@d18a38426379:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@d18a38426379:/#

I tested dumb-init 1.2.2 on Debian Stretch-slim on a s390x server.

Is there anyway we could get a build of 1.2.0? I know its a little dated but that is what Fluentd is using in their 1.2.6 builds. Specifically, there script calls:

dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')" \
 && wget -O /usr/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v${DUMB_INIT_VERSION}/dumb-init_${DUMB_INIT_VERSION}_$dpkgArch

It fails, cause its looking for a release of 1.2.0 with an arch of s390x. If you guys could add it the build there that would be great!

@james-crowley thanks for verifying! I built v1.2.0, v1.2.1, and v1.2.2 for s390x and uploaded those under the existing GitHub releases. Can you check if it works for you now?

@chriskuehl Works like a charm! I appreciate all your help and your support for the s390x platform!

@chriskuehl @asottile How was working with OSU? Any feedback you can give us? I have not gone through the processes myself, since we have plenty of s390x machines to work with.

Was there instructions given to you after getting approved? As for pulling in those builds, do you have to do that manually to add them to the Github release page?

It was pretty straightforward -- I made a ticket with some github usernames and was enabled within 24 hours (though they mention SLA on that is ~7 days, but it was very quick). Beyond that they give access to a jenkins instance that you log in with a github username

we didn't hook it up for PRs afaik, but it builds after-the-fact on merge to master

We did have to add some manual steps to upload, but they're not too difficult: #190

Yup, it was pretty smooth on my end too. I didn't attempt to set up any kind of GitHub integration though (mostly because it requires going through some process to get new integrations approved under this GitHub org and it didn't seem worth it).

Thanks for the feedback! Glad it seemed pretty painless, that is what were shooting for. Once again, thank you for support s390x and back porting your releases.