Docker 0.7rc5

[Solomon Hykes]

Hi all, just a quick note that docker 0.7rc5 is out. It's the first "real" release candidate - it's based  on the final storage driver API, and ships both an aufs and devmapper driver, with dynamic selection based on the capabilities of the system. This addresses the biggest issue which has delayed the release, which was the upgrade path for existing docker installations on aufs systems.

Michael wrote a quick guide here: https://github.com/crosbymichael/docker/blob/0.7.0-rc5/graphdriver/RC-README.md

0.7rc5 is also in sync with master and the numerous 0.6.x releases from the last couple weeks. As a reminder, every other feature initially planned for 0.7 has been released as a series of incremental 0.6.x releases.

Lastly, we upgraded our build scripts to make binary builds of docker first-class citizens. Distro maintainers, get in touch with tianon for details :)

There are still a few quirks to iron out, but are finally getting there.

Thanks for your patience everyone.

Solomon, Guillaume, Victor and Mike

[Brian Lalor]

On Thursday, November 14, 2013 8:56:29 PM UTC-5, Solomon Hykes wrote:

Hi all, just a quick note that docker 0.7rc5 is out. It's the first "real" release candidate - it's based  on the final storage driver API, and ships both an aufs and devmapper driver, with dynamic selection based on the capabilities of the system. This addresses the biggest issue which has delayed the release, which was the upgrade path for existing docker installations on aufs systems.

Michael wrote a quick guide here: https://github.com/crosbymichael/docker/blob/0.7.0-rc5/graphdriver/RC-README.md

This is great news!  I've been anxiously awaiting RedHat support.  I'm trying to get it running on CentOS 6.4 (kernel 2.6.32-358.14.1.el6.x86_64).  I had to build LXC from source but that was dead-simple.   When I try to start Docker, however, I get an error:

[root@centos6-dev tmp]# ./docker -d -D

2013/11/21 10:01:38 WARNING: You are running linux kernel version 2.6.32-358.14.1.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.

[/var/lib/docker|f5188be7] +job initapi()

[/var/lib/docker|f5188be7.initapi()] Creating server

[debug] driver.go:71 Error loading driver aufs: AUFS was not found in /proc/filesystems

[debug] deviceset.go:392 Generated prefix: docker-253:0-274157

[debug] deviceset.go:395 Checking for existence of the pool 'docker-253:0-274157-pool'

[debug] deviceset.go:230 loadMetadata()

[debug] deviceset.go:273 loadMetadata END

[debug] runtime.go:617 Using graph driver devicemapper

[debug] network.go:150 Creating bridge docker0 with network 172.17.42.1/16

[/var/lib/docker|f5188be7] -job initapi() = ERR (Error creating bridge: operation not supported)

2013/11/21 10:01:38 initapi: Error creating bridge: operation not supported

I have bridge-utils installed, but I'm thinking I'm either missing a kernel module, or maybe there's just something else going on.  Any thoughts?

[François Prud'homme]

I just made a test : same problem for me.

Actually, it seems brctl commands launched by docker are not well supported by centos.

To work, you have to do your own bridge and launch docker with "-b" option.

I may be wrong, but it's all i found in a few minutes (and it's work :))

[Nate Jones]

I just tried with centos 6.4 and docker 0.7.0 and I get the same error. I tried setting up the bridge myself, but my networking-fu is not very strong.

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Lalor]

On Nov 26, 2013, at 8:31 PM, Nate Jones <jus...@gmail.com> wrote:

I just tried with centos 6.4 and docker 0.7.0 and I get the same error. I tried setting up the bridge myself, but my networking-fu is not very strong.

Yeah, I have no idea how to go about setting up the bridge, nor what is required for the -b flag when starting Docker.  Can someone provide a walk-through?

--

Brian Lalor

bla...@bravo5.org

[Ben Evans]

OK, I am still very new to docker as a system, but my understanding of the fundamentals is that docker relies fairly heavily on features from version 3 of the Linux kernel.

CentOS ships with a rather old kernel, so you should probably upgrade. This blogpost may be useful: http://nareshv.blogspot.co.uk/2013/08/installing-dockerio-on-centos-64-64-bit.html

One other thing to be careful of, which I've run into when experimenting with CentOS & docker - the glibc version used by CentOS lags well behind what users coming from eg Ubuntu will probably expect. Neither is it feasible to expect to upgrade glibc and retain a stable system - so some caution is advised & some recompilation of third party dependencies should be anticipated & budgeted for.

Thanks,

Ben

