Buildpack dependency on rootfs


Jack Cai
 

I notice that there are a few changes going into the rootfs [1]. Are there
corresponding changes in the buildpack which would make them unable to work
properly in older levels of the rootfs (both cflinuxfs2 and lucid64)?

I guess the larger question is that are we going to have hard dependencies
from buildpack on the underlying stack levels?

[1] https://github.com/cloudfoundry/stacks/commits/master


Mike Dalessio
 

Hi Jack,

Thanks for asking these questions. Not knowing what specific changes you're
referring to, I'll try to address some different aspects of the topic.

First, just to set expectations, `lucid64` is no longer supported, and so
new buildpacks do not officially support it. This was pretty well announced
and discussed on the old vcap-dev mailing list, as well as the current
cf-dev mailing list. We do have tools and artifacts to generate buildpack
binaries for unsupported rootfses, though -- notably
https://github.com/cloudfoundry/binary-builder. Please let me know if you
need assistance in using any of the buildpacks tooling to do nonstandard
things, I'm happy to work with you on it.

At some point, it's *possible* that a buildpack will be released that won't
work on an older version of cflinuxfs2. Just as an example, we're thinking
about removing the vendored version of jq from the go-buildpack, and
relying on the version of jq put into the rootfs in
https://github.com/cloudfoundry/stacks/commit/8770b5185656938c943ee9bb2a5892097d055264.
However, we'd only do something like that after asking for comments and
communicating clearly on the mailing list as well as in the release notes.

Generally speaking, the goal is to provide a rootfs that's
backwards-compatible with buildpacks (e.g., we don't remove packages over
time, we only add or update packages); and to provide buildpacks that are
backwards-compatible with rootfses. It's obviously possible that we'll
break this contract, but we'd only do so after a comment period and lots of
notice.

Have I answered your questions?

It might be worth noting that we only recently started to track the rootfs
as a versioned artifact; the GitHub release history[2] discusses the
changes in each release. Hopefully this will increase transparency; please
let me know if you have other ideas for communicating more clearly.

[2]: https://github.com/cloudfoundry/stacks/releases

Cheers,
-mike

On Mon, Aug 24, 2015 at 5:06 PM, Jack Cai <greensight(a)gmail.com> wrote:

I notice that there are a few changes going into the rootfs [1]. Are there
corresponding changes in the buildpack which would make them unable to work
properly in older levels of the rootfs (both cflinuxfs2 and lucid64)?

I guess the larger question is that are we going to have hard dependencies
from buildpack on the underlying stack levels?

[1] https://github.com/cloudfoundry/stacks/commits/master


Jack Cai
 

Hi Mike

Thanks for addressing my questions gain. I agree that it's important to
make both the rootfs and the buildpacks backward-compatible with each
other. People often use master branch of the buildpacks to push
applications on non-current levels of Cloud Foundry. The strategy you
described will help such scenario.

Jack

On Mon, Aug 24, 2015 at 5:30 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hi Jack,

Thanks for asking these questions. Not knowing what specific changes
you're referring to, I'll try to address some different aspects of the
topic.

First, just to set expectations, `lucid64` is no longer supported, and so
new buildpacks do not officially support it. This was pretty well announced
and discussed on the old vcap-dev mailing list, as well as the current
cf-dev mailing list. We do have tools and artifacts to generate buildpack
binaries for unsupported rootfses, though -- notably
https://github.com/cloudfoundry/binary-builder. Please let me know if you
need assistance in using any of the buildpacks tooling to do nonstandard
things, I'm happy to work with you on it.

At some point, it's *possible* that a buildpack will be released that
won't work on an older version of cflinuxfs2. Just as an example, we're
thinking about removing the vendored version of jq from the go-buildpack,
and relying on the version of jq put into the rootfs in
https://github.com/cloudfoundry/stacks/commit/8770b5185656938c943ee9bb2a5892097d055264.
However, we'd only do something like that after asking for comments and
communicating clearly on the mailing list as well as in the release notes.

Generally speaking, the goal is to provide a rootfs that's
backwards-compatible with buildpacks (e.g., we don't remove packages over
time, we only add or update packages); and to provide buildpacks that are
backwards-compatible with rootfses. It's obviously possible that we'll
break this contract, but we'd only do so after a comment period and lots of
notice.

Have I answered your questions?

It might be worth noting that we only recently started to track the rootfs
as a versioned artifact; the GitHub release history[2] discusses the
changes in each release. Hopefully this will increase transparency; please
let me know if you have other ideas for communicating more clearly.

[2]: https://github.com/cloudfoundry/stacks/releases

Cheers,
-mike


On Mon, Aug 24, 2015 at 5:06 PM, Jack Cai <greensight(a)gmail.com> wrote:

I notice that there are a few changes going into the rootfs [1]. Are
there corresponding changes in the buildpack which would make them unable
to work properly in older levels of the rootfs (both cflinuxfs2 and
lucid64)?

I guess the larger question is that are we going to have hard
dependencies from buildpack on the underlying stack levels?

[1] https://github.com/cloudfoundry/stacks/commits/master