Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce
that garden-runC <https://github.com/cloudfoundry/garden-runc-release>,
the new cloud foundry container runtime for Linux, based on the OCI
specification <https://github.com/opencontainers/runtime-spec> and its
reference implementation “runC <https://github.com/opencontainers/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 <https://github.com/cloudfoundry/diego-cf-compatibility> 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
<https://github.com/cloudfoundry/diego-release/blob/develop/docs/manifest-generation.md#-g-opt-into-using-garden-runc-release-for-cells>
-- 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 <https://wiki.ubuntu.com/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
<https://github.com/cloudfoundry/guardian/blob/master/guardiancmd/seccomp.go>
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
<https://github.com/cloudfoundry-incubator/netman-release> and the new “grootfs”
OCI-compliant rootfs downloader
<https://github.com/cloudfoundry/grootfs-release>
-

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

Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce
that garden-runC <https://github.com/cloudfoundry/garden-runc-release>,
the new cloud foundry container runtime for Linux, based on the OCI
specification <https://github.com/opencontainers/runtime-spec> and its
reference implementation “runC <https://github.com/opencontainers/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 <https://github.com/cloudfoundry/diego-cf-compatibility> 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
<https://github.com/cloudfoundry/diego-release/blob/develop/docs/manifest-generation.md#-g-opt-into-using-garden-runc-release-for-cells>
-- 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 <https://wiki.ubuntu.com/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
<https://github.com/cloudfoundry/guardian/blob/master/guardiancmd/seccomp.go>
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
<https://github.com/cloudfoundry-incubator/netman-release> and the new “grootfs”
OCI-compliant rootfs downloader
<https://github.com/cloudfoundry/grootfs-release>
-

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

Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce
that garden-runC <https://github.com/cloudfoundry/garden-runc-release>,
the new cloud foundry container runtime for Linux, based on the OCI
specification <https://github.com/opencontainers/runtime-spec> and its
reference implementation “runC <https://github.com/opencontainers/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 <https://github.com/cloudfoundry/diego-cf-compatibility> 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
<https://github.com/cloudfoundry/diego-release/blob/develop/docs/manifest-generation.md#-g-opt-into-using-garden-runc-release-for-cells>
-- 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 <https://wiki.ubuntu.com/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
<https://github.com/cloudfoundry/guardian/blob/master/guardiancmd/seccomp.go>
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
<https://github.com/cloudfoundry-incubator/netman-release> and the new “grootfs”
OCI-compliant rootfs downloader
<https://github.com/cloudfoundry/grootfs-release>
-

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

Lovely. All our bosh-lites are upgraded and happy to be running another
v1+ release!





On Tue, Oct 18, 2016 at 10:23 AM +1100, "Christopher B Ferris" <
chrisfer(a)us.ibm.com> wrote:

Congrats!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402 <+1%20508%20667%200402>

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 <https://github.com/cloudfoundry/garden-runc-release>,
the new cloud foundry container runtime for Linux, based on the OCI
specification <https://github.com/opencontainers/runtime-spec> and its
reference implementation “runC <https://github.com/opencontainers/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 <https://github.com/cloudfoundry/diego-cf-compatibility> 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
<https://github.com/cloudfoundry/diego-release/blob/develop/docs/manifest-generation.md#-g-opt-into-using-garden-runc-release-for-cells>
-- 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 <https://wiki.ubuntu.com/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
<https://github.com/cloudfoundry/guardian/blob/master/guardiancmd/seccomp.go>
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
<https://github.com/cloudfoundry-incubator/netman-release> and the
new “grootfs” OCI-compliant rootfs downloader
<https://github.com/cloudfoundry/grootfs-release>
-

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