Pivotal Cloud Foundry v1.10

Pivotal Cloud Foundry Ops Manager v1.10 Release Notes

How to Upgrade

The procedure for upgrading to Pivotal Cloud Foundry (PCF) Ops Manager v1.10 is documented in the Upgrading Pivotal Cloud Foundry topic.


  • Ops Manager can now be deployed in the Azure German Cloud. For detailed step-by-step instructions on how to deploy in the Azure German Cloud, please refer to the documentation here
  • Fixed a bug where importing the into 1.10.0 was failing with a Nil Class error.
BOSH Director: 261.4
bosh-init: v.0.0.101
Stemcell: 3363.10
Azure CPI: 22
Google Cloud Platform CPI: 25.6.2
OpenStack CPI: 27
vSphere CPI: 38
UAA: 27


Version 1.10.0 of Ops Manager consists of the following component versions:

BOSH Director: v261.4
bosh-init: v0.0.100
Stemcell: 3363.x
Azure CPI: TK
Google Cloud Platform CPI: TK
OpenStack CPI: TK
vSphere CPI: TK

New Features in Ops Manager v1.10.0

Ops Manager API

Operators can now use the API to automate more tasks, such as configuring tiles, uploading tiles, and fetching upgrades from Pivotal Network. To view the Ops Manager API documentation, browse to https://YOUR-OPS-MANAGER-FQDN/docs.

New Endpoints

The Ops Manager API adds the following endpoints:

  • PUT /api/v0/staged/director/network_and_az: Operators can assign a network and singleton availability zone for the Ops Manager Director tile.
  • GET /api/v0/staged/cloud_config: Operators can fetch a BOSH cloud config based on the staged state of Ops Manager.
  • GET /api/v0/deployed/cloud_config: Operators can fetch a BOSH cloud config based on the deployed state of Ops Manager.
  • GET /api/v0/certificate_authorities: Operators can list all root certificate authorities for Ops Manager.
  • POST /api/v0/certificate_authorities: Operators can create a root certificate authority.
  • POST /api/v0/certificate_authorities/active/regenerate: Operators can rotate non-configurable certificates by deleting all non-configuration certificates and then regenerating them.

    Note: For more information about using the Ops Manager API for certificate rotation, see the Certificate Rotation section below.

  • POST /api/v0/certificate_authorities/generate: Operators can generate an additional root certificate authority.
  • POST /api/v0/certificate_authorities/:certificate_authority_guid/activate: Operators can activate a root certificate authority, and make all others inactive.
  • DELETE /api/v0/certificate_authorities/:certificate_authority_guid: Operators can delete a specific inactive certificate authority from Ops Manager.
  • POST /api/v0/staged/installations/commit: Operators can save the installation state as if the deployment was triggered by clicking Apply Changes, preparing the installation manifest. Operators can then fetch the manifest using the /api/v0/deployed/product/[product_id]/manifest endpoint.

Certificate Rotation

Ops Manager ships with a Certificate Authority (CA). This CA generates certificates that are used for communication across various PCF components. These certificates are non-configurable.

Ops Manager now allows you to regenerate non-configurable TLS/SSL certs using the API. See the Rotating Non-Configurable TLS/SSL Certificates topic for more information.

Ops Manager also allows operators to use an API endpoint to add their own custom CA authority. If added, this custom CA will be used to sign all non-configurable certificates and deployed across all relevant PCF components.


Previous versions of PCF used SHA-1 hashes, while PCF v1.10 uses SHA-2 by default. Both Operations Manager installations and certificates provided by PCF use SHA-2 hashes.

You cannot obtain SHA-2 by upgrading existing environments to PCF v1.10. However, you can convert existing SHA-1 hashes into SHA-2 hashes by rotating your Ops Manager certificates by following the procedure in Regenerating and Rotating Non-Configurable TLS/SSL Certificates.

Azure Government Cloud

Operators can now deploy Ops Manager in an Azure Government Cloud environment. For more information, see the Deploying PCF on Azure Government Cloud topic.

Smart Errands

Errands are scripts that Ops Manager runs to automate tasks. In PCF 1.10, Ops Manager provides three configurations for errands:

  • On: The errand always runs.
  • Off: The errand never runs.
  • When Changed: The errand runs only if the associated product manifest has changed since the last successful errand run.

If a tile developer does not specify a default configuration for an errand, then Ops Manager applies the When Changed configuration.

Operators should set errand configurations to On for any tile that pushes apps. For example, if your deployment includes the Single Sign-On, Push Notification Service, or PCF Metrics tiles, the errands for these tiles must run automatically to keep up with buildpack patches.

See the Managing Errands in Ops Manager topic for more information.

BOSH Updates

The following list sections updates in the new BOSH version that are not exposed by Ops Manager, but may be helpful for operators and tile developers for improving their workflows.

BOSH Director

Ops Manager v1.10.0 uses BOSH v261, which includes the following changes to the BOSH Director:

  • Context IDs for Tasks: The Tasks endpoint for the BOSH Director API includes a context_id property. This feature is particularly useful in tracking multiple BOSH tasks that are related. For example, PCF On-Demand Services uses it to track the multiple BOSH tasks involved in the cf create-service process.
  • HM Alerts as BOSH Events: You can now view BOSH Health Monitor alerts, such as process restarts and monit alerts, with the bosh events command. The bosh events command provides a historic view of your system, including events such as the creation of VMs. For more information, see the BOSH Events documentation.
  • Event filtering query parameters: If you use v2 of the BOSH CLI, you can now use filtering flags for detailed BOSH event recording and querying. For more information, see the BOSH Events documentation.

For a full list of updates and fixes in the new BOSH version that Ops Manager uses, see the BOSH release notes, beginning with v261.


Ops Manager v1.10.0 uses Stemcell 3363.10. Here are some of the major changes in Stemcell 3363:

  • Additional auditd rules
  • A new group, bosh_sshers, assigned to the vcap user. Users must belong to this group to use SSH.
  • Log Agent API access events are sent in CEF format to syslog via the vcap.agent topic.

For a full list of updates and fixes in the new stemcell that Ops Manager uses, see the stemcell 3363 release notes.

Create a pull request or raise an issue on the source for this page in GitHub