ARM support

[rcarmo]

Although it would require bootstrapping a new set of base containers, it would be nice to have armhf support.

[denismakogon]

Hello @rcarmo. Can you please elaborate which part IronFunctions you'd like to see supported on ARM?

[rcarmo]

Erm... that question doesn't really make sense, because I'd like to run all of it. I've started doing my own armhf version of iron/dind off an armhf Alpine container, but building the service itself seems to depend on a lot of x64 containers.

[denismakogon]

@rcarmo ok, i see. But my question makes sense, because in repo we have couple projects like fn tool, API server, fnlb. But i do understand what you're saying. So, let's try to define list of smaller tasks we'd like to do in a pursuit of supporting ARM v5 (or greater). Would that make sense?

[denismakogon]

Recently i tried to build project for ARMv5 and got this issue:

Deniss-MacBook-Pro-2:functions denismakogon$ GOARCH=arm GOARM=5 go build -o functions
# github.com/iron-io/functions/api/mqs
api/mqs/ironmq.go:117: constant 60000000000 overflows int

[jmank88]

@denismakogon That particular line is actually a bug anyways. A duration is passed (int(time.Minute)), but the method takes seconds, not nanoseconds. It has been fixed in #581.

[treeder]

@rcarmo this would be great, we've been talking with the https://www.packet.net/ guys about getting this running on their Type 2A server (96 physical cores), would love to make it happen. We could probably build in an ARM flag for the cli that built functions on the correct base images to make it pretty painless (thinking out loud).

cc @vielmetti

[vielmetti]

Thanks @treeder - there is also support in Docker manifests to have an image automatically select the right architecture based on the manifest (so called "fat manifest" or "multiarch" support). The one project that's gotten the furthest on this is portainer and their details on how they did multiarch are at portainer/portainer#285 using https://github.com/estesp/manifest-tool .

There's still the small matter of having an ARM build of iron/dind but once you have that the multiarch stuff lets you pick up the right architecture as you need it.

[denismakogon]

@jmank88 can we extract fix for smaller patch to get build/release job for ARMv5 (or greater)?

[rcarmo]

@vielmetti I have a repo where I made a start at my build of dind: https://github.com/rcarmo/iron-io-dind-armhf
Haven't had much time to follow up on this because I keep moving around (need to pack a Pi 3 to go), but it doesn't seem impossible.

[denismakogon]

So, @rcarmo @vielmetti we've fixed small issue and we were able to build binaries (API service) for ARM successfully.
There's PR i made to ensure that we are not breaking compatibility with ARM for server. The last thing we need to clarify that we can build fn tool too if it works fine i'll close this issue.
Thoughts?

cc @treeder

[vielmetti]

@denismakogon - this looks like good progress on armhf support. Full support for ARMv8 (aarch64, arm64) will require a parallel set of work, since ARM 32-bit binaries don't always run on 64-bit systems.

[denismakogon]

@vielmetti actually I was able to build IronFunctions for all platforms that go cross-compiling supports including ARMv8 (arm64).

[rcarmo]

Wow, thanks, guys. How do you suggest I get started testing this? maybe we could hold the issue open while we tally any documentation/teething issues?

[denismakogon]

@rcarmo you can pull latest master branch and build it with go flags like GOARCH, GOARM for specific ARM version including v8(arm64). I assume you're aware of how to build go code. Once you have binary I'd recommend to follow Getting started guide to try it out. If you're facing problems let me know.

[rcarmo]

@denismakogon Seems straightforward enough. I'll wipe a large SD card, grab the Go binaries and try it over the weekend.

[denismakogon]

Please note that you need latest Go 1.8 binaries.

[treeder]

This is more than just building the functions binary, that part is easy. The hard part is enabling users to run their functions on an ARM machine which requires different images for their functions which I believe @rcarmo is referring to when he created this ticket.

Although it would require bootstrapping a new set of base containers, it would be nice to have armhf support.

Or maybe not? But we'd need to make it easy for users to create ARM functions regardless. It's possible to run functions without dind (mount the docker socket), but it would be nice to support it.

How does this look as a full checklist for what we need:

• An ARM functions build - image name iron/functions:arm - preferably with dind support, but could start without dind
• A set of ARM base default base images that fn tool can use.
• Implement a --arm flag for the fn tool to build using the ARM base images - user/image:X.Y.Z-arm
• Implement a --arm flag for fn push (?)
• See if we could push multiple architectures at the same time to the Docker registry and use the multi-arch manifest support - see ARM support #577 (comment)

Does that sound like everything we'd need?

[treeder]

Official ARM images: https://hub.docker.com/u/aarch64/

[treeder]

And multi-arch issue: docker-library/official-images#2289

[rcarmo]

Any chance of armhf?

[treeder]

Looks like we can do the same with armhf: https://hub.docker.com/u/armhf/