Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using runtime-tools to test containerd #653

Open
alban opened this issue Jun 27, 2018 · 5 comments
Open

Using runtime-tools to test containerd #653

alban opened this issue Jun 27, 2018 · 5 comments

Comments

@alban
Copy link
Contributor

alban commented Jun 27, 2018

Following discussion on opencontainers/oci-conformance#36, I am trying to see how to use runtime-tools to test containerd.

I am exploring how to write a wrapper around containerd implementing the OCI Runtime Command Line Interface that runtime-tools would use as a $RUNTIME to talk to containerd.

containerd's ctr CLI tool can run (create+start) a container or start it. There is no CLI for creating one without starting it but it can be done both at the gRPC level or using the Golang client library.

CLI command cdr task start does the following:

  • calls the NewTask() method from the client library. This calls the gRPC command c.client.TaskService().Create()
  • calls the task.Start() method from the client library. This calls the gRPC command t.client.TaskService().Start

``

runtime-tools tests don't download images from internet but instead they create the config.json and the rootfs themselves with the specific configuration that need to be tested. However, the containerd interface mostly deals with images. It is possible to call create in the gRPC protocol and include config.json on the wire but the root.path will unfortunately not be respected in the last version. A fix is in progress (containerd/containerd#2412, containerd/containerd#2418, thanks @flx42 and @crosbymichael!).

Since runtime-tools tests have no control over which directory containerd will write the config.json received by gRPC, the rootfs prepared by runtime-tools tests will not be in the same directory. This contradicts the OCI specs (see @flx42's comment) but containerd might allow absolute paths in root.path outside of the bundle anyway, so that might be ok for the containerd wrapper to rely on that.

@alban
Copy link
Contributor Author

alban commented Jun 27, 2018

There is no CLI for creating one without starting it but it can be done both at the gRPC level or using the Golang client library.

Oh, create exists now. Sorry, I was looking at an old version.

@alban
Copy link
Contributor Author

alban commented Jul 17, 2018

My tests so far:

$ make
$ sudo systemd-run -p Delegate=yes -p KillMode=process $PWD/bin/containerd
  • run a test:
$ sudo RUNTIME=$PWD/ctroci.sh validation/process_rlimits/process_rlimits.t

With the following ctroci.sh script:

#!/bin/bash

CTR=/home/alban/go/src/github.com/containerd/containerd/bin/ctr

echo "$@" >> /tmp/ctroci.log

verb=$1
shift

docreate () {
	if [ "$1" == "--pid-file" ] ; then
		pidfileparam="--pid-file $2"
		shift 2
	fi
	if [ "$1" == "--bundle" ] ; then
		bundle=$2
		configfile=$bundle/config.json
		rootfs=`jq -r '.root.path' < $configfile`
		if ! [[ "$rootfs" =~ ^/ ]]; then
			rootfs=`readlink -f $bundle/$rootfs`
		fi
		shift 2
	fi

	echo $CTR -n oci-tests containers create $pidfileparam --config $configfile --rootfs $rootfs $@ >> /tmp/ctroci.log
	$CTR -n oci-tests containers create $pidfileparam --config $configfile --rootfs $rootfs $@

	echo $CTR -n oci-tests tasks start $@ >> /tmp/ctroci.log
	$CTR -n oci-tests tasks start $@
}

dostart () {
	echo no start >> /tmp/ctroci.log
}

dostate () {
	echo $CTR -n oci-tests containers info $@ >> /tmp/ctroci.log
	$CTR -n oci-tests containers info $@
}

dodelete () {
	echo $CTR -n oci-tests containers delete $@ >> /tmp/ctroci.log
	$CTR -n oci-tests containers delete $@
}


case $verb in
create)
	docreate "$@"
	;;
start)
	dostart "$@"
	;;
state)
	dostate "$@"
	;;
delete)
	dodelete "$@"
	;;
*)
	echo "unknown command $verb" >> /tmp/ctroci.log
	;;
esac

The test fails with timeout in waiting for the container status because $RUNTIME state is not done yet and cdr task start needs to be split up as mentioned above.

@crosbymichael
Copy link
Member

Ok, I think we need to add a ctr task create and you should be good.

@alban
Copy link
Contributor Author

alban commented Jul 23, 2018

@crosbymichael I started on containerd/containerd#2486

I could get it working with e.g. test validation/linux_cgroups_memory/linux_cgroups_memory.t that use a "create" without a "start".

I'll try to get the "state" working now.

@alban
Copy link
Contributor Author

alban commented Jul 24, 2018

I could get some tests to pass using:

The difficulties are:

Then, I can compare containerd and runc. I used runtime-tools with #658.

sudo make TAP=$(which tap) RUNTIME=/home/alban/go/src/github.com/containerd/ctroci/ctroci.sh localvalidation 2>&1 | tee /tmp/containerd.logs

sudo make TAP=$(which tap) RUNTIME=runc localvalidation 2>&1 | tee /tmp/runc.logs

Outputs:

I'll look at the details tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants