Perform proper arch-label translation

[anguslees]

I see closed issues like https://github.com/coreos/rkt/issues/730 that seem to imply rkt should work on arm. When I try however, I get:

# rkt run --interactive quay.io/coreos/alpine-sh
image: using image from file /usr/lib/rkt/rkt/stage1-host.aci
run: bad arch "arm" for linux (must be one of: [amd64 i386 aarch64 aarch64_be armv6l armv7l armv7b])

(I suspect alpine-sh doesn't even have an arm* build, but it looks like the failure is occurring before we even get to that part)

Looking around the rkt code a bit, it looks like the architecture is set in several places purely based on runtime.GOARCH - but this is incorrect on arm (where GOARCH=arm, but appc architecture needs to be armv6l, armv7l, etc). Am I missing something obvious here, or am I right in thinking I need to go write some more code before rkt will work on arm?

# rkt version
rkt Version: 1.1.0
appc Version: 0.7.4
Go Version: go1.6
Go OS/Arch: linux/arm
Features: -TPM

[sgotti]

something similar is in work for appc/acbuild#195 (but guessing executable arch).

What about a common function to detect local os and arch in appc/spec or another common package? /cc @dgonyeo

[cgonyeo]

I'd be in favor of a function like that. Once a solution for the acbuild issue is figured out, want me to toss it in appc/spec instead of acbuild?

[anguslees]

@dgonyeo: Yes please.

A slight wrinkle for the rkt case (I think?) is that somehow we need to know that an "armv7l" machine can actually run both "armv6l" and "armv7l" containers (and armv5l if we want to support that arm generation too). I expect there will be other cases of that in the distant future too. I think it would be reasonable to just special case linux/armv7l in rkt if we don't want to think about a generic API for that yet.

[sgotti]

A slight wrinkle for the rkt case (I think?) is that somehow we need to know that an "armv7l" machine can actually run both "armv6l" and "armv7l" containers (and armv5l if we want to support that arm generation too).

If this multi abi case is just like i386 running on amd64 I think that the current behavior, with rkt setting the default arch to the current machine abi is good (additionally, for dependencies, the os/arch shouldn't be automatically specified on discovery, see #2317)

Actually I haven't checked if an i386 image will work on an amd64 but, if this works now or will work in a future, a user that wants to run an i386 arch image on an amd64 system or an armv6l on an armv7l system should just explicitly define the arch label in the image string.

[lucab]

/cc @s-urbaniak

[trusch]

I see that there are the necessary translation functions in appc/spec but they are not called in the check for a valid os/arch tuple. It looks trivial to implement it.

• update appc schema from master
• use the convert function

Should I create a pull request after testing?

[lucab]

We are slowly and steadily improving our arch-related compatibility, but this is unfortunately not on our direct roadmap so any external contributions on that topic are much appreciated, @trusch!

Regarding the appc/spec bump, we'll need a 0.8.9 release to have it in rkt (which should happen soon), but on the other hand you can still develop/test against master until that happens.

Regarding arch-checking and conversions, there may be a few places to take care of in rkt (fetching/discovering, image validation, image running) and outside of it (containers/build and docker2aci) but I didn't check extensively yet.

If you have a non-amd64 OS at hand, feel free to have a round of building, converting, pushing to quay.io, fetching from remote, fetching from local and running. We'll need to collect and reference all those issues under an umbrella ticket.

[lucab]

@trusch if you are still interested in this https://github.com/coreos/rkt/pull/3384 just landed, so you can just proceed using the conversion functions from there.