cf-release v211 is available
Dieu Cao <dcao@...>
The cf-release v211 was released on June 4th, 2015
- IMPORTANT: This release removes lucid64 stack, please ensure apps are
migrated prior to upgrade
- IMPORTANT: If using the postgres included within cf-release, please
carefully read the note below about the upgrade to postgres 9.4.2
- 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
- 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
- [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 <https://www.pivotaltracker.com/epic/show/1879702>
- cloudfoundry/cf-release #689
<https://github.com/cloudfoundry/cf-release/pull/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
<https://github.com/cloudfoundry/cf-release/pull/680>: staticfile to be
tested before nodejs/ruby buildpacks details
- cloudfoundry/stacks #16
<https://github.com/cloudfoundry/cf-release/pull/16>: Add cmake to
rootfses details <https://www.pivotaltracker.com/story/show/94022672>
- cloudfoundry/stacks #17
<https://github.com/cloudfoundry/cf-release/pull/17>: Add autoconf to
rootfs details <https://www.pivotaltracker.com/story/show/94411176>
- cloudfoundry/cf-release #682
<https://github.com/cloudfoundry/cf-release/pull/682>: Upgrading ruby
buildpack to v1.4.2 details
- cloudfoundry/cf-release #683
<https://github.com/cloudfoundry/cf-release/pull/683>: Upgrading python
buildpack to v1.3.2 details
- Make 'dea_next.stacks' overridable in the manifest. details
- cloudfoundry/cf-release #681
<https://github.com/cloudfoundry/cf-release/pull/681>: Add security
group for cf-mysql subnets on bosh-lite details
- cloudfoundry/dea_ng #164
<https://github.com/cloudfoundry/cf-release/pull/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.
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 <https://www.pivotaltracker.com/story/show/95065248>.
- repo <https://github.com/cloudfoundry/statsd-injector>.
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
right) and in a publicgoogle doc
- Story details <https://www.pivotaltracker.com/story/show/95539818>.
- Other CF Components to follow; docs to be formalized with
NOAA client library fixed Close() issue, independent of CF release.
Change is backward-incompatible.
- details <https://www.pivotaltracker.com/story/show/94103174> | cf-dev
| github diff
Removed Dropsonde protocol dependence on gogoproto for non-go builds.
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
[Bug Fix] LoggregatorClientPool no longer leaking clients to
non-existant dopplers. details
- BOSH Version: 152
- Stemcell Version: 2969
- CC Api Version: 2.28.0
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
To rollback to a previous release, you should remove
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