Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the
templates/jobs colocated on the api_zN jobs, you can ignore this email. If
you are overriding the api_zN templates in your stub, or if you are not
using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

This is excellent! I love the decomposition of the buildpacks. I look
forward to the day when cf-release disappears and we just have a bunch of
small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the
templates/jobs colocated on the api_zN jobs, you can ignore this email. If
you are overriding the api_zN templates in your stub, or if you are not
using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

Why are you looking forward to independent releases?
A single release option appears pretty straightforward. Single release
that includes the correct dependent versions.
What are the advantages of breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

This is excellent! I love the decomposition of the buildpacks. I look
forward to the day when cf-release disappears and we just have a bunch of
small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the
templates/jobs colocated on the api_zN jobs, you can ignore this email. If
you are overriding the api_zN templates in your stub, or if you are not
using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

* In this case a release for each buildpack will reduce release download
sizes significantly. My org only uses Java and Node.
* Easily knowing what releases changed and which didn't will be nice. (Not
useful when everything is actively developed but more useful when
components grow more mature)
* If a bug is found in one release near an internal deploy deadline it is
easier to upgrade and test a single component with a fix instead than
waiting for the orchestration of an entirely new cf release with
potentially many more changes.
* Much easier to reuse releases outside of CF (e.g. UAA in bosh, etcd or
consul for internal projects)
* If using CF components like etcd, consul, or nats for in house CF
extensions it is easier for CF to sunset without forcing everyone who uses
it to migrate off. (On that note I'd like to see an independent Nats
release before it is removed from CF release)
* Easier to set up build environments if it ever becomes necessary to do
an internal fork of a release.

On the other hand it doesn't seem like documenting which combination of
components went into a given PWS deploy doesn't seem like that difficult of
a problem to solve. Also, as CF and its associated components mature I'd
imagine that tightly coupled release versions will become less of a problem.

Just a couple of thoughts.

Thanks,
Mike

On Fri, Feb 19, 2016 at 4:58 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Why are you looking forward to independent releases?
A single release option appears pretty straightforward. Single release
that includes the correct dependent versions.
What are the advantages of breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is excellent! I love the decomposition of the buildpacks. I look
forward to the day when cf-release disappears and we just have a bunch of
small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding
the templates/jobs colocated on the api_zN jobs, you can ignore this
email. If you are overriding the api_zN templates in your stub, or if you
are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

Tom brings up a valid concern, and we fully plan on providing data and
tooling to make it easy to deploy the platform, composed of versions of
several releases known to work together, in a way that's easy to use and
easy to extend. Documenting which versions work together and/or deployed
to PWS together is easy, but we intend to provide an even better solution,
which is part of a broader effort to simplify manifest generation, and
using BOSH altogether.

Currently, this entails our CI producing a machine-readable artifact
encapsulating the versions of things known to work together, and a tool
that generates CF manifests using that artifact, but with the ability to
easily override things (e.g. choose to use a different version of a
stemcell). We have a prototype of this here:
https://github.com/cloudfoundry/cf-deployment, but we realized that we
needed to rebuild this in a test-driven fashion, and that effort is
underway here: https://github.com/cloudfoundry/mkman.

Mike has hit a lot of the key user-facing benefits on the head, I'll add a
couple more points that speak to benefits for contributors to CF itself:

- extracting things like a common route-registrar into the routing
release means that contributors to many other components (e.g. CC, UAA,
HM9k, Loggregator, service brokers) don't need to worry about any route
registration/nats logic, they can just colocate the route-registrar from
the lightweight routing release when they are deploying their stuff in a
context where registering a route makes sense. This is just one example.
- providing one release, with one set of job spec definitions, etc. is
much simpler to maintain than, e.g. uaa having to maintain one job spec for
the uaa within cf-release, one for the uaa within a bosh-release, and one
for the uaa as a standalone release.
- cf-release doesn't become a single bottleneck when failures occur in
the integration pipelines. Currently, all teams get blocked from bumping
their components to feed into the integration pipeline as soon as one thing
fails, because the cf-release repo is a single point of entry to
integration pipelines. Together with concourse, it's very easy to
integrate many releases, and simply "pause" one version of one release if
it breaks the build, allowing other components to continue to flow in.
- it is much easier to test the BOSH-operability of things when
they're in their own release. consul and etcd are great examples of this,
as they are generally difficult to orchestrate well in an automated
fashion, and testing things like scale-up, scale-down, rolling deploys, and
fault tolerance of our consul or etcd jobs if they are also part of a
massive cf-release and not their own thing, is more difficult.

