PCF v1.12 Breaking Changes
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, Gorouter and HAProxy now always listen for TLS requests. Therefore, you must configure an SSL certificate for Gorouter and HAProxy in Elastic Runtime. You configure Gorouter and HAProxy using the same field and with the same certificate.
In addition, you must specify TLS cipher suites for both HAProxy and 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.
See the Elastic Runtime installation instructions for your IaaS for more information.
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 1.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 1.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.
Ops Manager v1.12.0 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 1.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 1.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.