Bug 1230233 - Please build docker on all supported architectures
Summary: Please build docker on all supported architectures
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: docker
Version: 22
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ARMTracker ZedoraTracker PPCTracker ARM64, F-ExcludeArch-aarch64 F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2015-06-10 13:17 UTC by Stephen Gallagher
Modified: 2015-08-15 05:17 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-08-15 05:17:25 UTC


Attachments (Terms of Use)

Description Stephen Gallagher 2015-06-10 13:17:03 UTC
Description of problem:
Currently, Docker is built only for the x86_64 and armv7hl architectures. I presume this is mostly because these are the only platforms fully supported by the Docker Hub.

However, the Fedora Server would like to use the Docker framework (without the Hub) to generate Server Roles. To that end, we would like the Docker package to be compiled and available for all the architectures that Fedora supports

Version-Release number of selected component (if applicable):
docker-1.7.0-4.git5b82e1d.fc22

Comment 1 Dan Horák 2015-06-10 13:24:02 UTC
AFAIK for F-23 it is on the way with docker BuildRequires already updated to be multi-platform.

Comment 2 Stephen Gallagher 2015-06-10 13:28:00 UTC
(In reply to Dan Horák from comment #1)
> AFAIK for F-23 it is on the way with docker BuildRequires already updated to
> be multi-platform.

The list of BZs you linked misses i686 (which is my highest priority).

Comment 4 Dan Horák 2015-06-10 13:30:55 UTC
(In reply to Stephen Gallagher from comment #2)
> (In reply to Dan Horák from comment #1)
> > AFAIK for F-23 it is on the way with docker BuildRequires already updated to
> > be multi-platform.
> 
> The list of BZs you linked misses i686 (which is my highest priority).

aha, I see :-)

Comment 5 Peter Robinson 2015-06-10 14:13:22 UTC
> The list of BZs you linked misses i686 (which is my highest priority).

A bug in i686 was fixed over the weekend. It seems that docker actually bundles a bunch of golang libraries too which was partially the error there too.

Comment 6 Lokesh Mandvekar 2015-06-16 19:55:06 UTC
(In reply to Peter Robinson from comment #5)
> > The list of BZs you linked misses i686 (which is my highest priority).
> 
> A bug in i686 was fixed over the weekend. It seems that docker actually
> bundles a bunch of golang libraries too which was partially the error there
> too.

Peter, sorry what bug and error are you talking about? link please?

Comment 7 Peter Robinson 2015-06-16 20:28:43 UTC
(In reply to Lokesh Mandvekar from comment #6)
> (In reply to Peter Robinson from comment #5)
> > > The list of BZs you linked misses i686 (which is my highest priority).
> > 
> > A bug in i686 was fixed over the weekend. It seems that docker actually
> > bundles a bunch of golang libraries too which was partially the error there
> > too.
> 
> Peter, sorry what bug and error are you talking about? link please?

golang-github-vishvananda-netns

http://koji.fedoraproject.org/koji/buildinfo?buildID=643716

Comment 8 Adam Miller 2015-06-16 20:35:48 UTC
It turned out not to be a bug in the golang-github-vishvananda-netns package but that the version of golang-github-vishvananda-netns bundled within Docker is either old and broken or it's been altered from it's original upstream in a broken way. Either way it should be debundled.

On that topic, does Docker have a bundled library exception from FESCo?

If so this page needs updating, otherwise there's a whole pile of things that need fixing with this package.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Comment 9 Jan Chaloupka 2015-06-17 07:39:17 UTC
Hi Adam,

using bundled/debundled dependencies is one of open question about golang packaging [1].

Docker is not the only 'golang' package in Fedora building from bundled dependencies. It is just impossible to carry out daily builds of a package (to keep up with upstream) and at the same time build from debundled dependencies. Every update of docker's dependencies can break API and make docker unbuildable. Or it takes so much time which you don't have. As recently I have been updating libcontainer which took me about about 3 days. Why? New dependencies of libcontainer appeared. What has to be done? Create a spec file => review request => find someone who will do the review => SCM request => import srpm to all branches => build on all branches => update on all branches => buildroot override on all branches. Some dependencies need to be updated as well. Again, update spec files on all branches => build on all branches => ...

In general, for each project you need different commits of the same dependency which does not have to be backward compatible with each other. So at least one tools (docker, kubernetes, etcd, flannel, mongo-tools, ...) will not build. So sooner or later there will be more packages building from bundled dependencies.

Golang packages are 'just' not yet ready to be fully build only from debundled depencies. What am I doing about that? Trying to keep all dependencies up-to-date with kubernetes, cadvisor, etcd and every other tool I update. So one day 'maybe' API of all golang projects stabilize and there will be no backward compatibility violetions. Checkout out [2] to see for changes in API. The web is still under development but can give a good picture of changes in API (red are changes breaking API, green are extensions of API). E. g. kubernetes has a lot of 'red' changes in API [3].

[1] https://fedorahosted.org/fpc/ticket/382#comment:37
[2] http://10.3.11.63/
[3] http://10.3.11.63/stats/kubernetes.html

Regards
Jan

Comment 10 Adam Miller 2015-06-17 21:14:41 UTC
Oh, OK. The golang SIG/ecosystem is just blatantly disregarding Fedora guidelines in the mean time, got it.

Comment 11 Peter Robinson 2015-06-17 21:19:43 UTC
> will be no backward compatibility violetions. Checkout out [2] to see for
> changes in API. The web is still under development but can give a good
> picture of changes in API (red are changes breaking API, green are
> extensions of API). E. g. kubernetes has a lot of 'red' changes in API [3].
> 
> [1] https://fedorahosted.org/fpc/ticket/382#comment:37
> [2] http://10.3.11.63/
> [3] http://10.3.11.63/stats/kubernetes.html

10.x.x.x is a non routeable address space part of RFC-1918. This is a public BZ for Fedora, not some internal RHEL issue, please provide publicly accessible links for [2] and [3]

Comment 12 Jan Chaloupka 2015-06-18 11:20:43 UTC
Hi Peter,

yes, you are right. At the moment the web is still a proof of concept. Once it is finished it will go public.

Jan


Note You need to log in before you can comment on or make changes to this bug.