Cheers,
Amit

On Fri, Feb 19, 2016 at 10:04 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

* In this case a release for each buildpack will reduce release download
sizes significantly. My org only uses Java and Node.
* Easily knowing what releases changed and which didn't will be nice.
(Not useful when everything is actively developed but more useful when
components grow more mature)
* If a bug is found in one release near an internal deploy deadline it is
easier to upgrade and test a single component with a fix instead than
waiting for the orchestration of an entirely new cf release with
potentially many more changes.
* Much easier to reuse releases outside of CF (e.g. UAA in bosh, etcd or
consul for internal projects)
* If using CF components like etcd, consul, or nats for in house CF
extensions it is easier for CF to sunset without forcing everyone who uses
it to migrate off. (On that note I'd like to see an independent Nats
release before it is removed from CF release)
* Easier to set up build environments if it ever becomes necessary to do
an internal fork of a release.

On the other hand it doesn't seem like documenting which combination of
components went into a given PWS deploy doesn't seem like that difficult of
a problem to solve. Also, as CF and its associated components mature I'd
imagine that tightly coupled release versions will become less of a problem.

Just a couple of thoughts.

Thanks,
Mike

On Fri, Feb 19, 2016 at 4:58 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Why are you looking forward to independent releases?
A single release option appears pretty straightforward. Single release
that includes the correct dependent versions.
What are the advantages of breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is excellent! I love the decomposition of the buildpacks. I look
forward to the day when cf-release disappears and we just have a bunch of
small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding
the templates/jobs colocated on the api_zN jobs, you can ignore this
email. If you are overriding the api_zN templates in your stub, or if you
are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

Hey all,

Forgot to include in the original email, you will also need to update your
cc.install_buildpacks property because the packages names have also
changed for all the buildpacks (except Java). They've gone from
"buildpack_RUNTIME" to "RUNTIME-buidpack".

Best,
Amit

On Sun, Feb 21, 2016 at 4:01 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom brings up a valid concern, and we fully plan on providing data and
tooling to make it easy to deploy the platform, composed of versions of
several releases known to work together, in a way that's easy to use and
easy to extend. Documenting which versions work together and/or deployed
to PWS together is easy, but we intend to provide an even better solution,
which is part of a broader effort to simplify manifest generation, and
using BOSH altogether.

Currently, this entails our CI producing a machine-readable artifact
encapsulating the versions of things known to work together, and a tool
that generates CF manifests using that artifact, but with the ability to
easily override things (e.g. choose to use a different version of a
stemcell). We have a prototype of this here:
https://github.com/cloudfoundry/cf-deployment, but we realized that we
needed to rebuild this in a test-driven fashion, and that effort is
underway here: https://github.com/cloudfoundry/mkman.

Mike has hit a lot of the key user-facing benefits on the head, I'll add
a couple more points that speak to benefits for contributors to CF itself:

