Requires #10660 to be merged first it has been merged

mmmm, interesting. atm, devicemapper 'works' on boot2docker - does this mean it will stop?

@SvenDowideit boot2docker will need udev, devicemapper and dynamically linked Docker binaries.

then lets dynamically link the binary that is used in b2d ...

please remember that today's b2d is a 32 bit userspace running on a 64 bit kernel, with some carefully written 8 bit shell scripts.

Though there is someone working on porting it to 64 bit userspace, we might also have to evaluate other options.

oh man

y, its positively amazing how many variations of systems Docker can run on.

makes sense to me. If we can't support device mapper functionality in static linking mode, it is better to disable it instead of dealing with constant stream of bugs. In fact even if a genuine bug comes along, first some energy is wasted in trying to rule out that it is not happening because of udev issues.

This needs to move forward. #4036 is getting a lot of comments from people using devicemapper with the static Docker binaries.

LGTM

BTW, if we disable this, what will be default storage graphdriver on static binary?

@rhvgoyal We'll have to discuss how we handle falling through to all other usable options (aufs, btrfs, overlay) and throw an error to make it clear that the requirements aren't met for any of the desirable graph drivers.

@rhvgoyal

INFO[0000] docker daemon: 1.4.1-dev 4a2f90e; execdriver: native-0.2; graphdriver: vfs 

@unclejack perhaps ^ should have a warning too?

@vbatts IMO, we should error out if we're down to vfs and we weren't told to use vfs explicitly. e.g.: Docker shouldn't use vfs if it's not told explicitly to use it and it should error out if falls through down to vfs because it couldn't use any of the better options.

@unclejack

So what's the downside of using vfs by default (if nothing better is available). IIUC, this probably means that there is no sharing between containers and there will be multiple copies of common data between containers?

If yes, IMHO, using vfs as last option by default is better than failing. We can put a big fat warning about data usage thing. Again, my view point is that one should be able to launch containers without much configuration and then figure out later how to tune it better to make it perform better and make storage efficient.

@rhvgoyal The problem with making vfs any kind of default is that most users won't notice it, nor will they know why that's a bad thing. The main point is that the first contact with Docker needs to be as painless as possible when the requirements are met. However, vfs shouldn't be used for anything other than testing. We've had some reports from users who were just starting and didn't know vfs shouldn't be used.

@unclejack

Ok. I am not aware of what user group downloads the pre-built static binaries and whether they already have support of aufs, btrfs or overlayfs or not. I hope not many people face this error.

So no objections from my side to error out on VFS. If too many people complain about it, we should
be able to change it again.

For people installing via https://get.docker.io, would it be possible to include the contrib/check-config.sh as part of the installation procedure?

@unclejack though it is curious, that even vfs is defaulted to instead of overlay for me. :-)

@vbatts https://github.com/docker/docker/blob/master/daemon/graphdriver/driver.go#L41 is the reason why it has precedence.

@unclejack oh right.

I am little concerned about testing of devicemapper driver with this patch. IIUC, we build static binary for our tests and now devicemapper not being built with static binary, it will not get any of the testing and might be completely broken soon.

So I would say that this requires little rethink.

I guess first there is a need to make automated testing work with dynamically build docker and with devicemapper and then one can disable compiling support of device mapper with static docker.

I added the 1.6.0 milestone because that is doable right? would we need @tianon help w everything after this is merged

@jfrazelle I have an idea, but I'm not sure it's a very good one... I'd like your thoughts on it.

If we swap the order at https://github.com/docker/docker/blob/620339f166984540f15aadef2348646eee9a5b42/project/make/.integration-daemon-start#L5 so that dynbinary is added to PATH before binary, then we could update https://github.com/docker/docker/blob/620339f166984540f15aadef2348646eee9a5b42/project/make.sh#L49-L55 so that we build binary, then run all the tests, then build dynbinary, then run test-integration-cli a second time, and that would actually work (and test against both static and non-static Docker).

Why exactly are you guys clinging to static builds? Some perceived cross distro utopia? One build to rule them all? Foolish. And to be clear: it is udev that doesn't support static builds; there is no static udev library.

@snitm Static builds are foolish in the context of linking udev+devicemapper into the binary. Having a Docker binary without dependencies on external libraries would be OK. That's one awesome thing about Go: when not linking against external libraries/code, you can just build a static binary to deploy it without additional dependencies. This is also awesome when making small Docker images with a single binary in them.

@unclejack no it is foolish because there could be distro specific capabilities/fixes available in the dynamic libraries that you shouldn't need to update docker to get. It also has the effect of making docker only as capable/strong as the weakest distro that Docker, Inc. supports. I'll grant you that normalizing docker's capabilities across all distros by throwing away features that don't conform to your misplaced definition of "awesome" makes for a much narrower support matrix. But given you're left with the inability to leverage exceptional distros' features/fixes: spinning static builds as anything but self-serving to Docker, Inc. is pretty disingenuous.

This PR was useful because of the conversations around it and because it helped lead to the final solution. However, the final solution is #11412 and this PR needs to be closed.