byte order info

[glevand]

I didn't see any way to know the byte order (endian) of the container image other than inspecting binaries in the image. Byte order info should be in the config file so that a system can determine compatibility with only the config, and not need to download the entire container image when testing.

Maybe this is a shortcoming of using GOARCH as the set of values for platform:arch.

[stevvooe]

@glevand Could you give an example of where this may matter but wouldn't be covered by the platform/architecture? For example, is ppc64le not sufficient for the architecture?

[glevand]

@stevvooe I think the issue is that the spec requires a platform have the go language ported to it (to have a GOARCH value). Is that what we want, a dependency on the go language? If so, that should be stated in the spec since it is a significant dependency. Looking at the FAQ, it states 'Container formats and runtime should not be bound to clients, to higher level frameworks...'. I think the go language could be considered a high level framework.

What prompted me to open this issue was support for aarch64_be, but I now see the problem is that the spec requires go language support, which aarch64_be does not have.

[stevvooe]

@glevand Understood.

I agree that we shouldn't be dependent on go language support. However, we should follow the conventions for GOARCH/GOOS since they have done a thorough, modern job of capturing this variation. The ease of cross-compilation with Go is evidence of this.

Either way, my question still stand. At this point, you've only pointed out an inconsistency but we really need to understand why it matters. Could you give an example of where this may matter but wouldn't be covered by the platform/architecture? What specific problem are you trying to solve that is not covered by architecture?

[jonboulle]

FWIW we went through a similar discussion in appc and ended up deciding against using raw GOARCH values (arm or arm64) for ARM architectures since they don't offer the necessary granularity (you need to combine it with GOARM but even that doesn't get you all the way). We instead corresponded with the folks at ARM Holdings and used their suggestions for the most appropriate values - which for the most part turns out to be the equivalent of utsname.machine on Linux - https://github.com/appc/spec/blob/master/schema/types/labels.go#L24

[stevvooe]

@jonboulle So, it sounds like some sort of ARCH is sufficient, but we need to adopt more granular values for certain architectures. Looking at utsname, there seem to be a number of caveats there, as well: http://www.gnu.org/software/libc/manual/html_node/Platform-Type.html. For example, some have manufacturer specified. Reading through the installation documentation, the Go developers broken architecture specific extensions into sub-variables. Is there a standard registry or specification for utsname machine definitions? I could not find one.

I'd hate to have us diverge into another solution that has the same problems as the current one.

[jonboulle]

@stevvooe Unfortunately no. The closest thing we came up with was mpasternacki's suggestion here to use autotools triplets, which I think ultimately might be the least-bad solution - at least it is comprehensive and consistent. Because at the end of the day there are some things that seem like a total coin-flip (e.g. amd64 vs x86_64) and some that have trickier/subtler implications (like the ARM stuff, which is why we went to the "source"). A good case in point is the Debian "port naming debates" for armhf

[stevvooe]

@jonboulle That is very unfortunate. I'm not even a fan of using autotools triplets, as they tend to be as obtuse.

I really think deviating from Go here is a bad idea. We can always augment with extra required information, as the need arises (ie GOARM and GO386). It looks like we've already headed down a half-baked path (x86_64 vs amd64 is already inconsistent :( ) without solving the open problems.

[jonboulle]

@stevvooe hmm but how exactly are you suggesting that the extra information would be augmented? I am also unclear how we'd solve glevand's use case here, and share his concern about the spec being a little too go-centric

[glevand]

Some problems with using GNU triplets and some general info on ABI specifiers is mentioned here: https://wiki.debian.org/Multiarch/Tuples

[stevvooe]

@jonboulle I'd like to clarify that I'm not saying we should use GOARCH/GOOS directly. We should mirror the technique and mapping, including the extra portions, rather than invent something new. Initially, we might simply define GOARCH as equal to OCP's arch. What I'd like to avoid is adopting another solution that is simply different.

[jonboulle]

Sure, I get that, was just unclear on how exactly you plan on incorporating those extra portions - e.g. another field? or mapping everything into OS and ARCH?

[stevvooe]

@jonboulle I would suggest having extra environment variables that are OS/ARCH specific. This will keep OS/ARCH clean while not trying to pack data too tightly into those variables.

[philips]

@stevvooe I think we should just leave it open too; this is what we did in appc. os and arch are well-known labels but we left it open for someone else to add a byte-order or even arm.com/byte-order label.