- extracting things like a common route-registrar into the routing
release means that contributors to many other components (e.g. CC, UAA,
HM9k, Loggregator, service brokers) don't need to worry about any route
registration/nats logic, they can just colocate the route-registrar from
the lightweight routing release when they are deploying their stuff in a
context where registering a route makes sense. This is just one example.
- providing one release, with one set of job spec definitions, etc.
is much simpler to maintain than, e.g. uaa having to maintain one job spec
for the uaa within cf-release, one for the uaa within a bosh-release, and
one for the uaa as a standalone release.
- cf-release doesn't become a single bottleneck when failures occur
in the integration pipelines. Currently, all teams get blocked from
bumping their components to feed into the integration pipeline as soon as
one thing fails, because the cf-release repo is a single point of entry to
integration pipelines. Together with concourse, it's very easy to
integrate many releases, and simply "pause" one version of one release if
it breaks the build, allowing other components to continue to flow in.
- it is much easier to test the BOSH-operability of things when
they're in their own release. consul and etcd are great examples of this,
as they are generally difficult to orchestrate well in an automated
fashion, and testing things like scale-up, scale-down, rolling deploys, and
fault tolerance of our consul or etcd jobs if they are also part of a
massive cf-release and not their own thing, is more difficult.

Cheers,
Amit

On Fri, Feb 19, 2016 at 10:04 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

* In this case a release for each buildpack will reduce release download
sizes significantly. My org only uses Java and Node.
* Easily knowing what releases changed and which didn't will be nice.
(Not useful when everything is actively developed but more useful when
components grow more mature)
* If a bug is found in one release near an internal deploy deadline it
is easier to upgrade and test a single component with a fix instead than
waiting for the orchestration of an entirely new cf release with
potentially many more changes.
* Much easier to reuse releases outside of CF (e.g. UAA in bosh, etcd or
consul for internal projects)
* If using CF components like etcd, consul, or nats for in house CF
extensions it is easier for CF to sunset without forcing everyone who uses
it to migrate off. (On that note I'd like to see an independent Nats
release before it is removed from CF release)
* Easier to set up build environments if it ever becomes necessary to do
an internal fork of a release.

On the other hand it doesn't seem like documenting which combination of
components went into a given PWS deploy doesn't seem like that difficult of
a problem to solve. Also, as CF and its associated components mature I'd
imagine that tightly coupled release versions will become less of a problem.

Just a couple of thoughts.

Thanks,
Mike

On Fri, Feb 19, 2016 at 4:58 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Why are you looking forward to independent releases?
A single release option appears pretty straightforward. Single release
that includes the correct dependent versions.
What are the advantages of breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is excellent! I love the decomposition of the buildpacks. I
look forward to the day when cf-release disappears and we just have a bunch
of small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate
releases. As we transition to deploying CF via a bunch of composed
releases, for now we're making the change more transparent, by submoduling
and symlinking the buildpacks releases back into cf-release. This requires
some manifest changes: buildpacks are now colocated with cloud controller,
rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding
the templates/jobs colocated on the api_zN jobs, you can ignore this
email. If you are overriding the api_zN templates in your stub, or if you
are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

"RUNTIME-buidpack"

is the missing L intentional in buildpack?

On Thu, Mar 3, 2016 at 10:51 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey all,

Forgot to include in the original email, you will also need to update
your cc.install_buildpacks property because the packages names have also
changed for all the buildpacks (except Java). They've gone from
"buildpack_RUNTIME" to "RUNTIME-buidpack".

Best,
Amit

On Sun, Feb 21, 2016 at 4:01 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom brings up a valid concern, and we fully plan on providing data and
tooling to make it easy to deploy the platform, composed of versions of
several releases known to work together, in a way that's easy to use and
easy to extend. Documenting which versions work together and/or deployed
to PWS together is easy, but we intend to provide an even better solution,
which is part of a broader effort to simplify manifest generation, and
using BOSH altogether.

Currently, this entails our CI producing a machine-readable artifact
encapsulating the versions of things known to work together, and a tool
that generates CF manifests using that artifact, but with the ability to
easily override things (e.g. choose to use a different version of a
stemcell). We have a prototype of this here:
https://github.com/cloudfoundry/cf-deployment, but we realized that we
needed to rebuild this in a test-driven fashion, and that effort is
underway here: https://github.com/cloudfoundry/mkman.

Mike has hit a lot of the key user-facing benefits on the head, I'll add
a couple more points that speak to benefits for contributors to CF itself:

