If firewalld is not installed (or I suppose not running), firewalld was
producing an error in the daemon init logs, even though firewalld is not
required for iptables stuff to function.
The firewalld library code was also logging directly to logrus instead
of returning errors.
Moved logging code higher up in the stack and changed firewalld code to
return errors where appropriate.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 38b5c7266a14c34624bba532cb74d8b2ae46c726
Component: engine
I believe this was failing because 'nc' wouldn't show the data
it received sometimes. So intead of looking for that data we now
look for the output of the echo that comes after the nc command
successfully runs
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 769df832a39e2507fb46cb8896666a1c3197ff0b
Component: engine
Generation based on CAP_LAST_CAP, I hardcoded
capability.CAP_BLOCK_SUSPEND as last for systems which has no
/proc/sys/kernel/cap_last_cap
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: a559c1145af3162cd683866fd6f998ff5f57058f
Component: engine
It adds List function for listing all supported caps
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 5a2d592c27e93cf7f3d01216cf6e22656330fe84
Component: engine
The docker graph call driver.Exists() on initialisation for each filesystem in
the graph. This results will results in a lot `zfs get all` commands. To reduce
this, retrieve all descend filesystem at startup and cache it for later checks
Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Upstream-commit: bad25ccf978b56da6fa181439504ab33906524cd
Component: engine
instead of let zfs automaticly mount datasets, mount them on demand using mount(2).
This speed up this graph driver in 2 ways:
- less zfs processes needed to start a container
- /proc/mounts get smaller, so zfs userspace tools has less to read (which can
a significant amount of data as the number of layer grows)
This ways it can be also ensured that the correct mountpoint is always used.
Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Upstream-commit: 11e9167a6b45fdc134ee43e89abefd34a85cf624
Component: engine
Previously, we've taken advantage of the fact that libcontainer's `update-vendor.sh` is the same syntax as Docker's `vendor.sh` with some shell magic. This changes that to copy libcontainer's dependencies into this file explicitly so that we can scale to more projects with varying methods of vendoring (assuming they don't use import re-writing, which screws up everyone).
We'll need to stay diligent in making sure this list matches what's in libcontainer's `update-vendor.sh` (minus the not-required codegangsta/cli dep), but that's a fair trade-off for being able to scale our dependency model better (and track new discrete dependencies more directly).
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: b919dee8347a47763d576136254bcbc922ef4c57
Component: engine
Before this PR the list of commands that were printed for the help
text was statically put into the flags.Usage() function via main.init(). This
made it impossible to modify later on when we add new commands
via plugins.
This PR moves the list of commands (name & description) into a structure
that is sorted and printed dynamically by the Usage func. This will allow
the code to add to the list of commands after the init() func is done
but before the help text is printed for the user.
This just moves code around - it should have no UX impact at all.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 4f00b1020e8bf28d5d3dfb88730894888666fd9a
Component: engine