[François Prud'homme]

After some time on it, this is what i done to have a running docker config on Centos 6.4 :

- yum install bridge-utils lxc (and hwloc / libcgroup maybe ?)

- Enable ipv4 forwarding ( "sysctl net.ipv4.ip_forward=1" & vi /etc/sysctl.conf)

- Disable cgconfig & cgred, add "none        /cgroup        cgroup        defaults    0    0" to /etc/fstab and mount /cgroup

- Add a bridged interface (with any ip address...). In my case i have a /etc/sysconfig/network-scripts/ifcfg-brdocker with :

DEVICE=brdocker

ONBOOT=yes

TYPE=Bridge

NETMASK=255.255.0.0

IPADDR=172.88.0.1

STP=off

DELAY=0

- Add masquerading on your main interface (and maybe docker :p) : iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

- Start docker : docker -d -b brdocker

All problems are related to bridging & iptables... need to have more comprehensive bridge error messages & a review of iptable processing

Hope all this can help :)

(sorry for my English... i'm french, and don't take the time to re-read...)

Le vendredi 15 novembre 2013 02:56:29 UTC+1, Solomon Hykes a écrit :

[Brian Lalor]

On Nov 27, 2013, at 6:25 AM, François Prud'homme <frapru...@gmail.com> wrote:

After some time on it, this is what i done to have a running docker config on Centos 6.4 :

- yum install bridge-utils lxc (and hwloc / libcgroup maybe ?)

- Enable ipv4 forwarding ( "sysctl net.ipv4.ip_forward=1" & vi /etc/sysctl.conf)

- Disable cgconfig & cgred, add "none        /cgroup        cgroup        defaults    0    0" to /etc/fstab and mount /cgroup

- Add a bridged interface (with any ip address...). In my case i have a /etc/sysconfig/network-scripts/ifcfg-brdocker with :

DEVICE=brdocker

ONBOOT=yes

TYPE=Bridge

NETMASK=255.255.0.0

IPADDR=172.88.0.1

STP=off

DELAY=0

- Add masquerading on your main interface (and maybe docker :p) : iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

- Start docker : docker -d -b brdocker

All problems are related to bridging & iptables... need to have more comprehensive bridge error messages & a review of iptable processing

Hope all this can help :)

(sorry for my English... i'm french, and don't take the time to re-read…)

François, that’s a great start.  Thank you!  I’m getting an error when trying to start a container, however:

[root@vagrant-centos64 ~]# docker run -i -t centos /bin/bash

Unable to find image 'centos' (tag: latest) locally

Pulling repository centos

539c0211cd76: Download complete

[error] commands.go:2470 Error resize: Error: bad file descriptor

I get the same error with the ubuntu and base images.

Furthermore, the docker daemon gives this warning when starting:

2013/11/27 12:59:25 WARNING: cgroup mountpoint not found for memory

The Docker version:

Client version: 0.7.0

Go version (client): go1.2rc5

Git commit (client): 0d078b6

I’ve captured this config so far in a Vagrantfile and associated bootstrap script.  Would you (or anyone, really) mind taking a look? https://github.com/blalor/vagrant-centos64-docker

And your English is perfect. :-)

--

Brian Lalor

bla...@bravo5.org

[François Prud'homme]

Check /cgroup mountpoint... and if cgconfig/cgred are correctly stopped.

Do a "mount /cgroup" manually and check if you have all cgroup files (cpuset.*, memory.*,...), if you have nothing or some folders like cpu/cpuset/memory/..., you have a problem here.

For information, in my "walk-throug" :

- if you create a "docker0" bridge (in place of "brdocker" in my example), you don't have to add "-b" on docker launch.

- IP masquerading is only necessary on bridged interface (docker0 now)

I test my config on a vagrant machine with centos 6.4 : it's work :) (problem to access external network... but it's a nat vagrant machine, with a bridge, with a nat... not very simple to see where is the problem ;))

(and hwloc/libcgroup are not needed)