- extracting things like a common route-registrar into the routing
release means that contributors to many other components (e.g. CC, UAA,
HM9k, Loggregator, service brokers) don't need to worry about any route
registration/nats logic, they can just colocate the route-registrar from
the lightweight routing release when they are deploying their stuff in a
context where registering a route makes sense. This is just one example.
- providing one release, with one set of job spec definitions, etc.
is much simpler to maintain than, e.g. uaa having to maintain one job spec
for the uaa within cf-release, one for the uaa within a bosh-release, and
one for the uaa as a standalone release.
- cf-release doesn't become a single bottleneck when failures occur
in the integration pipelines. Currently, all teams get blocked from
bumping their components to feed into the integration pipeline as soon as
one thing fails, because the cf-release repo is a single point of entry to
integration pipelines. Together with concourse, it's very easy to
integrate many releases, and simply "pause" one version of one release if
it breaks the build, allowing other components to continue to flow in.
- it is much easier to test the BOSH-operability of things when
they're in their own release. consul and etcd are great examples of this,
as they are generally difficult to orchestrate well in an automated
fashion, and testing things like scale-up, scale-down, rolling deploys, and
fault tolerance of our consul or etcd jobs if they are also part of a
massive cf-release and not their own thing, is more difficult.

Cheers,
Amit

On Fri, Feb 19, 2016 at 10:04 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

* In this case a release for each buildpack will reduce release
download sizes significantly. My org only uses Java and Node.
* Easily knowing what releases changed and which didn't will be nice.
(Not useful when everything is actively developed but more useful when
components grow more mature)
* If a bug is found in one release near an internal deploy deadline it
is easier to upgrade and test a single component with a fix instead than
waiting for the orchestration of an entirely new cf release with
potentially many more changes.
* Much easier to reuse releases outside of CF (e.g. UAA in bosh, etcd
or consul for internal projects)
* If using CF components like etcd, consul, or nats for in house CF
extensions it is easier for CF to sunset without forcing everyone who uses
it to migrate off. (On that note I'd like to see an independent Nats
release before it is removed from CF release)
* Easier to set up build environments if it ever becomes necessary to
do an internal fork of a release.

On the other hand it doesn't seem like documenting which combination of
components went into a given PWS deploy doesn't seem like that difficult of
a problem to solve. Also, as CF and its associated components mature I'd
imagine that tightly coupled release versions will become less of a problem.

Just a couple of thoughts.

Thanks,
Mike

On Fri, Feb 19, 2016 at 4:58 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

Why are you looking forward to independent releases?
A single release option appears pretty straightforward. Single release
that includes the correct dependent versions.
What are the advantages of breaking them out?

Thanks,
Tom

On Thu, Feb 18, 2016 at 5:28 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is excellent! I love the decomposition of the buildpacks. I
look forward to the day when cf-release disappears and we just have a bunch
of small independent releases. Hopefully that day is getting closer and
closer.

Mike

On Thu, Feb 18, 2016 at 11:31 AM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Hey developers,

The buildpacks team has recently extracted the buildpacks as
separate releases. As we transition to deploying CF via a bunch of
composed releases, for now we're making the change more transparent, by
submoduling and symlinking the buildpacks releases back into cf-release.
This requires some manifest changes: buildpacks are now colocated with
cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding
the templates/jobs colocated on the api_zN jobs, you can ignore this
email. If you are overriding the api_zN templates in your stub, or if you
are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (
https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d)
for more details.

Best,
Amit

Le 18 févr. 2016 à 19:31, Amit Gupta <agupta(a)pivotal.io> a écrit :

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate releases. As we transition to deploying CF via a bunch of composed releases, for now we're making the change more transparent, by submoduling and symlinking the buildpacks releases back into cf-release. This requires some manifest changes: buildpacks are now colocated with cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the templates/jobs colocated on the api_zN jobs, you can ignore this email. If you are overriding the api_zN templates in your stub, or if you are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d <https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d>) for more details.

Best,
Amit

Le 10 mars 2016 à 21:14, Amit Gupta <agupta(a)pivotal.io> a écrit :

At the time of the email, the java buildpack hadn't been extracted into a separate release yet. I believe it has now, and that will be reflected in CF v232.

What command did you run?
What SHA of cf-release have you checked out?

On Thu, Mar 10, 2016 at 12:10 PM, Benjamin Gandon <benjamin(a)gandon.org> wrote:
Amit, just for me to be sure, why didn’t you list the java-buildpack?

Also, have the blobs properly been uploaded?
I copy below the BOSH errors I get:

With binary-buildpack:

Uploading 'binary-buildpack-release/1.0.1'
Recreating release from the manifest
MISSING
Cannot find package with checksum `413ce11236f87273ba8a9249b6e3bebb3d0db92b'

With go-buildpack:

Uploading 'go-buildpack-release/1.7.3'
Recreating release from the manifest
MISSING
Cannot find package with checksum `300760637ee0babd5fddd474101dfa634116d9c4'

With java-buildpack:

Uploading 'java-buildpack-release/3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `e6ff7d79e50f0aaafa92f100f346e648c503ab17'

With nodejs-buildpack:

Uploading 'nodejs-buildpack-release/1.5.7'
Recreating release from the manifest
MISSING
Cannot find package with checksum `b3edbcfb9435892749dffcb99f06d00fb4c59c5b'

With php-buildpack:

Uploading 'php-buildpack-release/4.3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `fbc784608ffa3ceafed1810b69c12a7277c86ee0'

With python-buildpack:

Uploading 'python-buildpack-release/1.5.4'
Recreating release from the manifest
MISSING
Cannot find package with checksum `7e2377ccd9df10b21aba49c8e95338a0b1b3b92e'

With ruby-buildpack:

Uploading 'ruby-buildpack-release/1.6.14'
Recreating release from the manifest
MISSING
Cannot find package with checksum `362282d45873634db888a609cd64d7d70e9f4be2'

With staticfile-buildpack:

Uploading 'staticfile-buildpack-release/1.3.2'
Recreating release from the manifest
MISSING
Cannot find package with checksum `06382f7c804cc7f01a8dc78ca9c91e9b7f4712cc'

Are these on a specific blobstore I should point my deployment manifest at?

/Benjamin

Le 18 févr. 2016 à 19:31, Amit Gupta <agupta(a)pivotal.io> a écrit :

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate releases. As we transition to deploying CF via a bunch of composed releases, for now we're making the change more transparent, by submoduling and symlinking the buildpacks releases back into cf-release. This requires some manifest changes: buildpacks are now colocated with cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the templates/jobs colocated on the api_zN jobs, you can ignore this email. If you are overriding the api_zN templates in your stub, or if you are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d) for more details.

Best,
Amit

Le 10 mars 2016 à 23:24, Benjamin Gandon <benjamin(a)gandon.org> a écrit :

No no no, these are not SHAs of cf-release, but those of all the buildpack-releases indeed.
Looks like no blobs of these releases are actually available online, are they?

I'm running the standard middle step "bosh prepare deployment" provided by bosh-workspace.
(See <https://github.com/cloudfoundry-incubator/bosh-workspace <https://github.com/cloudfoundry-incubator/bosh-workspace>>)

/Benjamin


Le 10 mars 2016 à 21:14, Amit Gupta <agupta(a)pivotal.io <mailto:agupta(a)pivotal.io>> a écrit :

At the time of the email, the java buildpack hadn't been extracted into a separate release yet. I believe it has now, and that will be reflected in CF v232.

What command did you run?
What SHA of cf-release have you checked out?

On Thu, Mar 10, 2016 at 12:10 PM, Benjamin Gandon <benjamin(a)gandon.org <mailto:benjamin(a)gandon.org>> wrote:
Amit, just for me to be sure, why didn’t you list the java-buildpack?

Also, have the blobs properly been uploaded?
I copy below the BOSH errors I get:

With binary-buildpack:

Uploading 'binary-buildpack-release/1.0.1'
Recreating release from the manifest
MISSING
Cannot find package with checksum `413ce11236f87273ba8a9249b6e3bebb3d0db92b'

