Since docker container names can be long, we should permit a partial, unique container name to be specified to all commands that accept a container id.

Blocked on lack of network support.

See https://github.com/opencontainers/runtime-spec/blob/master/config.md#hostname

In order to avoid the large number of clr_oci_replace_string() calls.

Specifically, process.user.uid, process.user.gid and process.additionalGids are ignored.

See:

• clr_oci_create_container_workload() in src/oci.c.
• https://github.com/opencontainers/runtime-spec/blob/master/config.md#user.

make functional-test should run as a non-root user, but if you try that now, you get this error:

 2016-08-08T17:42:05.062873Z:15654:cc-oci-runtime:critical:failed to run prestart hooks

   2016-08-08T17:42:05.064133Z:15654:cc-oci-runtime:critical:Failed to create tap [cwlp3s0] [Operation not permitted]

   2016-08-08T17:42:05.064164Z:15654:cc-oci-runtime:critical:failed to create network

   2016-08-08T17:42:05.064193Z:15654:cc-oci-runtime:critical:failed to launch VM

The runtime should detect if it is being run as a non-root user and disable network setup in that scenario along with a warning message that networking is disabled.

imo and experience the next files must be removed:

• Makefile.in
• aclocal.m4
• compile
• config.guess
• config.h.in
• config.sub
• configure
• depcomp
• install-sh
• ltmain.sh
• m4/libtool.m4
• m4/ltoptions.m4
• m4/ltsugar.m4
• m4/ltversion.m4
• m4/lt~obsolete.m4
• missing
• test-driver

these files must be auto-generated by autogen.sh in order to avoid conflicts like this:
$ ./configure
$ make
missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
http://www.gnu.org/software/automake
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
http://www.gnu.org/software/autoconf
http://www.gnu.org/software/m4/
http://www.perl.org/
Makefile:1347: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 127

We need better integration with clear linux, automatically testing we can create a bundle in Travis seems like a good start, reducing the bad surprises downstream can have. Hopefully it is possible to do it outside of Intel.

For that, I'd isolate the bundle build into its own Dockerfile so we can easily develop and reproduce the bundle build locally. It'd be a shame no to do that considering the project.

Currently is not possible to map a specific port to a container.
It should be possible to do something like this
docker-upstream port test 8080

'Ctrl+O + Enter' shows next message:
[ 2.002964] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w)

this makes difficult to save a file from nano

On clear linux I am unable to launch a container with an attached volume.
This failure is present both with runc and cors

docker-upstream run -it --runtime runc --name webxx -v /webappxx training/webapp python app.py
docker-upstream run -it runc --name webyy -v /webappyy training/webapp python app.py

Both these fail with the error
docker-upstream: An error occurred trying to connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=webxx: EOF.

The same command works on ubuntu

The current networking implementation support bridge networking.

We need to support at least one overlay network framework. The first overlay network we need to enable is swarm with the current integration bridge approach if possible.

ps command has not implementation

We need to figure out how to build cc-oci-runtime within travis environment.

The following message shows up on container launch even though the hostname is setup correctly

[ 0.076952] systemd[1]: Failed to initialise default hostname

sudo docker-upstream run -it debian
[ 0.076952] systemd[1]: Failed to initialise default hostname
root@c897841142fe:/# hostname
c897841142fe

Travis is now doing a build check, but we can enhance that to add a run check with 'make check'.

./configure shows a warning
...
cat: ./data/kernel-cmdline: No such file or directory
....

The network branch does not provide docker bridge IP address as default gateway. With lack of a correct gateway, the container cannot communicate with external IPs.

Steps:

1. Start docker daemon using cc-oci-runtime

#dockerd-upstream --add-runtime cor=/usr/bin/cc-oci-runtime --default-runtime=cor

1. Start a container

#docker-upstream run -ti debian sh

1. Verify default gateway is the same as Host docker bridge (currently is not the same)

#ip route

The expected output:

