Pivotal Cloud Foundry Ops Manager v1.10 Release Notes
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 installation.zip into 1.10.0 was failing with a Nil Class error.
|BOSH Director: 261.4|
|AWS CPI: 62|
|Azure CPI: 22|
|Google Cloud Platform CPI: 25.6.2|
|OpenStack CPI: 27|
|vSphere CPI: 38|
Version 1.10.0 of Ops Manager consists of the following component versions:
|BOSH Director: v261.4|
|AWS CPI: TK|
|Azure CPI: TK|
|Google Cloud Platform CPI: TK|
|OpenStack CPI: TK|
|vSphere CPI: TK|
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
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
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.
Operators can now deploy Ops Manager in an Azure Government Cloud environment. For more information, see the Deploying PCF on Azure Government Cloud topic.
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.
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.
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_idproperty. 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
- HM Alerts as BOSH Events: You can now view BOSH Health Monitor alerts, such as process restarts and monit alerts, with the
bosh eventscommand. The
bosh eventscommand 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.
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
vcapuser. Users must belong to this group to use SSH.
- Log Agent API access events are sent in CEF format to syslog via the
For a full list of updates and fixes in the new stemcell that Ops Manager uses, see the stemcell 3363 release notes.