With go-buildpack:

Uploading 'go-buildpack-release/1.7.3'
Recreating release from the manifest
MISSING
Cannot find package with checksum `300760637ee0babd5fddd474101dfa634116d9c4'

With java-buildpack:

Uploading 'java-buildpack-release/3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `e6ff7d79e50f0aaafa92f100f346e648c503ab17'

With nodejs-buildpack:

Uploading 'nodejs-buildpack-release/1.5.7'
Recreating release from the manifest
MISSING
Cannot find package with checksum `b3edbcfb9435892749dffcb99f06d00fb4c59c5b'

With php-buildpack:

Uploading 'php-buildpack-release/4.3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `fbc784608ffa3ceafed1810b69c12a7277c86ee0'

With python-buildpack:

Uploading 'python-buildpack-release/1.5.4'
Recreating release from the manifest
MISSING
Cannot find package with checksum `7e2377ccd9df10b21aba49c8e95338a0b1b3b92e'

With ruby-buildpack:

Uploading 'ruby-buildpack-release/1.6.14'
Recreating release from the manifest
MISSING
Cannot find package with checksum `362282d45873634db888a609cd64d7d70e9f4be2'

With staticfile-buildpack:

Uploading 'staticfile-buildpack-release/1.3.2'
Recreating release from the manifest
MISSING
Cannot find package with checksum `06382f7c804cc7f01a8dc78ca9c91e9b7f4712cc'

Are these on a specific blobstore I should point my deployment manifest at?

/Benjamin

Le 18 févr. 2016 à 19:31, Amit Gupta <agupta(a)pivotal.io <mailto:agupta(a)pivotal.io>> a écrit :

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate releases. As we transition to deploying CF via a bunch of composed releases, for now we're making the change more transparent, by submoduling and symlinking the buildpacks releases back into cf-release. This requires some manifest changes: buildpacks are now colocated with cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the templates/jobs colocated on the api_zN jobs, you can ignore this email. If you are overriding the api_zN templates in your stub, or if you are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d <https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d>) for more details.

Best,
Amit

Le 11 mars 2016 à 00:04, Amit Gupta <agupta(a)pivotal.io> a écrit :

I did

cd cf-release
git fetch origin
git checkout develop
git pull --ff-only
./scripts/update
bosh create release --with-tarball

And also

cd src/buildpacks/binary-buildpack-release/
git fetch origin
(confirmed HEAD was pointed at origin/master)
bosh create release

Everything worked fine for me, meaning it was able to sync blobs down from the remote blobstores. I'm not familiar with bosh-workspace, and it's not clear to me why it's trying to upload anything (e.g. Uploading 'ruby-buildpack-release/1.6.14').

On Thu, Mar 10, 2016 at 2:48 PM, Benjamin Gandon <benjamin(a)gandon.org <mailto:benjamin(a)gandon.org>> wrote:
And btw Amit, it looks like the java-buildpack v3.6 is here with its fellows:
https://github.com/cloudfoundry/buildpack-releases/blob/master/java-buildpack-release/releases/java-buildpack-release/java-buildpack-release-3.6.yml <https://github.com/cloudfoundry/buildpack-releases/blob/master/java-buildpack-release/releases/java-buildpack-release/java-buildpack-release-3.6.yml>
For example the « e6ff7d79e50f0aaafa92f100f346e648c503ab17 » SHA in the error below (when recreating the java-buildpack-release) is the one of the first blob in the release manifest above.

Le 10 mars 2016 à 23:24, Benjamin Gandon <benjamin(a)gandon.org <mailto:benjamin(a)gandon.org>> a écrit :

No no no, these are not SHAs of cf-release, but those of all the buildpack-releases indeed.
Looks like no blobs of these releases are actually available online, are they?

I'm running the standard middle step "bosh prepare deployment" provided by bosh-workspace.
(See <https://github.com/cloudfoundry-incubator/bosh-workspace <https://github.com/cloudfoundry-incubator/bosh-workspace>>)

/Benjamin


Le 10 mars 2016 à 21:14, Amit Gupta <agupta(a)pivotal.io <mailto:agupta(a)pivotal.io>> a écrit :

At the time of the email, the java buildpack hadn't been extracted into a separate release yet. I believe it has now, and that will be reflected in CF v232.

What command did you run?
What SHA of cf-release have you checked out?

On Thu, Mar 10, 2016 at 12:10 PM, Benjamin Gandon <benjamin(a)gandon.org <mailto:benjamin(a)gandon.org>> wrote:
Amit, just for me to be sure, why didn’t you list the java-buildpack?

Also, have the blobs properly been uploaded?
I copy below the BOSH errors I get:

With binary-buildpack:

Uploading 'binary-buildpack-release/1.0.1'
Recreating release from the manifest
MISSING
Cannot find package with checksum `413ce11236f87273ba8a9249b6e3bebb3d0db92b'

