PCF v1.12 Breaking Changes
Page last updated:
Warning: Pivotal Cloud Foundry (PCF) v1.12 is no longer supported because it has reached the End of General Support (EOGS) phase. To stay up to date with the latest software and security updates, upgrade to a supported version.
This topic describes the breaking changes you need to be aware of when upgrading to Pivotal Cloud Foundry (PCF) v1.12. For more information about important preparation steps you must follow before beginning an upgrade, see Upgrading Pivotal Cloud Foundry.
In previous versions of PCF, the Diego Brain VM ran the Cloud Controller Bridge component, which translated Cloud Controller requests into Diego API commands. The Cloud Controller Bridge conveyed communications between the Cloud Controller and Diego over plain-text HTTP.
In PCF v1.12, the Enable secure communication between Diego and Cloud Controller option in the Cloud Controller pane of the Elastic Runtime tile allows you to enable direct communications between the Cloud Controller and Diego over secure TLS and deactivate the Cloud Controller Bridge. If you deploy a fresh installation of PCF v1.12, the Enable checkbox is selected by default.
For upgrades, if you want to use this new feature, you must manually select the Enable checkbox after the upgrade is complete and then click Apply Changes. Selecting the checkbox before the upgrade results in API downtime.
In previous versions of PCF, you had the option of selecting Forward unencrypted traffic to Elastic Runtime Router in the Networking pane of Elastic Runtime. If you selected this option, you did not have to provide a certificate or private key for Gorouter configuration.
In PCF v1.12, the Gorouter and HAProxy now always listen for TLS requests. Therefore, you must configure an SSL certificate for the Gorouter and HAProxy in Elastic Runtime. You configure the Gorouter and HAProxy using the same field and with the same certificate.
In addition, you must specify TLS cipher suites for both HAProxy and the Gorouter. These cipher suites are specified independently in different fields. If you configured a previous installation with TLS cipher suites, these configurations persist through the upgrade. Make sure that you have configured the correct set of TLS cipher suites and minimum TLS version to support your client and load balancer needs.
In both cases, the HAProxy configuration is ignored if you are not using HAProxy.
For more information, see the Elastic Runtime installation topic for your IaaS.
The internal credentials that Elastic Runtime uses for inter-component communication are now generated and stored in CredHub instead of Ops Manager. For a list of the credentials migrated to CredHub, see Pivotal Elastic Runtime Release Notes.
If you want to access these credentials, you must use the CredHub CLI or the Ops Manager API instead of the Credentials tab of the Elastic Runtime tile.
In order for the CredHub API to communicate with the BOSH Director, TCP Port 8844 must be open on the networks where Ops Manager and Elastic Runtime VMs are deployed. TCP Port 8844 must be open to enable internal networking between VMs located inside the local network. For more information, see Preparing Your Firewall for Deploying PCF.
This release removes the legacy Postgres database VMs for the Cloud Controller and UAA. If your deployment was originally installed before PCF v1.6 and still uses Postgres, you must contact your dedicated Support Engineer or Platform Architect for assistance in migrating your Cloud Controller and UAA databases to MySQL. They have access to the PostgreSQL-to-MySQL Migrator tool and instructions on Pivotal Network.
If you do not migrate to MySQL before upgrading to Elastic Runtime v1.12, the upgrade fails. For more information, see Migrate the CC and UAA Databases from Postgres to MySQL.
If your existing PCF v1.11.x installation includes both PCF Runtime for Windows and MySQL for PCF v1.x, you must upgrade to MySQL for PCF v1.10.3 or later before you upgrade to PCF Elastic Runtime v1.12. For instructions on how to upgrade MySQL for PCF, see the MySQL for PCF documentation.
If you do not upgrade MySQL for PCF, the upgrade fails. For more information, see Upgrade MySQL for PCF.
We back-ported a fix from NFS 1.3.1 to NFS 1.2.1 for an incompatibility between our NFS Volume release and Diego’s container runtime, garden. But, because the fix was in the NFS Service Broker, and service bindings created by old versions of this broker won’t get migrated during upgrade, existing NFS service bindings that specify read-only mounts will still exhibit the incompatibility.
As a result, customers upgrading from versions containing nfs-volume-release < 1.2.1 that have NFS services bound read-only to their applications will see that their applications crash after upgrade.
To fix this condition, customers should unbind the service, rebind it, and then restage the application.
Alternately, customers wishing to avoid application down time can temporarily re-bind their applications as read/write before upgrading, and then swtich to read-only afterwards.
Ops Manager v1.12 uses the BOSH Command Line Interface (CLI) v2. In v2, the formatting of the CLI output has changed. If your deployment uses scripts that rely on BOSH output, you must refactor them to interpret the command output of the BOSH CLI v2. For more information about the BOSH CLI v2, see Pivotal Operations Manager Release Notes.
In PCF v1.12 and earlier, the BOSH Director may delete stemcells required by errands. This causes deployments or upgrades to fail with
Error: Stemcell doesn't exist. To prevent this error, do the following before you click Apply changes in Ops Manager to upgrade:
Download a current stemcell from Pivotal Network.
Upload the stemcell by clicking Import a Product in Ops Manager, or by manually running
bosh upload-stemcellwith the BOSH CLI.
See the Pivotal Knowledge Base article Deploy fails with Error: Stemcell doesn’t exist for details.
This known issue has been fixed in Ops Manager v2.0 and later.
If your original Elastic Runtime deployment was PCF v1.6 or earlier, you must regenerate the non-configurable Director certificates to deploy CredHub. During a deploy, CredHub attempts to verify the connection to UAA on the BOSH Director with the Ops Manager certificate Subject Alternative Name (SAN). Ops Manager v1.6 and earlier generated non-configurable certificate SANs in a format that CredHub does not understand. For more information, see CredHub Requires Director Certificate Rotation.
PCF Log Search is not compatible with PCF v1.12. If your deployment contains PCF Log Search, you must remove the product tile before upgrading to PCF v1.12. Failure to remove this product prior to the upgrade may cause issues with your deployment.
For more information, see the Upgrading Pivotal Cloud Foundry topic.