Add support to build minikube binary on AArch64

[arm64b]

Current Makefile can only support build minikube bin on
{linux, darwin, windows}/amd64 system. This PR is used to
build the binary on linux/arm64 platform.

Fix #2454

Signed-off-by: Dennis Chen dennis.chen@arm.com

[minikube-bot]

Can one of the admins verify this patch?

[arm64b]

/assign @jimmidyson 🎃

[arm64b]

Hello @minikube-bot @dlorenc @luxas @jimmidyson , any feedback/suggestion about this if we want to use minikube on our AArch64 platform, actually it does 📆

[dlorenc]

Hey,

We've had some similar discussions over in #2171 about enabling minikube for other architectures.

Can you explain the use-case a little bit more? Changes like this greatly expand our test/support matrix, so we need to make sure there's enough interest to justify the support costs.

[arm64b]

Hi except the point mentioned in #2171, we're building the AArch64 enterprise ecosystem which is being evaluated by some big internet companies, so clearly it's very important for us to have those related areas ready for the customers. minikube is one of the toolbox raised by this. Yes we know that simply just enable the binary build process will expand the test/support matrix followed, but I will give a vote to promote the multi-arch support in you guys' road map/ to-do list in terms of the biz model we're facing 🎖 Maybe, just maybe, can we offload the arch-related support to the arch vendors who want to make it happen on their platforms ❓

[dlorenc]

I'm going to close this and the related PR for now. Feel free to re-open with a more detailed proposal on how to run integration tests on these platforms in CI. Until then, we can't make any promises on keeping minikube actually working on these platforms, so it would be irresponsible to add any kind of official support.

[vielmetti]

@dlorenc - is there any opportunity to revisit this? I understand that there are plans to move your CI system over to Prow from Jenkins in #3256, and perhaps like #2881 this could be queued up behind that move or taken as "experimental" in the interim.

[tstromberg]

@vielmetti - I'm OK with approving this PR so long as it doesn't break our current Make rules. Please see about updating it for merge conflicts.

We don't yet have plans for aarch64 on our CI system, so we'll just list it as an experimental port for now.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: arm64b
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: dlorenc

If they are not already assigned, you can assign the PR to them by writing /assign @dlorenc in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[afbjorklund]

I did some work* on building for ARM, by using Raspbian and the proot system...

• https://github.com/afbjorklund/raspbian-proot

Don't see any reason why that shouldn't work in a CI context, as it doesn't require root.

Can verify on it hardware afterwards (Raspberry Pi), so it could be an interesting project.

[afbjorklund]

Looks like a hardcoded oneliner is remaining, but much more remain for the none driver.

[afbjorklund]

This line is part of the release build, it tries to checksum all known binaries (they have been cross-compiled earlier).

Thus it doesn't make sense to checksum only one of them. Should probably make the list into a make variable though.

[afbjorklund]

I think the Raspbian distro is 32-bit (armhf/armv7l), so maybe use Debian for the 64-bit (arm64/aarch64)

https://www.debian.org/releases/stretch/arm64/release-notes/

[afbjorklund]

This has already been changed (in c7037c4). But it doesn't really help, anyway.

It needs to be dynamic, so that you can cross-compile for any target. This way, it only works for $(GOOS): not $(GOARCH)

[afbjorklund]

Added a better (cross-compilng) implementation in #3887, we can close this old PR now.

But need a new ticket for discussing runtime support for the ARM architecture (amd64)...

As long as we were doing VM, this was rejected.

But for the new nonedriver, it could be done.

[tstromberg]

Closing this PR as an alternative has been merged. Thank you!