#ip route
default via $DOCKER_BRIDGE_IP dev eth0 
...

1. Try to ping to a reachable ip e.g. your host IP

#ping $HOST_IP

This will fail:

#ping $HOST_IP   
PING $HOST_IP ($HOST_IP): 56 data bytes
ping: sending packet: Network is unreachable

The current workaround is set the the default gateway manually, inside the container run:

#ip route add default via $DOCKER_IP_BRIDGE
#ip route
default via $DOCKER_IP_BRIDGE dev eth0 
$DOCKER_IP_BRIDGE/16 dev eth0  proto kernel  scope link  src ...

The exec command is blocked on network support. Once networking is available, the function clr_oci_vm_connect() needs to be updated to remove the g_critical ("not implemented yet") call.

related to #23

The IRC channel is irc://freenode.net/#clearcontainers.
The mailing list is being created.

Currently the networking implementation supports network=none and network=bridge.
Docker swarm overlay networking needs to be supported to enable clusterwide networking.

Requires support for #94

Swarm sets up two veth interfaces per container

• overlay veth
  • with IP Addresses (Container Overlay IP and Service Virtual IP)
• docker_gw_bridge veth
  • with a host level IP address for non overlay traffic

The docker_gw_bridge is used for non overlay traffic (if the overlay network configuration allows for this i.e. --internal=true is not set)

Requirements to support Docker Swarm Mode

Discovery

Runtime MUST discover

• Hostname
• All interfaces and their names
• All IP’s on interfaces
• All routes
• macaddress, MTU’s and other properties per interface

Connectivity

Runtime MUST

• Connect all the interfaces to QEMU and setup macaddress
• Handle all interface types (veth, ovs, tap …)

Configuration:

Runtime MUST

• Pass all of this information into the VM

VM cloud-init service MUST

• Setup Hostname
• Setup Interface name, MTU, IPv4 addresses and subnet masks, IPv6 addresses
• Setup routes

When configured with --prefix=home/damien/clear/install:

$ cat data/vm.json
{
    "vm": {
        "path": "/home/damien/clear/install/bin/qemu-system-x86_64",
            "image": "${prefix}/var/lib/cc-oci-runtime/data/image/clear-containers.img",
            "kernel": {
                "path": "${prefix}/var/lib/cc-oci-runtime/data/kernel/vmlinux.container",
                "parameters": "root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro  rw rootfstype=ext4 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k panic=1 console=hvc0 console=hvc1 initcall_debug init=/usr/lib/systemd/systemd systemd.unit=container.target iommu=off quiet systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket systemd.show_status=false cryptomgr.notests"
            }
    }
}

Of course, cc-oci-runtime cannot, then, find those files.

Clear Linux has a bundles concept: https://clearlinux.org/documentation/bundles_overview.html

We need to package cc-oci-runtime among other components to be easily usable and installabe.

• qemu-lite
• cc-oci-runtime

We should create a bats file that checks the state directory contents are as expected (state.json, hypervisor.sock, etc). We need to check file existence, type, owner, group, perms and where appropriate size (assert non-zero, etc).

In the first implementation direct invocation of the iproute2 utilities has been used to discover and setup networking configuration by spawning iproute2 commands. This is inefficient and not very secure.

Replace the commands with a pure netlink based implementation which will allow for more efficient setup.

Support lines starting with # as comments.

The next message appears when running a clear container:

root@containers-broadwell ~/containers-metrics/test # docker-upstream run -ti ubuntu bash
[ 0.054929] systemd[1]: Failed to initialise default hostname
root@975cd940fe3c:/#

This is useful for debug/diagnostics since all runtime operations are logged to /run/opencontainer/containers/cc-oci-runtime.log. However, on a busy server that file could grow fast.

We should probably

• Disable the global log by default and document how to configure docker to pass
  "--global-log /run/opencontainer/containers/cc-oci-runtime.log" to containerd.
  See: setup_logging().
• Update README.rst on the new behaviour (no global log by default if run stand-alone).

