Specify process for naming future architectures #29
Conversation
|
Not opposed but I am guessing you meant for this to be on the arch line, not the OS line? |
|
Oops, fixed... On 04/15/16 02:35, Brandon Philips wrote:
|
| @@ -167,7 +167,8 @@ Here is an example image JSON file: | |||
| <li>amd64</li> | |||
| <li>arm</li> | |||
| </ul> | |||
| More values may be supported in the future and any of these may or may not be supported by a given container runtime implementation. | |||
| More values may be supported in the future and any of these may or may not be supported by a given container runtime implementation. Future values will be consistent with those already canonicalized by the <a href="https://www.debian.org/ports/">Debian ports list</a>. | |||
There was a problem hiding this comment.
this is already kinda broken by "arm", right? :/
There was a problem hiding this comment.
Well Debian doesn't use 386 but i386. They do seem to have an architecture named arm, there are lots of Debian arm architectures based on the build flags. I don't demand that we follow Debian's lead, but it was the closest thing that I could find to a standard for specifying actual BUILD TIME architectures! I think that it is good to copy someone, even if there are some differences in the naming. I think that it is better than to just come up with random names for things. And actually, I think that in the case of arm, following Debian's standard brings along a lot of valulable technical know-how (AKA, the taxonomy of arm build setups ;) ).
There was a problem hiding this comment.
Indeed, for the sake of Arm, I think that it is necesary to either copy either Debian or Fedora, otherwise, we won't take into acount the specifics and there will be incompatibility problems at the kernel level. AKA, not all "ARM" images will run on all "ARM" kernels.
|
I just realized that the manifest spec already specifies the use of the official list for $GOARCH. https://golang.org/doc/install/source#environment EDIT: and that list agrees with the already present values. |
timthelion
force-pushed
the
patch-4
branch
2 times, most recently
from
c1b767e to
0d5c80a
Compare
Signed-off-by: Timothy Hobbs <timothyhobbs@seznam.cz>
|
You're correct. The problem is, the The manifest spec (which as you noted already uses the |
|
@jonboulle is the debian ports list specific enough? Pardon me, that I have no actual knowledge of the Arms race or whatever we're going to call this conundrum. |
|
@timthelion well, from the brief exchange we had with ARM engineers (see below), I had thought that endianness was a requirement, but I also am not extremely well versed in this area
|
|
Perhaps this would be another possible source for standard names: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch |
|
On Fri, Apr 15, 2016 at 05:56:00AM -0700, Timothy Hobbs wrote:
Not unless you want to dig down in there to find obscure architectures |
|
Maybe just reference 1 here, and move this conversation over to that |
|
@jonboulle We studied this problem early on in OCI and during multi-arch considerations for the V2.2 manifest. Indeed, The intent with these field sets was to define a class of machines on which the image would run. The real work here is defining the classes and aliasing in such way to make these fields useful in multi-arch scenarios. In some case, this may actually be better left to implementations, leaving OCIs role to define the common architectures which must be compatible (amd64, etc.), along with the data model and process for expressing the os/architecture (platform) for an image. That said, we can say that these are seeded by Ultimately, this is going to have to be a real community effort and that will be as successful as the process we adopt. |
| @@ -167,7 +167,9 @@ Here is an example image JSON file: | |||
| <li>amd64</li> | |||
| <li>arm</li> | |||
| </ul> | |||
| More values may be supported in the future and any of these may or may not be supported by a given container runtime implementation. | |||
| A full list of possible values can be found in the <a href=https://golang.org/doc/install/source#environment>Go language documentation for $GOOS and $GOARCH</a>. | |||
| Any of these may or may not be supported by a given container runtime | |||
There was a problem hiding this comment.
perhaps pull this sentence up to be all on one line.
|
This seems like something that could utilize |
|
@vbatts I would rather this spec be authoritative on archs and OS strings than not. This will be an important namespace for the spec to own. If we reference the GOARCH / GOOS spec I think it should be more along the lines of "New architectures and OSes will be added over time and through discussion on the OCI Image Project. A source for inspiration for new entries is the Go docs etc etcd" |
|
@philips While agree we need to call these out here, it is unlikely that anyone will ever "own" the platform namespace ;). Deferring to GOOS/GOARCH as the inspiration, but not the canonical source, seems to be the right balance. |
|
@stevvooe So, are you saying you are OK merging as-is? Or you want it to be more along the lines of "future entries should be inspired by". I am not seeing what you want. |
|
@philips I agree with "future entries should be inspired by" and #29 (comment). We're going to have to curate these and I don't see a way around it. I'm not sure about merging this PR. We can merge this but then it will be rolled back later. |
|
@stevvooe Ack. @timthelion Sorry, but would you mind making the language be more like what @stevvooe suggests? If our indecisiveness is getting too annoying LMK and I can fixup the language and merge on your behalf. |
|
Closing in favor of: #60 |
The old platform.os text had two MUST conditions. The first could have been read "the runtime MUST generate an error if invoked with a config.json whose platform.os is incompatible with the host platform" (which is the direction I'm going with this commit). However, it could also have been read "the bundle-validator MUST generate an error if platform.os is incompatible with the content the bundle's other content (e.g. 'linux' in platform.os, but only Windows binaries in the bundle's rootfs). For the second MUST, I doubt we want to require a compliant runtime support all Go architectures itself. And there is a benefit to pointing runtime/bundle authors at the Go set, but not much benefit in making that a hard limit [1,2]. The rewording here follows [2] in acknowledging that process.arch-matching is something that the config author and runtime caller have to sort out between themselves and pointing them at the Go docs and a registration process to avoid fragmenting the community. [1]: opencontainers/image-spec#29 [2]: opencontainers/image-spec#60 Signed-off-by: W. Trevor King <wking@tremily.us>
The old platform.os text had two MUST conditions. The first could have been read "the runtime MUST generate an error if invoked with a config.json whose platform.os is incompatible with the host platform" (which is the direction I'm going with this commit). However, it could also have been read "the bundle-validator MUST generate an error if platform.os is incompatible with the content the bundle's other content (e.g. 'linux' in platform.os, but only Windows binaries in the bundle's rootfs). For the second MUST, I doubt we want to require a compliant runtime support all Go architectures itself. And there is a benefit to pointing runtime/bundle authors at the Go set, but not much benefit in making that a hard limit [1,2]. The rewording here follows [2] in acknowledging that process.arch-matching is something that the config author and runtime caller have to sort out between themselves and pointing them at the Go docs and a registration process to avoid fragmenting the community. [1]: opencontainers/image-spec#29 [2]: opencontainers/image-spec#60 Signed-off-by: W. Trevor King <wking@tremily.us>
No description provided.