On Oct 18, 2016, at 1:27 AM, Julz Friedman <julz.friedman(a)gmail.com> wrote:

Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce that garden-runC, the new cloud foundry container runtime for Linux, based on the OCI specification and its reference implementation “runC”, is now 1.0!

ACTION REQUIRED: Given that garden-runc is now ready to use and fully compatible with garden-linux, we intend to end-of-life garden-linux immediately. More details on this and an explanation for the accelerated timescale are at the bottom of this email.

About garden-runc: At this point garden-runC has been successfully running 100% of the production traffic on PWS for around a month (it has been running a smaller portion of the load for a longer time as we gained confidence). The Diego team has been testing with and listing compatible releases of both g-l and g-r for several months. It has also been the only supported linux backend for concourse for several months, thereby being used in a broad range of environments and deployment scenarios. In all cases it has held up remarkably well. Given this I'm happy to recommend people move over to garden-runC as soon as possible (diego’s manifest generation scripts should make this extremely simple -- just pass the `-g` flag to diego manifest generation -- but please note you MUST recreate any cells that previously ran garden-linux as part of the transition or you WILL have problems. An easy way to do this is to combine the transition to garden-runc with a stemcell deploy).

As well as being based on open standards and using a low-level container runtime developed with a large community and many eyeballs, garden-runC has some other significant benefits:

AppArmor is configured and enforced by default and out of the box for all unprivileged containers.
Seccomp whitelisting is used to restrict the set of system calls a container can access, hugely reducing the surface area for break-out exploits. Again this is set up out of the box, you don't need to do anything.
We've been able to simplify and modularise the garden code base extensively as part of this transition, allowing pluggable networking and rootfs management. This enables (and will be required by) the fast-developing container-to-container networking work and the new “grootfs” OCI-compliant rootfs downloader
Garden-runC uses the exact same low-level container execution code as docker/k8s for running containers, so when you run container images you know they run identically in CF as elsewhere

I'm immensely proud of the cross-foundation team that has delivered this, including engineers from Pivotal, IBM and SAP.

GARDEN-LINUX END OF LIFE: 28/10/2016 - ACTION REQUIRED: Now that garden-runC is ready we’re extremely keen to avoid maintaining two code-bases for any longer than necessary, so we would like to move everyone to garden-runC immediately, with the next Diego-release update (as mentioned above, apart from the need to recreate the cells this is a 1-1 transition). Doing this on an accelerated timescale is particularly important because we have encountered a regression in the 4.4 kernel that causes problems during container destruction for garden-linux. We are working to track this down, but it is proving extremely difficult to rectify or work around. If anyone intends to use stemcells with 4.4 kernels, until we identify a fix, they should immediately move to garden-runC to avoid issues.

If anyone has huge problems moving off garden-linux now please reach out to me asap and we’ll see what we can do, otherwise I will suggest diego stop supporting generating manifests for garden-linux with the next release, and will propose moving garden-linux to the attic shortly after that. Either way, we will no longer be developing new features for garden-linux or accepting pull requests from this point. Unless anyone has a strong reason otherwise (if so please do say!), we will end support for garden-linux 28/10/2016.

Thanks all very much, and again a huge thanks to the garden team!

Julz Friedman
Garden Core PM