PCF Ops Manager v2.5 Release Notes

Pivotal Cloud Foundry is certified by the Cloud Foundry Foundation for 2019.

Read more about the certified provider program and the requirements of providers.


How to Upgrade

The Upgrading Pivotal Cloud Foundry topic contains instructions for upgrading to Pivotal Cloud Foundry (PCF) Ops Manager v2.5.

Releases

Warning: Before installing or upgrading to Ops Manager v2.5, review the Critical Breaking Changes in PCF v2.5.

2.5.2

  • This patch contains no new features or fixes. It updates Ops Manager components to address dependency requirements for other products.

Ops Manager v2.5.2 uses the following component versions:

Component Version
Ops Manager2.5.1-build.169*
Stemcell250.17
BBR SDK1.14.0
BOSH Director268.6.0
BOSH DNS1.10.0
Metrics Server0.0.22
CredHub2.1.2*
Syslog11.4.0
Windows Syslog1.0.3
UAA71.0
BPM1.0.4
Networking9
OS Conf20.0.0
AWS CPI73
Azure CPI35.4.0
Google CPI29.0.1
OpenStack CPI42
vSphere CPI52.1.0
BOSH CLI5.4.0
Credhub CLI2.4.0
BBR CLI1.5.0
* Components marked with an asterisk have been updated.

2.5.1

  • [Security Fix]: This patch addresses CVE-2019-5418, a Rails file content disclosure vulnerability.
  • [Security Fix]: This patch addresses CVE-2019-5419, a Rails vulnerability that could lead to denial of service (DoS) attacks.
  • [Security Fix]: Ops Manager operators cannot set secrets that do not match the constraints defined by the must_match_regex parameter.
  • [Bug Fix]: When a redeploy is triggered by Apply Changes and that redeploy lasts multiple days, logs are generated for that entire time.
  • [UI Improvement]: The Pending Changes page for an on-demand service broker tile now warns you explicitly that changes made applies only to the broker andt p: not to service instances.
  • [UI Improvement]: The notification banner that appears when a certificate in your deployment is about to expire is updated for clarity.

Ops Manager v2.5.1 uses the following component versions:

Component Version
Ops Manager2.5.1-build.169*
Stemcell250.17
BBR SDK1.14.0
BOSH Director268.6.0
BOSH DNS1.10.0
Metrics Server0.0.22
CredHub2.1.2
Syslog11.4.0
Windows Syslog1.0.3
UAA71.0*
BPM1.0.4*
Networking9
OS Conf20.0.0
AWS CPI73
Azure CPI35.4.0
Google CPI29.0.1
OpenStack CPI42
vSphere CPI52.1.0
BOSH CLI5.4.0
Credhub CLI2.4.0*
BBR CLI1.5.0*
* Components marked with an asterisk have been updated.

2.5.0

Ops Manager v2.5.0 uses the following component versions:

Component Version
Ops Manager2.5.0-build.158*
Stemcell250.17*
BBR SDK1.14.0
BOSH Director268.6.0
BOSH DNS1.10.0
Metrics Server0.0.22
CredHub2.1.2
Syslog11.4.0
Windows Syslog1.0.3
UAA69.0
BPM1.0.3
Networking9
OS Conf20.0.0
AWS CPI73
Azure CPI35.4.0
Google CPI29.0.1
OpenStack CPI42
vSphere CPI52.1.0
BOSH CLI5.4.0
Credhub CLI2.2.1
BBR CLI1.4.0
* Components marked with an asterisk have been updated.

New Features in Ops Manager v2.5

Ops Manager v2.5 includes the following major features:

Pending Changes Page Displays Staged Changes

If you have changed the configuration of a tile in your deployment, use the Pending Changes page to review the changes to the existing manifest or configs line-by-line. Access a tile’s pending changes by clicking the See Changes button on the Review Pending Changes page.

Use the output on this page to verify accuracy and comprehensiveness before redeploying Ops Manager. This page is especially useful for deployments with more than one operator or administrator, or deployments that change due to both API and UI modifications.

For more information, see About Pending Changes for a Specific Tile.

Microsoft Azure Availability Zones Available

Ops Manager operators and administrators can now configure Availability Zones (AZs). AZs provide high availability, minimal latency, and efficient resource management for deployments around the world.

AZs are only available for new installations of Ops Manager. Existing installations that are being upgraded from v2.4 must use Availability Sets.

For more information, see Configuring BOSH Director on Azure and Configuring BOSH Director on Azure Using Terraform.

Host Group Configuration Available for vSphere Availability Zones

You can associate an Availability Zone (AZ) with a host group for Ops Manager deployments on vSphere. Host groups are subsets of vSphere clusters. Since you must associate a cluster with an AZ in vSphere deployments, host group configuration can help you manage deployment resources more precisely. Enable vSphere host groups from the Create Availability Zones pane in the BOSH Director tile.

For more information, see Create Availability Zones Page in Configuring BOSH Director on vSphere.

NATS Certificate Rotation Available in the Ops Manager API

Ops Manager allows you to regenerate and rotate the NATS certificate authority (CA). The public keys and expiration dates for the NATS CA are visible at /api/v0/deployed/certificates. The certificate itself is listed as an active CA on the certificates table in the Ops Manager database.

A new NATS CA is created every time a new Ops Manager root CA is created. This pairs the lifecycle of the NATS CA with the Ops Manager root CA. The two CAs are created, activated, and deleted in unison. When an operator uses the regenerate endpoint in the Ops Manager API, new leaf certificates are generated for each client using the NATS CA. The new certificates use the active NATS CA in the database.

