v211

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

Runtime

• Remove lucid64 stack completely from cf-release details
  • Please ensure all your applications have migrated to the cflinuxfs2 stack prior to upgrading to this release
  • Once all apps have been migrated to the new stack, Operators will need to manually delete the lucid64 stack via the cc api using the admin user.
  • http://apidocs.cloudfoundry.org/211/stacks/delete_a_particular_stack.html
• 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

Loggregator

• If no Dopplers available in an AZ, Metron will now fail over across AZs. [details] (https://www.pivotaltracker.com/story/show/86649938)

• 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.

  • details.
  • repo.

• 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.

  • details | cf-dev announcement | github diff

• Removed Dropsonde protocol dependence on gogoproto for non-go builds. details

• Increase doppler marshal/unmarshal efficiency to compensate for message size changes. [details] (https://www.pivotaltracker.com/story/show/93439456)

• [Bug Fix] Syslog drain binder is no longer leaking connections to cloud_controller. [details] (https://www.pivotaltracker.com/story/show/93932106)

• [Bug Fix] LoggregatorClientPool no longer leaking clients to non-existant dopplers. [details] (https://www.pivotaltracker.com/story/show/95008094)

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

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