Docker base image naming for non-x86_64

[Vincent Batts]

On 06/06/15 16:40 -0400, Colin Walters wrote:
>On Tue, Jun 2, 2015, at 11:02 AM, Adam Miller wrote:
>> Hello all,
>>     There was recently a thread on the Fedora ARM mailing list[0]
>> about getting a Fedora ARM image into the official Docker Hub. That
>> discussion lead down the trail of how to best handle the naming for
>> all of this.
>>
>> The current questions are either using Fedora's namespace and just
>> making a new image (using Fedora ARM as an example), this would be the
>> "FROM" line for a Dockerfile
>>
>>     FROM fedora/armhfp
>
>Upstream Docker does have an Architecture metadata field.
>
>I'd imagine there is some possibility to teach the client how to pull
>the right base image based on an architecture.
>
>There's probably some discussion of this somewhere upstream?
>I'm CC'ing Vincent who might know.

this is a rough process. The client and registry work fine, on a given
arch, but not sharing. Upstream has talked of making an arm.docker.io as
a stop gap, but the problem needs to be fixed in the manifest and
registry API. This discussion always tends to end with "we'll do more
for this in the next release cycle". :-\

>Or at least, detect when you pull an incompatible image?
>
>It'd be good to coordinate this with other distributions like Debian
>too - what patterns are they using?
>
>I think what might be nicest is if the architecture became an implicit
>3rd field or something?
>
>So if I did:
>
>docker pull fedora:22 from an x86_64 host I got x86_64 (or
>amd64 in Debian terms),
>
>But it should be *possible* to do:
>docker pull fedora:22:arm64 or whatever on x86_64, even if
>it won't actually run.

feel free to open the topic on
https://groups.google.com/forum/#!forum/docker-dev

IBMers and others would gladly pile in on the topic.

vb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150608/095b6485/attachment.sig>