architecture tagging

[ericvh]

As far as I can tell, there is no mechanism for identifying an architecture (ARM versus x86 for instance) for an image. It would be quite useful to allow for this both within the registry and within the build infrastructure (so that a docker build on ARM would only use ARM pre-req images)

[wking]

On Fri, Oct 24, 2014 at 07:50:04AM -0700, Eric Van Hensbergen wrote:

As far as I can tell, there is no mechanism for identifying an
architecture (ARM versus x86 for instance) for an image. It would
be quite useful to allow for this both within the registry and
within the build infrastructure (so that a docker build on ARM would
only use ARM pre-req images)

This sort of thing also sounds useful now that we have the possiblity
of images that depend on the Windows-kernel in the pipe 1, as well
as a range of architectures. And who knows, maybe eventually images
that depend on OS X's XNU kernel. I think it's best dealt with using
tags in an image's metadata and a search index, and making such
first-class members of the registry (or a free-standing component that
listens to webhook updates from the registry). That would also let
you include things like kernel option dependencies
(e.g. CONFIG_NFS_V4, or whatever) if your image depends on
configurable kernel features.

[dmp42]

The suggested new format so far (moby/moby#8093) does include an informative-only architecture flag.

The upside of that proposal is that it's easy to index.

This is NOT final, and should be considered work in progress. There are unaddressed questions for now (do we want "fat images"? - eg: multiple architectures, with dependent layers - how do we address tag resolution if we are not going with fat images?)

Also, there is in the engine an arch field AFAIK: https://github.com/docker/docker/pull/707/files

[wking]

On Tue, Oct 28, 2014 at 12:36:43PM -0700, Olivier Gambier wrote:

The suggested new format so far
(moby/moby#8093) does include an
informative-only architecture flag.

Do we want to continue the arch discussion there (mixed in with the
validation/signature stuff)? Or keep it here? Or move it to a new
docker/docker issue?

do we want "fat images"? - eg: multiple architectures, with
dependent layers -

I don't think so. Otherwise how would I distinguish between “I want
to run an x86 Python container on my amd64 Linux kernel” and “I want
to run an amd64 Python container on my amd64 Linux kernel”.

how do we address tag resolution if we are not going with fat
images?)

Either bake it into the tag (python:3.3-x86-linux) or the namespace
(x86-linux/python:3.3). For previous work on this sort of thing, see
PEP 425 [1](and likely any existing multi-kernel, multi-arch package
manager). The Python folks also decided that fat binaries were more
trouble then they were worth 2.

Also, there is in the engine an arch field AFAIK:
https://github.com/docker/docker/pull/707/files

Ah good, but there's no kernel field (e.g. to distinguish “Windows
Server on amd64” from “Linux on amd64”).

[dmp42]

I kind of feel working this issue here is backward - the situation needs to be clarified first in the engine itself (you are right about both the "usage" and the kernel field).

[wking]

On Tue, Oct 28, 2014 at 03:04:52PM -0700, Olivier Gambier wrote:

I kind of feel working this issue here is backward - the situation
needs to be clarified first in the engine itself (you are right
about both the "usage" and the kernel field).

Sure. Should I open a new docker/docker issue, or should I summarize
our discussion here in moby/moby#8093?

[dmp42]

I guess a new issue altogether in docker is good - and see what core maintainers and shykes think about the future for this and the big picture about arch/kernel features.

[wking]

On Tue, Oct 28, 2014 at 03:43:47PM -0700, Olivier Gambier wrote:

I guess a new issue altogether in docker is good

Opened with moby/moby#8831, so we can probably close this.

[duglin]

I assume this is related to: moby/moby#8256 correct?

[dmp42]

@duglin close enough, yes

[stevvooe]

Superseded by distribution/distribution#200.