# Release 3.0.17

[erick0z]

Welcome to Clear Containers 3.0.17 release!

Thi release the clear containers image was updated to the latest agent version. The agent include changes to support to online vCPUs and Linux capabilities. Now it has NoNewPrivileges in the api. Finally, the agent now is the subreaper of all processes.

Changes

• versions: image: Update base os to version 20640
• build: Don't install git hooks when running under a CI

Shortlog

b0926d4 versions: agent: image: update agent
66f41d6 versions: image: Update base os to version 20640
1c45133 build: Don't install git hooks when running under a CI

Compatibility with Docker

Clear Containers 3.0.17 is compatible with Docker v17.12-ce

OCI Runtime Specification

Clear Containers 3.0.17 support the OCI Runtime Specification v1.0.0-rc5

Clear Linux Containers image

Clear Containers 3.0.17 requires at least Clear Linux containers image 20640

Clear Linux Containers Kernel

Clear Containers 3.0.17 requires at least Clear Linux Containers kernel v4.9.60-84.container

Installation

• BC-Linux

• Centos

• Clear Linux

• Fedora

• SLES

• Ubuntu

• Developers

Issues & limitations

Docker swarm support

See issue #771 for more

Networking

Adding networks dynamically

Resource management

docker run --cpus=

See issue #341 for more information.

docker run --kernel-memory=

See issue #388 for more information.

shm

cgroup constraints

Capabilities

See issue #51 for more information.

sysctl

tmpfs

Other

checkpoint and restore

docker stats

See issue #200 for more information.

runtime commands

ps command

See issue #95 for more information.

events command

See issue #379 for more information.

update command

See issue #380 for more information.

Networking

Support for joining an existing VM network

docker --net=host

docker run --link

Host resource sharing

docker --device

docker -v /dev/...

docker run --privileged

Other

Annotations

runtime commands

init command

spec command

Host rdmsr warnings

More information Limitations

[jodh-intel]

Once the "FIXME" line in the Changes section is removed...

lgtm

[clearcontainersbot]

kubernetes qa-passed 👍

[jcvenegas]

@grahamwhaley any idea about the jenkins errror.

09:19:21 FATAL: Unable to produce a script file

[jodh-intel]

@jcvenegas, @grahamwhaley - I think I found out why:

java.io.IOException: No space left on device

[grahamwhaley]

Yep, that would have been my guess. The high level view of the error is that the Jenkins slave service cannot create the script it needs to run.
I'm pretty sure the root cause will be docker eating up disk space with images and items we no longer need (the build servers have sufficient, but limited, storage space). Last time this happened I found and ran a magic 'docker purge old images' type command - I'll go dig that up and put it at the start or end of our Jenkins config command script so we do a 'cleanse cycle' on each build.

[grahamwhaley]

OK, it was slightly more complex than that...
We had run out of disk space, but there was more than one reason:

• we had a dangling fio test. They create quite a large test file. I suspect this may have been dangling as it was the thing that first hit the out of disk space problem.
  We clean up those test normally here: https://github.com/clearcontainers/tests/blob/master/metrics/storage/fio_job.sh#L233

• we had a bunch of dangling mounts. I suspect those were left over from a recent dangling mount bug we fixed - I've unmounted them.

• we had a bunch of install-asset.xxxx files in /tmp. Unclear exactly how they end up there, but @jcvenegas - the trap EXIT code here: https://github.com/clearcontainers/tests/blob/master/.ci/install_asset.sh#L27
  looks a little strange to me - we have two 'cleanup' functions and two 'trap EXIT' registrations - feels wrong. Should that be combined into a single catch and cleanup func?

We have diskspace back now, but there is still a bunch in the overlay2 area - I suspect that is linked to our images. The images we have installed all look pretty valid and current, and I'm holding off the docker system prune and related calls just yet, as they will I think nuke all our downloaded images that we use for each run, so would only get us a short term fix, and then the next run would download them all again. I will note, adding osbuilder into the mix for image download/create looks like it cost us another ~1Gb image to store ;-)

I'll kick this build again to test it - and we'll have to keep an eye on this. I think we will hit disk issues again, and then we'll have to get smarter again.

[grahamwhaley]

The rebuild worked btw.

[jcvenegas]

@grahamwhaley I'll send a fix for install_assets.sh