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>
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>
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>
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>
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>
I struggled to figure out why a machine create was failing, and
eventually asked if anyone else had seen the vague error I was getting:
"Error creating machine: Process exited with: 100. Reason was: ()"
It is immensely helpful if we log the command output instead of
just the rc.
It would also have been useful if the driver providers used the output, but
this covers most scenarios since they don't.
Signed-off-by: Christy Perez <christy@linux.vnet.ibm.com>
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>
