Add support for s390x

[e-desouza]

Describe the problem/challenge you have
Take OpenShift backups on IBM Z/IBM LinuxONE systems

Describe the solution you'd like
s390x support similar to arm64, ppc64lee

Environment:

• Velero version (use velero version): v1.4.0 and above
• Kubernetes version (use kubectl version): Kubernetes 1.16
• Cloud provider or hardware configuration: s390x arch (z13, z14, z15, LinuxONE, LinuxONE II, LinuxONE III)
• OS (e.g. from /etc/os-release): linux

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

[e-desouza]

@ncdc can you please assign this to me? I have a PR in progress.

[nrb]

@e-desouza Any update on your PR?

[e-desouza]

Replicating what the other platforms did, I'm looking for a place to upload the restic binary to. This part specifically needs it.
Other than that it's all ready and merged to latest at: https://github.com/e-desouza/velero

[jenting]

It needs the restic supports s309x platform, ref to restic/restic#2780.

[eleanor-millman]

Closing, but feel free to reopen if/when you make the PR.

[hoytk]

What is the status of s390x support? The is closed but I'm not finding any mention or packages for Z.

[dsu-igeek]

The PR was never submitted. If you need this, please reopen the issue and vote for it.

[hoytk]

I don't have permission to re-open this issue.

[eleanor-millman]

@hoytk Reopened for you!

[zubron]

I mentioned in #4047 (comment) that Restic now has a release with s390x support. In order to support this architecture we would need to upgrade to this version.

[rposts]

Thanks @zubron - for now it can be built on s390x by simply specifying RESTIC_VERSION=0.12.1 during make all-containers step. Would it make sense to add a blurb in the docs wrt s390x until Restic upgrade happens in the main branch?

[kycfeel]

I'm also looking forward! What's the status of it right now?

[rposts]

@zubron if it makes sense I can PR changes as per #4047. Let me know your thoughts. Thanks.

[eleanor-millman]

@rposts FYI, @zubron is on vacation until next Friday, so she will take a bit of time to respond :)

[rposts]

Hi @zubron - just wanted to follow-up on this issue.

I also noticed that in order for testcases (make test) to run on s309x we will require some changes to build-image/Dockerfile (these changes are not required to produce velero binaries on s390x):

• s390x arch equivalent of kubebuilder
• s390x arch equivalent of protobuf
• s390x arch equivalent of goreleaser
• s390x arch equivalent of kubectl

[zubron]

Hi @rposts - Sorry for the delay in getting back to you here!

For non-amd64 platforms that we support, we don't maintain the build image for building/running tests, and instead rely on Go's cross-compiling and Docker buildx for releasing on those targets as I mentioned in #4047 (comment). I don't think it will be possible to actually build on s390x as not all of the tools listed above have s390x binaries available. Are you using s390x as your development platform? Another option for testing on this platform would be to use our E2E tests. These run the velero binary and deployment on a cluster so that would enable testing of s390x assets.

We recently upgraded the version of restic we are using (see #4274) which has a s390x build so it should just be a matter of adding this platform to the targets that we build for.

[rposts]

Thanks @zubron for your comments.

Yes, my development platform is s390x and my intention was to run through the testcases to make sure velero works on this platform. I also acknowledge your #4047 comment. Just that I couldn't find a way to run the testcases without building the s390x compatible velero/build-image which required kubebuilder etc.

I will try to run E2E test if that offers sufficient coverage.

Would you have any rough idea when we can expect this platform to be added to the cross-compile/release scripts?

Thanks again for your continued help.

[rposts]

Hi @zubron - just a quick follow up on adding this platform to the build targets. I think we have pretty much everything in place now.

Thanks for your patience and help.

[eleanor-millman]

@reasonerjt is this resolved now?

[reasonerjt]

@rposts
Could you clarify if you have verified that the s390x is supported?

I'm removing the 1.10 label as we don't have bandwidth to verify it.

[rposts]

@reasonerjt as far as I can see nothing has changed here so there is no reason to believe s390x support has been added. I will be happy to assist with validation once support has been added.

[rposts]

@reasonerjt - just wanted to check how I can further assist in making s390x binaries available? Thanks.

[bluzarraga]

Hello, I am also looking for s390x support for velero, is there any timeline for adding this? I see this issue is over 3 years old now and that the version of restic is at least 0.15.0 since #5784 (above the necessary 0.12.1 according to #4047 (comment)). What needs to happen to support s390x?

[ranjeetsingh-23]

Hi Team,
Any update on velero CLI for s390x support?

[ranjeetsingh-23]

Hi Team,
I don't see Velero CLI is available for s390x
https://github.com/vmware-tanzu/velero/releases/tag/v1.14.0
When a Velero CLI support for s390x can be added?
Thanks,

[kaovilai]

It should be possible to produce a binary using only GitHub actions. However, it will not be officially tested in any continuous manner, so its functionality cannot be guaranteed at all times.

If I understand the sentiment of the maintainers correctly, it is that we should make it easy and perhaps even document how to create such a CLI for s390x, but we will not ship anything that we do not have CI/dev infrastructure to test and debug.

Are you OK with documentation and any fixes required to unblock self builds? Or do you require maintainers to produce unvalidated cross compiled s390x velero binary?

[kaovilai]

#7505 is going to address this