[François Prud'homme]

New addition : leave masqerading for eth0.

If you want a "more proper" integration, here is an init script i find somewhere (infinitly sorry for the author... don't remember where). I just add iptable lines :

-----------------------------

#!/bin/bash

### BEGIN INIT INFO

# INIT INFO

# Provides:          docker

# Required-Start:    networking

# Required-Stop:     networking

# Default-Start:     2 3 4 5

# Default-Stop:      0 1 6

# Short-Description: docker

# Description:       docker

### END INIT INFO

. /etc/init.d/functions

NAME=docker

PID_FILE="/var/run/${NAME}.pid"

DELAY=0

status_q() {

  status -p $PID_FILE $NAME > /dev/null

  return $?

}

start_app() {

   nohup /usr/bin/docker -d >/var/log/docker.log 2>&1 </dev/null &

   return $?

}

check_config() {

   # Do not start if there is no config file.

   # [ ! -f "$CONFIG_FILE" ] && return 6

   return 0

}

start() {

        status_q; res=$?

  if [ $res -eq 3 ]; then

           echo -n $"$NAME starting..."

           start_app

           iptables -t nat -A POSTROUTING -o docker0 -j MASQUERADE

           iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

           echo $! > $PID_FILE

           [ $DELAY -gt 0 ] && sleep $DELAY

           status_q; res=$?

           [ $res -eq 0 ] && success || failure

           echo

        elif [ $res -eq 0 ]; then

           success; echo "$NAME is already running"

        else

           failure; echo "$NAME is not running, res: $res"

        fi

        return $res

}

stop() {

        status_q; res=$?

        if [ $res -eq 3 ]; then

           success && echo "$NAME is not running"

        else

           killproc -p $PID_FILE; res=$?

           iptables -t nat -D POSTROUTING -o docker0 -j MASQUERADE

           iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

           if [ $res -eq 0 ]; then

             rm -f PID_FILE

             success && echo "$NAME has been stopped"

           else

             failure && echo "$NAME cannot be stopped ($res)"

           fi

        fi

        return $res

}

case $1 in

  start)

           start

           exit $?

  ;;

  stop)

           stop

           exit $?

  ;;

  status)

     echo -n $"$NAME running..."

           status_q; res=$?

     [ $res -eq 0 ] && success || failure

     echo

           exit $res

  ;;

  restart)

           stop

           start

           exit $?

  ;;

  *)

    echo "Usage: $0 {start|stop|restart|status}"

    exit 2

    ;;

esac

---------------------------------

[Brian Lalor]

Without libcgroup, /cgroup doesn’t exist (but I can create and mount it manually), and the cgconfig/cgred services don’t exist.  Additionally, when I try to run a Docker container without libcgroup installed I get a new error:

lxc-start: Error creating cgroups

That’s in addition to “Error: bad file descriptor”.

If I restart the instance after running my bootstrap script and then try to run a docker container, I get the “error creating cgroups” again.  The postinstall script for libcgroup doesn’t appear to actually start the service, so I’m not sure why a reboot would change that behavior.

With /cgroup mounted I do have cpuset.* and memory.*; there are no sub-directories under /cgroup.  So that all looks fine.

The initial startup output from the docker daemon looks innocuous:

2013/11/27 14:20:28 WARNING: You are running linux kernel version 2.6.32-358.23.2.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.

[/var/lib/docker|37948c53] +job initapi()

[/var/lib/docker|37948c53.initapi()] Creating server

Loading containers: done.

[/var/lib/docker|37948c53.initapi()] Creating pidfile

[/var/lib/docker|37948c53.initapi()] Setting up signal traps

[/var/lib/docker|37948c53] Register(create) (handlers=map[initapi:0x49ceb0])

[/var/lib/docker|37948c53] Register(start) (handlers=map[initapi:0x49ceb0 create:0x4bbb90])

[/var/lib/docker|37948c53] Register(serveapi) (handlers=map[initapi:0x49ceb0 create:0x4bbb90 start:0x4bbbf0])

[/var/lib/docker|37948c53] -job initapi() = OK (0)

[/var/lib/docker|37948c53] +job serveapi(unix:///var/run/docker.sock)

2013/11/27 14:20:28 Listening for HTTP on /var/run/docker.sock (unix)

I get the following output from the docker daemon on a failed “docker run”:

2013/11/27 14:19:02 POST /v1.7/containers/create

[/var/lib/docker|95d3f3ff] +job create()

cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc

[/var/lib/docker|95d3f3ff] -job create() = OK (0)

2013/11/27 14:19:02 POST /v1.7/containers/cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc/attach?stderr=1&stdin=1&stdout=1&stream=1

2013/11/27 14:19:02 POST /v1.7/containers/cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc/start

[/var/lib/docker|95d3f3ff] +job start(cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc)

[/var/lib/docker|95d3f3ff] -job start(cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc) = OK (0)

2013/11/27 14:19:03 POST /v1.7/containers/cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc/resize?h=26&w=80

[error] api.go:1034 Error: bad file descriptor

[error] api.go:82 HTTP Error: statusCode=500 bad file descriptor

2013/11/27 14:19:03 GET /v1.7/containers/cc70d0b82d122b43c09ae475e71bb035b449d33015a92fbb99a0aa979a0cb2bc/json

I’m not worrying about masquerading at this point, as I can’t even get the container to start. :-(

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Brian Lalor

bla...@bravo5.org

[forti]

Hi Brian,
you have to update to latest lxc version from github.

I got same results as you when using the "epel testing" lxc package.
Repackaging lxc from github solved the cgroups problem.

François, thank you for bridge tip :)

Best Regards,
forti

[Brian Lalor]

On Nov 27, 2013, at 11:24 AM, forti <for...@gmail.com> wrote:

you have to update to latest lxc version from github.

I got same results as you when using the "epel testing" lxc package.
Repackaging lxc from github solved the cgroups problem.

François, thank you for bridge tip :)