With go-buildpack:

Uploading 'go-buildpack-release/1.7.3'
Recreating release from the manifest
MISSING
Cannot find package with checksum `300760637ee0babd5fddd474101dfa634116d9c4'

With java-buildpack:

Uploading 'java-buildpack-release/3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `e6ff7d79e50f0aaafa92f100f346e648c503ab17'

With nodejs-buildpack:

Uploading 'nodejs-buildpack-release/1.5.7'
Recreating release from the manifest
MISSING
Cannot find package with checksum `b3edbcfb9435892749dffcb99f06d00fb4c59c5b'

With php-buildpack:

Uploading 'php-buildpack-release/4.3.6'
Recreating release from the manifest
MISSING
Cannot find package with checksum `fbc784608ffa3ceafed1810b69c12a7277c86ee0'

With python-buildpack:

Uploading 'python-buildpack-release/1.5.4'
Recreating release from the manifest
MISSING
Cannot find package with checksum `7e2377ccd9df10b21aba49c8e95338a0b1b3b92e'

With ruby-buildpack:

Uploading 'ruby-buildpack-release/1.6.14'
Recreating release from the manifest
MISSING
Cannot find package with checksum `362282d45873634db888a609cd64d7d70e9f4be2'

With staticfile-buildpack:

Uploading 'staticfile-buildpack-release/1.3.2'
Recreating release from the manifest
MISSING
Cannot find package with checksum `06382f7c804cc7f01a8dc78ca9c91e9b7f4712cc'

Are these on a specific blobstore I should point my deployment manifest at?

/Benjamin

Le 18 févr. 2016 à 19:31, Amit Gupta <agupta(a)pivotal.io <mailto:agupta(a)pivotal.io>> a écrit :

Hey developers,

The buildpacks team has recently extracted the buildpacks as separate releases. As we transition to deploying CF via a bunch of composed releases, for now we're making the change more transparent, by submoduling and symlinking the buildpacks releases back into cf-release. This requires some manifest changes: buildpacks are now colocated with cloud controller, rather than package dependencies of cloud controller.

If you are using spiff to generate manifests, and are not overriding the templates/jobs colocated on the api_zN jobs, you can ignore this email. If you are overriding the api_zN templates in your stub, or if you are not using spiff, you will need to add the following:

templates:
- name: consul_agent
release: cf
+ - name: go-buildpack
+ release: cf
+ - name: binary-buildpack
+ release: cf
+ - name: nodejs-buildpack
+ release: cf
+ - name: ruby-buildpack
+ release: cf
+ - name: php-buildpack
+ release: cf
+ - name: python-buildpack
+ release: cf
+ - name: staticfile-buildpack
+ release: cf
- name: cloud_controller_ng
release: cf

Please see this commit (https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d <https://github.com/cloudfoundry/cf-release/commit/549e5a8271bbf0d30efdb84f381f38c8bf22099d>) for more details.

Best,
Amit