VMware Tanzu Application Service for VMs v2.10 Release Notes
This topic contains release notes for VMware Tanzu Application Service for VMs (TAS for VMs) v2.10.
Ops Manager is certified by the Cloud Foundry Foundation for 2020.
Release Date: 08/07/2020
- [Security Fix] Remove UAA client secret from logs during installation
- [Feature Improvement] Expose GCS blobstore storage account timeout values
- [Feature Improvement] Upgrade Percona-XtraDB-Cluster to version 5.7.30-31.43
- [Bug Fix] Fix issue where requests to internal routes could fail due to incorrect case-sensitivity in DNS lookup in the service discovery controller.
- [Bug Fix] Apps Manager accounts for App Metrics’ duplicate counts of HTTP requests, HTTP latency, and HTTP errors on App page Overview tab graphs
- [Bug Fix] System Metrics Scraper/Prom Scraper — Fixes a bug that causes excess log volume and increases scrape interval to reduce metric volume
- Bump ubuntu-xenial stemcell to version
- Bump cf-cli to version
- Bump cf-networking to version
- Bump cflinuxfs3 to version
- Bump dotnet-core-offline-buildpack to version
- Bump garden-runc to version
- Bump go-offline-buildpack to version
- Bump nginx-offline-buildpack to version
- Bump nodejs-offline-buildpack to version
- Bump notifications-ui to version
- Bump php-offline-buildpack to version
- Bump push-apps-manager-release to version
- Bump pxc to version
- Bump python-offline-buildpack to version
- Bump ruby-offline-buildpack to version
- Bump silk to version
- Bump system-metrics-scraper to version
Release Date: July 31, 2020
To upgrade to TAS for VMs v2.10, see Upgrading Ops Manager.
When upgrading to TAS for VMs v2.10, be aware of the following upgrade considerations:
If you previously used an earlier version of TAS for VMs, you must first upgrade to TAS for VMs v2.9 to successfully upgrade to TAS for VMs v2.10.
Some partner service tiles may be incompatible with Ops Manager v2.10. VMware is working with partners to ensure their tiles are updated to work with the latest versions of Ops Manager.
For information about which partner service releases are currently compatible with Ops Manager v2.10, review the appropriate partners services release documentation at https://docs.pivotal.io or contact the partner organization that produces the tile.
TAS for VMs v2.10 includes the following major features:
When you configure an aggregate syslog drain in TAS for VMs v2.10, by default you receive logs only. You do not also receive metrics. By not including metrics alongside logs, your syslog drain uses fewer resources and reduces network traffic between TAS for VMs components and your external logging service.
If you want the aggregate drain to send metrics along with logs, you can modify your drain URLs.
To continue to see metrics in your drains after upgrading to TAS for VMs v2.10:
- Navigate to the Ops Manager Installation Dashboard.
- Click the VMware Tanzu Application Service for VMs tile in the Installation Dashboard.
- Select System Logging.
- For Address, enter the hostname or IP address of the syslog server and append
?include-metrics-deprecated=true. For example,
- Click Save.
For more information about configuring aggregate syslog drains, see Configure System Logging in Configuring TAS for VMs.
You can choose to prevent the Loggregator Firehose from emitting app logs but still allow the Firehose to emit app metrics. Disabling logs in the Firehose helps reduce the load on TAS for VMs by allowing you to scale down Doppler and Traffic Controller VMs.
To configure the Firehose to receive only app metrics, you must select the Disable logs in Firehose, Log Cache syslog ingestion, Enable V1 Firehose, and Enable V2 Firehose checkboxes in the System Logging pane of the TAS for VMs tile. You must also configure Aggregate log and metric drain destinations in the System Logging pane of the TAS for VMs tile. For more information, see Configure System Logging in Configuring TAS for VMs.
TAS for VMs v2.10 introduces RFC3339 log format support for several TAS for VMs components. You can configure these components to produce logs with human-readable RFC3339 timestamps with the Timestamp format for component logs configuration option in the TAS for VMs tile. Logs that use human-readable timestamps are often easier to debug.
RFC3339-formatted timestamps follow the RFC3339 spec, include nine points of precision where possible, and are in UTC. For example:
For more information about configuring the Timestamp format for component logs field, see System Logging in Configuring TAS for VMs.
In TAS for VMs v2.10.0, if you select the Converge to human-readable RFC3339 format option under Timestamp format for component logs, then the following components and related jobs use RFC3339 timestamps:
Components not listed in the table above either do not support RFC3339 timestamps in TAS for VMs v2.10.0 or were already using the RFC3339 timestamp format. Selecting Converge to human-readable RFC3339 format ensures that any additional components that add support for RFC3339 timestamps in later releases of TAS for VMs v2.10 are automatically configured to use RFC3339 timestamps after you upgrade.
To confirm which TAS for VMs components use RFC3339 timestamps:
Go to the
OPS-MANAGER-FQDNis the fully-qualified domain name of your Ops Manager instance.
For each component, confirm that the
logging.format.timestampproperty is set to
Breaking Change: The Timestamp format for component logs feature replaces the Format of timestamps in Diego logs feature in the App Containers pane of the TAS for VMs tile. However, when you upgrade to TAS for VMs v2.10, the option that was selected under Format of timestamps in Diego logs in your previous deployment is applied to Timestamp format for component logs. For more information, see Timestamp Format for Component Logs Replaces Timestamp Format for Diego Logs in Ops Manager and Runtime Breaking Changes.
You can supply sticky session cookie names for the Gorouter to use when handling sticky sessions. The Gorouter uses these cookies to support session affinity, or sticky sessions. For more information, see Session Affinity in HTTP Routing.
By default, the Gorouter uses
JSESSIONID. Some apps require a different session name.
For example, Spring WebFlux requires
SESSION for the session cookie name.
To supply cookie names, see Configure Networking in Configuring TAS for VMs.
TAS for VMs v2.10 includes the following improvements to App Autoscaler:
- App Autoscaler no longer returns an error when you set an
executes_attime that is in the past. This lets you re-use scheduled limit changes through the Scheduler API. App Autoscaler calculates future execution dates based on the past date.
- You can use rules that are based on the HTTP throughput metric when the number of the requests is high. For information about the metric, see Default Metrics for Scaling Rules.
TAS for VMs v2.10 paired with cf CLI v7 allows you to do the following:
- Push updates to apps without incurring downtime. See Rolling App Deployments.
- Exercise granular control over the
cf pushprocess. See Running cf push Sub-Step Commands.
- Use a single command to push apps that run multiple processes. See Pushing an App with Multiple Processes.
- Run additional processes in the same container as your app. See Pushing Apps with Sidecar Processes.
- Add metadata to resources such as spaces and apps. See Using Metadata.
For more information about the GA release of cf CLI v7, see Cloud Foundry Further Simplifies Modern App Development: An Inside Look at the New cf CLI v7.
TAS for VMs v2.10 includes the following known issues:
If you disable the V1 Firehose and you are using a version of the cf CLI earlier than v6.50, you may encounter errors when you push an app or view the logs for an app. The logs exist but are not visible from the cf CLI.
Running the following commands results in errors:
Timeout trying to connect to NOAA
timeout connecting to log server, no log will be shown
Despite the log-related errors,
cf push works correctly and pushes the app.
To avoid encountering errors after disabling the Loggregator V1 Firehose, upgrade to cf CLI v6.50 or later.