SUCCESS!!!

There’s a warning when creating a container, but it still starts:

[root@vagrant-centos64 ~]# docker run -i -t base /bin/bash

Unable to find image 'base' (tag: latest) locally

Pulling repository base

b750fe79269d: Download complete

27cf78414709: Download complete

lxc-start: Does this kernel version support 'attach'?

lxc-start: Function not implemented - failed to set namespace 'mnt'

This is awesome!  Thank you forti and François!!

--

Brian Lalor

bla...@bravo5.org

[Brian Pitts]

On Wednesday, November 27, 2013 10:24:21 AM UTC-6, forti wrote:

Hi Brian,
you have to update to latest lxc version from github.

I got same results as you when using the "epel testing" lxc package.
Repackaging lxc from github solved the cgroups problem.

I'm puzzled by this. Does docker now depend on an unreleased version of the lxc userspace tools, or is there something wrong with the packaging that building from source fixes?

The version in the testing repos for fedora and epel is 0.9.0, and that's the latest released version I see at linuxcontainers.org.

[Solomon Hykes]

On Wed, Nov 27, 2013 at 12:07, Brian Pitts <br...@polibyte.com="mailto:br...@polibyte.com">> wrote:

On Wednesday, November 27, 2013 10:24:21 AM UTC-6, forti wrote:

Hi Brian,
you have to update to latest lxc version from github.

I got same results as you when using the "epel testing" lxc package.
Repackaging lxc from github solved the cgroups problem.

I'm puzzled by this. Does docker now depend on an unreleased version of the lxc userspace tools, or is there something wrong with the packaging that building from source fixes?

​

No, docker does not rely on an unreleased version of lxc. Whatever problem you're seeing is packaging-related.

We (docker maintainers) are working on a better integration testing tool to validate each release on a matrix of distros / versions of lxc etc.

The version in the testing repos for fedora and epel is 0.9.0, and that's the latest released version I see at linuxcontainers.org.

--

