Skip to content


You can find the source of this version on GitHub at cloudfoundry/cf-release. It was created based on the commit 48c88357.

Release Notes

The cf-release v211 was released on June 4th, 2015 - IMPORTANT: This release removes lucid64 stack, please ensure apps migrated prior to upgrade - IMPORTANT: If using the postgres included within cf-release, please carefully read the note below about postgres job upgrade


  • Remove lucid64 stack completely from cf-release details
  • Upgraded postgres included in cf-release to postgres 9.4.2 details
    • See note below about the postgres job upgrade
  • [Experimental] Work continues on /v3 and Application Process Types details
  • [Experimental] Work continues on Route API details
  • [Experimental] Work continues on Context Path Routes details
  • Work in progress for support of user-provided tags on service instances details
  • cloudfoundry/cf-release #689: Fixing failed cc_ng and cc_ng_worker with NFS details
  • Remove default support address for CC details
  • increased cloud_controller_ng start timeout to be able to run long ccdb migrations details
  • cloudfoundry/cf-release #680: staticfile to be tested before nodejs/ruby buildpacks details
  • cloudfoundry/stacks #16: Add cmake to rootfses details
  • cloudfoundry/stacks #17: Add autoconf to rootfs details
  • cloudfoundry/cf-release #682: Upgrading ruby buildpack to v1.4.2 details
  • cloudfoundry/cf-release #683: Upgrading python buildpack to v1.3.2 details
  • Make ‘dea_next.stacks’ overridable in the manifest. details
  • cloudfoundry/cf-release #681: Add security group for cf-mysql subnets on bosh-lite details
  • cloudfoundry/dea_ng #164: Add warden_handle method to staging task details
  • Use MASQUERADE instead of SNAT for container NAT details
  • Throw better errors for apps stats endpoint details
  • Fix buildpack_cache deletion issue details


  • If no Dopplers available in an AZ, Metron will now fail over across AZs. details
  • StatsD support broken out of Metron and into a separate process. New class of items for adding data into metron/loggregator now known as an “injectors.” Further info to follow on cf-dev.
  • All loggregator metrics now using a Metron /varz shim instead of writing to a local /varz.
    • Most loggregator metrics will have a different prefix as a result.
    • All former metrics and new ones are documented - in wiki (scroll right) and in a public google doc.
    • Story details.
    • Other CF Components to follow; docs to be formalized with documentation team.
  • NOAA client library fixed Close() issue, independent of CF release. Change is backward-incompatible.
  • Removed Dropsonde protocol dependence on gogoproto for non-go builds. details
  • Increase doppler marshal/unmarshal efficiency to compensate for message size changes. details
  • [Bug Fix] Syslog drain binder is no longer leaking connections to cloud_controller. details
  • [Bug Fix] LoggregatorClientPool no longer leaking clients to non-existant dopplers. details

Used Configuration

  • BOSH Version: 152
  • Stemcell Version: 2969
  • CC Api Version: 2.28.0

Commit summary

Compatible Diego Version

  • final release 0.1281.0 commit

Postgres Job Upgrade

The Postgres Job will upgrade the postgres database to version 9.4.2. Postgres will be unavailable during this upgrade.

A copy of the database is made for the upgrade, you may need to adjust the persistent disk capacity of the postgres job.

If the upgrade fails: - The old database is still available at /var/vcap/store/postgres - The new database is at /var/vcap/store/postgres-9.4.2 - A marker file is kept at /var/vcap/store/FLAG_POSTGRES_UPGRADE to prevent the upgrade from happening again. - pg_upgrade logs that may have details of why the migration failed can be found in /home/vcap/

To attempt the upgrade again, you should remove /var/vcap/store/postgres-9.4.2 and /var/vcap/store/FLAG_POSTGRES_UPGRADE

To rollback to a previous release, you should remove /var/vcap/store/postgres-9.4.2 and /var/vcap/store/FLAG_POSTGRES_UPGRADE. The previous release has no knowledge of these files, but they will conflict if you later try the upgrade again.

Post upgrade, both old and new databases are kept. The old database moved to /var/vcap/store/postgres-previous. The postgres-previous directory will be kept until the next postgres upgrade is performed in the future. You are free to remove this if you have verified the new database works and you want to reclaim the space.

Manifest and Job Spec Changes

  • lucid64 stack has been removed
  • properties.dea_next.stacks.default lucid64 stack has been removed


You can reference this release in your deployment manifest from the releases section:

- name: "cf"
  version: "211"
  url: ""
  sha1: "d841e66df96cc492654dde179623f12ba52779f5"

Or upload it to your director with the upload-release command:

bosh upload-release --sha1 d841e66df96cc492654dde179623f12ba52779f5 \