Known limitation of code used to fix #38.

So that we can have a nano second resolution logging.
Runc already does that.

If the runtime is configured for docker and docker run is specified without -ti, no output is currently generated to either the console or the docker log (docker logs command).

$ docker-upstream run --runtime runc ubuntu echo "hello world"
hello world

$ docker-upstream logs  $(docker-upstream ps -qa | head -1)
hello world

$ docker-upstream run --runtime cor ubuntu echo "hello world"
container 20ed5890250df32cd7c1b24027bcba708c6b350481557205fc881a16e924b27d created

$ docker-upstream logs  $(docker-upstream ps -qa | head -1)
container 20ed5890250df32cd7c1b24027bcba708c6b350481557205fc881a16e924b27d created

$ docker-upstream run -it --runtime runc ubuntu echo "hello world"
hello world

$ docker-upstream logs  $(docker-upstream ps -qa | head -1)
hello world

$ docker-upstream run -it --runtime cor ubuntu echo "hello world"
hello world

We should add a document describing how to run Clear Containers under Clear Linux (or other distribution) inside a VM. This may be a common setup for Clear Containers evaluation. The only detail necessary may be the requirement to have VM-in-VM enabled, as is detected by the clear-linux-check-config.sh script already.

With runc:

$ sudo docker-upstream run --runtime runc  debian /usr/bin/perl -e 'exit 55'
$ echo $?
55

with cc-oci-runtime:

$ sudo docker-upstream run  debian  /usr/bin/perl -e 'exit 55'
$ echo $?
0

Chroot to the bundle directory right before guest execution: qemu -chroot $bundle_dir
This needs the addition of @BUNDLE_DIR@ to hypervisor.args.

The runtime should arrange for the hypervisor standard output and standard error to be captured to files to aid in debugging. Something like:

/run/opencontainer/containers/${container}/hypervisor.stdout
/run/opencontainer/containers/${container}/hypervisor.stderr

See https://github.com/opencontainers/runtime-spec/blob/master/config.md#annotations.

It is safer and generate smaller binaries than using PATH_MAX char arrays.
It could have a speed/performance impact.

Started a postgres container :
sudo docker-upstream run -it postgres

Works with runc. Get the message

LOG:  database system is ready to accept connections

When run with cc-oci-runtime, it shows the following:

Success. You can now start the database server using:
    pg_ctl -D /var/lib/postgresql/data -l logfile start
cat: -: No such file or directory

Above message is not very helpful. Need to root cause the issue.

It makes for a more understandable and readable code.

The current implementation supports only a single network and only IPv4. This is due to the limitation of the kernel command line based on https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
This allows for a single interface and IP.

As next step we need to support

• Support multiple networks (i.e interfaces)

This requires cloud-init or alternate method of sending in the network configuration and actually configuration of the same within the VM.

This issues will track the architecture and progress of the implementation

Known limitation of code used to fix #38.

It minimises potential memory leaks and adds code clarity.

Rather than programatically redirecting stdin/out/err for the qemu-lite process, we could run it with -chardev serial path=/dev/pts/XX where that device is the value passed from containerd.

In order to support more than one interface or bridges, routing etc we need a mechanism in clear-containers image that can handle such complex configuration. It can also add extra features to customize the container with specific values or even to setup proxies.

process_config_start ignores values returned by spec handlers therefore spec handler's validations are ignored.
If a spec handler returns false cor must not continue and report the error

When trying to update a debian docker container, I got some errors which seem to be related to 9pfs.
root@ede543359f58:/etc/apt# apt-get update
Get:1 http://security.debian.org jessie/updates InRelease [63.1 kB]
Ign http://httpredir.debian.org jessie InRelease
Get:2 http://httpredir.debian.org jessie-updates InRelease [142 kB]
E: Unable to determine file size for fd 11 - fstat (2: No such file or directory)

Looking at google, found that this qemu issue is related:
https://bugs.launchpad.net/qemu/+bug/1336794