[François Prud'homme]

I just check my version of lxc... and understand : it's 0.8 from rpmforge

For information (more speed than a google search) : rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

(and i have no hwloc/libcgroup installed on my systems)

Seems this version have no problem... to resume in very short (and dirty because without consistent modification... i just test these on a fresh vagrant centos 6.4) :

rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

yum install lxc bridge-utils

sysctl net.ipv4.ip_forward=1

echo "none        /cgroup        cgroup        defaults    0    0" >> /etc/fstab

mkdir /cgroup ; mount /cgroup

brctl addbr docker0; ifconfig docker0 172.88.0.1 netmask 255.255.0.0 up

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables -t nat -A POSTROUTING -o docker0 -j MASQUERADE

iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited

iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited^

wget http://get.docker.io/builds/Linux/x86_64/docker-latest.tgz ; tar zxf docker-latest.tgz

usr/local/bin/docker -d

2013/11/27 21:04:01 WARNING: You are running linux kernel version 2.6.32-358.el6.x86_64, which might be unstable running docker. Please upgrade your kernel to 3.8.0.

[/var/lib/docker|958d6904] +job initapi()

[/var/lib/docker|958d6904.initapi()] Creating server

Loading containers: done.

[/var/lib/docker|958d6904.initapi()] Creating pidfile

[/var/lib/docker|958d6904.initapi()] Setting up signal traps

[/var/lib/docker|958d6904] Register(create) (handlers=map[initapi:0x49ceb0])

[/var/lib/docker|958d6904] Register(start) (handlers=map[initapi:0x49ceb0 create:0x4bbb90])

[/var/lib/docker|958d6904] Register(serveapi) (handlers=map[initapi:0x49ceb0 create:0x4bbb90 start:0x4bbbf0])

[/var/lib/docker|958d6904] -job initapi() = OK (0)

[/var/lib/docker|958d6904] +job serveapi(unix:///var/run/docker.sock)

2013/11/27 21:04:05 Listening for HTTP on /var/run/docker.sock (unix)

On another terminal (move binary on your path for easy access...) :

docker run -i -t base /bin/bash

No error, no problem, no stress... just pleasure ^_^ :

[root@localhost /]# docker run -i -t base /bin/bash

Unable to find image 'base' (tag: latest) locally

Pulling repository base

b750fe79269d: Download complete

27cf78414709: Download complete

root@a629994dfc09:/# apt-get update

Ign http://archive.ubuntu.com quantal InRelease

Hit http://archive.ubuntu.com quantal Release.gpg

Hit http://archive.ubuntu.com quantal Release

Hit http://archive.ubuntu.com quantal/main amd64 Packages

Get:1 http://archive.ubuntu.com quantal/universe amd64 Packages [5274 kB]

Get:2 http://archive.ubuntu.com quantal/multiverse amd64 Packages [131 kB]

Get:3 http://archive.ubuntu.com quantal/main Translation-en [660 kB]

Get:4 http://archive.ubuntu.com quantal/multiverse Translation-en [100 kB]

Get:5 http://archive.ubuntu.com quantal/universe Translation-en [3648 kB]

Fetched 9813 kB in 2min 27s (66.4 kB/s)

Reading package lists... Done

root@a629994dfc09:/# apt-get install nyancat

Reading package lists... Done

Building dependency tree... Done

The following NEW packages will be installed:

  nyancat

0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Need to get 13.4 kB of archives.

After this operation, 79.9 kB of additional disk space will be used.

Get:1 http://archive.ubuntu.com/ubuntu/ quantal/universe nyancat amd64 1.0+git20120523.99dc310-1 [13.4 kB]

Fetched 13.4 kB in 0s (44.4 kB/s)

Selecting previously unselected package nyancat.

(Reading database ... 9893 files and directories currently installed.)

Unpacking nyancat (from .../nyancat_1.0+git20120523.99dc310-1_amd64.deb) ...

Setting up nyancat (1.0+git20120523.99dc310-1) ...

root@a629994dfc09:/# nyancat

Nyanyanyanyanyanyanya...

Hope it can help ^_^

[Brian Pitts]

On Wednesday, November 27, 2013 2:20:16 PM UTC-6, Solomon Hykes wrote:

On Wed, Nov 27, 2013 at 12:07, Brian Pitts wrote:

On Wednesday, November 27, 2013 10:24:21 AM UTC-6, forti wrote:

Hi Brian,
you have to update to latest lxc version from github.

I got same results as you when using the "epel testing" lxc package.
Repackaging lxc from github solved the cgroups problem.

I'm puzzled by this. Does docker now depend on an unreleased version of the lxc userspace tools, or is there something wrong with the packaging that building from source fixes?

​

No, docker does not rely on an unreleased version of lxc. Whatever problem you're seeing is packaging-related.

I verified it's working fine with lxc 0.9.0 in Fedora 20. I haven't had time to play with docker 0.7 in EL6 yet. Brian Laior or forti, consider reporting your problems as bugs against the docker-io package in EPEL.

https://bugzilla.redhat.com/buglist.cgi?component=docker-io&list_id=1949633&product=Fedora%20EPEL

[François Prud'homme]

Just to conclude this topic (because we are on dev group and not user group ;)) for docker devs :

- Please add a more clear error messages for bridge problem (say to use -b with a manually done bridge for example)

- Check the way you are trying to make the bridge : "ip link add docker0 type bridge" is not well supported in centos/redhat... use "brctl addbr docker0" instead

And add a note in readme :

- Have a clear check of iptables update (i don't know why masquerade rule are not present in centos...)

- net.ipv4.ip_forward=1

- /cgroup check

In fact... it's very few things for a first release ! ^_^

Thanks to all people have make Docker on all systems real !!!!! :D

[forti]

Hi,
indeed there was never lxc package for RHEL6 ;)
All involved look really busy to get it all working, thank you.

On Wednesday, November 27, 2013 9:07:05 PM UTC+1, Brian Pitts wrote:

I'm puzzled by this. Does docker now depend on an unreleased version of the lxc userspace tools, or is there something wrong with the packaging that building from source fixes?

The version in the testing repos for fedora and epel is 0.9.0, and that's the latest released version I see at linuxcontainers.org. ners support to the

[Solomon Hykes]

FYI, Red Hat and Ubuntu have different preferences regarding execution backend for Docker. Ubuntu prefers the lxc scripts, and Red Hat prefers libvirt. We are working on a pluggable driver API to make these options interchangeable, and add more options while we're at it (openvz, basic chroot for older machines, and why not bsd jails and solaris zones down the road). This is similar to how we've handled the choice of storage backends. We will apply the same strategy to all other possible customizations: networking, monitoring, orchestration, etc.

--

[Brian Lalor]

On Nov 27, 2013, at 5:16 PM, Solomon Hykes <s...@docker.com> wrote:

> FYI, Red Hat and Ubuntu have different preferences regarding execution backend for Docker. Ubuntu prefers the lxc scripts, and Red Hat prefers libvirt. We are working on a pluggable driver API to make these options interchangeable, and add more options while we're at it (openvz, basic chroot for older machines, and why not bsd jails and solaris zones down the road). This is similar to how we've handled the choice of storage backends. We will apply the same strategy to all other possible customizations: networking, monitoring, orchestration, etc.

Do you have any insight into how Docker’s going to be supported in RHEL 6.5? I’m assuming that announcement meant RHEL6.5 would be able to act as a *host*.

--
Brian Lalor
bla...@bravo5.org

[Solomon Hykes]

Yes, that's correct, the goal is for RHEL6.5 to be a supported docker host (supported both by Docker and Red Hat).

We are also talking to the Fedora maintainers to get an official Fedora base container into the docker index. Once that's in place, it's up to Red Hat whether they want to actually offer support for RHEL-based containers. I can't speak for them on that point.

[Brian Lalor]

On Nov 27, 2013, at 5:34 PM, Solomon Hykes <s...@docker.com> wrote:

Yes, that's correct, the goal is for RHEL6.5 to be a supported docker host (supported both by Docker and Red Hat).

That is awesome news.  

--

Brian Lalor

bla...@bravo5.org

[Ben Evans]

On Wed, Nov 27, 2013 at 10:34 PM, Solomon Hykes <s...@docker.com> wrote:

On Wed, Nov 27, 2013 at 2:25 PM, Brian Lalor <bla...@bravo5.org> wrote:

Do you have any insight into how Docker’s going to be supported in RHEL 6.5?  I’m assuming that announcement meant RHEL6.5 would be able to act as a *host*.

Yes, that's correct, the goal is for RHEL6.5 to be a supported docker host (supported both by Docker and Red Hat).

Are you able to speak publicly about what the position on kernels is going to be? And if RHEL 6.5 is getting a modern kernel, is there any possibility of a glibc upgrade as well? 

This has been a major stumbling block for me to work with docker on RHEL 6.4 - and a clear roadmap would be very useful as I evaluate docker as a potential PROD management tool.

Thanks,

Ben

[Brian Lalor]

On Nov 28, 2013, at 7:40 AM, Ben Evans <b...@improbableworlds.net> wrote:

Are you able to speak publicly about what the position on kernels is going to be? And if RHEL 6.5 is getting a modern kernel, is there any possibility of a glibc upgrade as well? 

I would be floored if they did more than a minor version bump to the kernel or glibc.  RHEL6 for enterprise folks who want a super-stable release.  Seems to me like a major bump to either of those things would cause some serious consternation among their customers.

This has been a major stumbling block for me to work with docker on RHEL 6.4 - and a clear roadmap would be very useful as I evaluate docker as a potential PROD management tool.

What’re the issues with glibc?

--

Brian Lalor

bla...@bravo5.org

[Ben Evans]

On Thu, Nov 28, 2013 at 12:42 PM, Brian Lalor <bla...@bravo5.org> wrote:

On Nov 28, 2013, at 7:40 AM, Ben Evans <b...@improbableworlds.net> wrote:

Are you able to speak publicly about what the position on kernels is going to be? And if RHEL 6.5 is getting a modern kernel, is there any possibility of a glibc upgrade as well? 

I would be floored if they did more than a minor version bump to the kernel or glibc.  RHEL6 for enterprise folks who want a super-stable release.  Seems to me like a major bump to either of those things would cause some serious consternation among their customers.

Well, precisely.

 

This has been a major stumbling block for me to work with docker on RHEL 6.4 - and a clear roadmap would be very useful as I evaluate docker as a potential PROD management tool.

What’re the issues with glibc?

If memory serves, CentOS 6.4 ships with glibc 2.12 - so anything which has been compiled on a more recent system (notably recent Ubuntu) fails to link & has to be recompiled. Many of the libraries available in yum are very outdated, so they usually need to be recompiled from source too. And then there are the vendor libraries for which source is not available. In short, not very nice.

Cheers,

Ben

[Brian Lalor]

I'm not trying to be rude, but I don't see how this is a problem. With support for RHEL as a *host*, none of that matters. You can create a Fedora 19 container and use the latest stuff all you want, completely separate from the host. Am I missing something?

--

Brian Lalor

bla...@bravo5.org

[Ben Evans]

On Thu, Nov 28, 2013 at 1:00 PM, Brian Lalor <bla...@bravo5.org> wrote:

I'm not trying to be rude, but I don't see how this is a problem. With support for RHEL as a *host*, none of that matters. You can create a Fedora 19 container and use the latest stuff all you want, completely separate from the host. Am I missing something?

I suspect we care about different things. I'm interested in production systems that actually matter, not development machines - and I'm trying to evaluate whether docker is suitable / mature enough for my use case yet. 

I think we should also probably terminate this thread on docker-dev, as I'm increasingly not sure it's an appropriate place for it - accordingly, have moved it to Bcc - although I'm happy to continue the discussion with anyone suitably inclined.

Ben

[Brian Lalor]

On Nov 27, 2013, at 4:47 PM, François Prud'homme <frapru...@gmail.com> wrote:
>
> In fact... it's very few things for a first release ! ^_^
> Thanks to all people have make Docker on all systems real !!!!! :D

I agree. This is very well done!

[Matthew Miller]

On Thursday, November 28, 2013 8:07:51 AM UTC-5, Ben Evans wrote:

On Thu, Nov 28, 2013 at 1:00 PM, Brian Lalor <bla...@bravo5.org> wrote:

I'm not trying to be rude, but I don't see how this is a problem. With support for RHEL as a *host*, none of that matters. You can create a Fedora 19 container and use the latest stuff all you want, completely separate from the host. Am I missing something?

I suspect we care about different things. I'm interested in production systems that actually matter, not development machines - and I'm trying to evaluate whether docker is suitable / mature enough for my use case yet.

Depending on your exact needs for production systems, Fedora may actually be appropriate, and we're working on making it even more so. Fedora isn't just for development. If you would like to talk about exactly how Fedora isn't fitting your needs in this case, maybe we can find a way to fix that.

[Josh Poimboeuf]

On Thu, Nov 21, 2013 at 07:04:19AM -0800, Brian Lalor wrote:
> This is great news! I've been anxiously awaiting RedHat support. I'm
> trying to get it running on CentOS 6.4 (kernel 2.6.32-358.14.1.el6.x86_64).
> I had to build LXC from source but that was dead-simple. When I try to
> start Docker, however, I get an error:

[snip]

> 2013/11/21 10:01:38 initapi: Error creating bridge: operation not supported
>
> I have bridge-utils installed, but I'm thinking I'm either missing a kernel
> module, or maybe there's just something else going on. Any thoughts?

FYI, this issue is now fixed upstream with commit 7a94cdf. And also in
the latest docker-io EL6 EPEL RPM.


Josh

[Niklas Molin]

Hi Forti.

Which LXC version do I have to use to fix this problem?

Thanks,

Niklas

[Brian Lalor]

The docker-io package in EPEL requires lxc 0.9.0, which is also in EPEL.  This is a working combination.

--
You received this message because you are subscribed to the Google Groups "docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to docker-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Brian Lalor

bla...@bravo5.org

[Oleksiy Kovyrin]

We've been using Docker on our new CI server for a few weeks now on Centos 6.4 and it's been working great. Today we've upgraded to Centos 6.5 and along the way with the OS upgrade we've managed to upgrade lxc from 0.8.0 (rpmforge) to 0.9.0 (epel). And that broke Docker. We have started getting messages like these:

[ro...@stage02.dal05 docker]# docker run -i -t centos /bin/bash
lxc-start: Error creating cgroups
lxc-start: failed to spawn 'ffd4482f5c4a093b7a7be4d585e76ed28293c21aa6ef4b9473c018b6aaba6c4c'
[error] commands.go:2445 Error getting size: bad file descriptor

I've downgraded lxc to 0.8.0 now and it works again. So, there is clearly something going on with lxc after 0.8.0 and 0.9.0 from EPEL does not seem to be working (at least for us).

[Brian Lalor]

On Dec 18, 2013, at 3:04 AM, Oleksiy Kovyrin <ale...@kovyrin.net> wrote:

We've been using Docker on our new CI server for a few weeks now on Centos 6.4 and it's been working great. Today we've upgraded to Centos 6.5 and along the way with the OS upgrade we've managed to upgrade lxc from 0.8.0 (rpmforge) to 0.9.0 (epel). And that broke Docker. We have started getting messages like these:

[ro...@stage02.dal05 docker]# docker run -i -t centos /bin/bash
lxc-start: Error creating cgroups
lxc-start: failed to spawn 'ffd4482f5c4a093b7a7be4d585e76ed28293c21aa6ef4b9473c018b6aaba6c4c'
[error] commands.go:2445 Error getting size: bad file descriptor

I've downgraded lxc to 0.8.0 now and it works again. So, there is clearly something going on with lxc after 0.8.0 and 0.9.0 from EPEL does not seem to be working (at least for us).

Are you using the docker-io package from EPEL?  Did you start the cgroups service?  I know next to nothing about lxc but it seems conceivable to me that there’s something incompatible between versions in in /var/lib/docker.

--

Brian Lalor

bla...@bravo5.org

[Vincent Batts]

Are you using the same version of docker? Is it the epel build or did you build it yourself?

That error output looks familiar. I know there were changes around the 0.7.0 release of docker that needed /var/lib/docker to be cleaned out. Perhaps 'save' your images while it is working. Rm  /var/lib/docker, do the upgrade again, and then 'load' the images again.

[Oleksiy Kovyrin]

I was using EPEL’s RPM when we broke it. Then, while trying to understand what was going on I’ve tried to upgrade the binary to 0.7.2 - that didn’t help. Then I’ve cleaned up /var/lib/docker and tried again - no luck. And then I’ve found this thread and it led me to looking into the list of upgraded packages and trying to downgrade lxc. I don’t want to break our CI again today, but I will try to reproduce the issue on another server and will let you guys know how it goes.

-- 

Oleksiy Kovyrin

http://kovyrin.net/

[Josh Poimboeuf]

On Wed, Dec 18, 2013 at 12:04:21AM -0800, Oleksiy Kovyrin wrote:
> We've been using Docker on our new CI server for a few weeks now on Centos
> 6.4 and it's been working great. Today we've upgraded to Centos 6.5 and
> along the way with the OS upgrade we've managed to upgrade lxc from 0.8.0
> (rpmforge) to 0.9.0 (epel). And that broke Docker. We have started getting
> messages like these:
>
> [ro...@stage02.dal05 docker]# docker run -i -t centos /bin/bash
> lxc-start: Error creating cgroups
> lxc-start: failed to spawn 'ffd4482f5c4a093b7a7be4d585e76ed28293c21aa6ef4b9473c018b6aaba6c4c'
> [error] commands.go:2445 Error getting size: bad file descriptor
>
>
> I've downgraded lxc to 0.8.0 now and it works again. So, there is clearly
> something going on with lxc after 0.8.0 and 0.9.0 from EPEL does not seem
> to be working (at least for us).

What's the output of "grep cgroup /proc/mounts"? I've noticed that
lxc-start sometimes gets confused by non-standard cgroup mount
locations.


Josh

[Oleksiy Kovyrin]

[ro...@stage02.dal05 data]# grep cgroup /proc/mounts

none /cgroup cgroup rw,relatime,net_prio,perf_event,blkio,net_cls,freezer,devices,memory,cpuacct,cpu,ns,cpuset 0 0

-- 

Oleksiy Kovyrin

http://kovyrin.net/

On Dec 18, 2013, at 1:02 PM, Josh Poimboeuf <jpoi...@redhat.com> wrote:

grep cgroup /proc/mounts

[Vincent Batts]

ah! that is why this error looked familiar. Lxc has issues when the controllers are mounted in an 'all' fashion.

There is now an issue opened for this upstream (https://github.com/lxc/lxc/issues/110), please comment on there.

But also, we opened a bug to track this as well https://bugzilla.redhat.com/show_bug.cgi?id=1038775

For now, this is what my rhel65 box looks like, to get this working.

$ grep cgroup /proc/mounts 

cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0

cgroup /cgroup/cpu cgroup rw,relatime,cpu 0 0

cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0

cgroup /cgroup/memory cgroup rw,relatime,memory 0 0

cgroup /cgroup/devices cgroup rw,relatime,devices 0 0

cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0

cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0

cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0

My /etc/cgconfig.conf looks like this:

mount {

        cpuset  = /cgroup/cpuset;

        cpu     = /cgroup/cpu;

        cpuacct = /cgroup/cpuacct;

        memory  = /cgroup/memory;

        devices = /cgroup/devices;

        freezer = /cgroup/freezer;

        net_cls = /cgroup/net_cls;

        blkio   = /cgroup/blkio;

}

If you change your mounts, it requires a reboot.

Take care,

vb