For more information about regenerating and rotating certificates, see Rotating Certificates.

Pre-Created Clients Available in the Ops Manager API

You can now configure a pre-created client account to manage automation tasks and scripts for Ops Manager. To do this, you will need access to the UAA Command Line Client (UAAC) and Ops Manager API.

Pivotal recommends using client accounts for automated tasks because client accounts are not bound to the same authentication protocols as user accounts. A user account that controls automated components can cause those components to fail if the account experiences inconsistent availability due to permission or authentication issues.

You can configure a pre-created client for Ops Manager either before you deploy Ops Manager for the first time, or by adding it to an existing deployment.

For more information about Ops Manager users and clients, see Creating and Managing Ops Manager User and Client Accounts.

Apply Custom VM Extensions to the BOSH Director in the Ops Manager API

You can define custom VM extensions for the BOSH Director VM by creating them in the API and then applying them to an instance group using PUT /api/v0/staged/products/PRODUCT_GUID/JOBS/JOB_GUID/resource_config. This endpoint works for both the BOSH Director’s jobs and product tiles.

Use this endpoint to configure custom behavior for the BOSH Director VM, such as allowing the Director to read or write directly to a blobstore.

For more information about custom VM extensions, see Staged VM Extensions in the Ops Manager API documentation.

Ops Manager User Interface Text is Updated

The field names, button text, error messaging, and other textual UI elements in Ops Manager are updated. This is part of an ongoing effort to improve clarity, utility, and the user experience.

This update does not impact Ops Manager product tiles or the BOSH Director. For more information about the Ops Manager UI, see Using the Ops Manager Interface.

Store BOSH Job Credentials on tmpfs

You can choose to store credentials for BOSH jobs in temporary file storage (tmpfs). This method stores credentials in volatile memory, rather than on the persistent disk. Choosing to store credentials in tmpfs may impact your BOSH deployment’s availability if the tmpfs is refreshed or loses access to the deployment. You must recreate all VMs for this change to take effect.

To enable this feature, navigate to the Director Config section of the BOSH Director tile and enable the Store BOSH Job Credentials on tmpfs (beta) checkbox.

For more information on the Director Config forms, see IaaS-Specific Deployment Guidelines.

Forward Ops Manager Debug Logs to An External Store in the Syslog Form

You can choose to forward logs generated by debugging processes to an external source by selecting a checkbox in the Syslog pane of the Ops Manager Settings page. Forwarded logs are delivered to whatever external location you choose to receive other types of logs from Ops Manager.

To forward logs, select the Forward Debug Logs checkbox in the Syslog pane. This checkbox is deselected by default, because debug logs can be excessive and require a great deal of storage capacity. If you choose to use this option, ensure you have sufficient storage to contain the generated logs.

For more information about the Ops Manager Syslog pane, see Settings Page in the Using the Ops Manager Interface topic.

Custom Rsyslog Configuration Available in Ops Manager Syslog Template

You can further customize Syslog behavior by including configuration options in the Custom rsyslog Configuration field of the Ops Manager Settings page. This optional field lets you add more refined rules for syslog configuration than are permitted in the standard settings available in the Ops Manager UI.

If you configure custom rules and also choose the Forward Debug Logs checkbox, the rules apply before log forwarding takes place.

For more information about forwarding debug logs, see Forward Ops Manager Debug Logs to An External Store in the Syslog Form.

For more information about the Ops Manager Syslog pane, see Settings Page in the Using the Ops Manager Interface topic.

Known Issues

Ops Manager’s Syslog Template is Not Supported for Service Broker Tiles

Ops Manager’s Syslog template does not propagate to service broker tiles. Tile developers with service broker tiles should continue to use their own Syslog configurations. Service broker tiles with the Syslog template configured will not display the Syslog template.

For more information about the Syslog template, see Syslog Form Template Available for Tile Authors.

Monit Inaccurately Reports Health of UAA

When BOSH Director reboots, Monit may report UAA as running, even though its process state is unhealthy. The Monit start scripts for UAA use the UAA /healthz endpoint to verify UAA is running, but the /healthz endpoint does not know there is a database requirement. Monit detects UAA is healthy, even though UAA is stuck, and never restarts it.

To fix this, run monit restart uaa to restart UAA after Postgres is running.

For more information, see Monit reports UAA running on BOSH Director when it is actually unhealthy in the Pivotal Knowledge Base.

BPM Fails to Start Job Process

Some Monit processes fail to start. The bpm.log shows an exit status of 1 with no other cause for the failure.

BOSH Process Manager (BPM) calls runC to create a new container and launch a job process. However, runC cannot start the container because there is a stale state.json in /var/vcap/bpm/runc/CONTAINER-ID/state.json, where state.json is a zero-byte file. When running runC manually to start the job process, runC has an EOF error and the exit status is 1. runC fails to read the state.json and exits.

To resolve this issue, delete the zero-byte state.json file by deleting its parent directory with the following command: rm -rf /var/vcap/data/bpm/runc/MJRHG---
Then run monit start JOB to start the job process and review the job logs to check if there are any further failures.

For more information, see BPM fails to start job process with exit status 1 in the Pivotal Knowledge Base.

API Documentation Updates

Ops Manager v2.5 includes the following updates to the API. Some of these updates are referenced in the New Features section.

Updated Sections

The following sections of the API documentation are updated in Ops Manager v2.5:

New Sections

The following sections are new in Ops Manager v2.5:

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