LATEST VERSION: 1.14 - RELEASE NOTES

Redis for PCF Release Notes

Page last updated:

View Release Notes for Another Version

To view the release notes for another product version, select the version from the dropdown at the top of this page.

v1.11.5

Release Date: July 25, 2018

Fixes

  • Fixes previous version not working with any 3468 stemcell version.

Known Issues

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • The redis-odb fails if arbitrary parameters are changed in an update-service command.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

Compatibility

Component Version
Stemcell 3468.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.1.0
on-demand-service-broker v0.19.0
consul v192.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

v1.11.4

Release Date: July 16, 2018

WARNING: If you are upgrading from v1.11.0 or v1.11.1, you might need to take manual steps to avoid data loss. See this Knowledge Base article, Redis Tile Upgrade to v1.11.0 or v1.11.1 May Result in Loss of Persistent Data.

It is safe to upgrade directly from v1.10.

Features

  • This release updates the packaged golang to v1.10.3.

Fixed Issues

  • The default persistence for on-demand instances is now partial persistence using RDB files. This fixes the issue of disk usage inflation from frequent instance restarts.

  • Fixes an intermittent issue that can cause executing a restore to fail and leave the CONFIG command unaliased.

Compatibility

Component Version
Stemcell 3468.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.1.0
on-demand-service-broker v0.19.0
consul v192.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

Known Issues

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • The redis-odb fails if arbitrary parameters are changed in an update-service command.

  • Can only be installed with specific stemcell version: 3468.54.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

v1.11.3

Release Date: March 7, 2018

WARNING: If you are upgrading from v1.11.0 or v1.11.1, you might need to take manual steps to avoid data loss. See this Knowledge Base article, Redis Tile Upgrade to v1.11.0 or v1.11.1 May Result in Loss of Persistent Data.

It is safe to upgrade directly from v1.10.

Features

This release updates the stemcell verison.

Compatibility

Component Version
Stemcell 3468.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.0.1
on-demand-service-broker v0.19.0
consul v191.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

Known Issues

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • Default persistence is set to full persistence using an AOF file. If an instance is restarted frequently (for example, for upgrades), this file can grow significantly, leading to very large persistent disk usage. If your Redis instance has significantly larger persistent disk usage than expected, check the size of your appendonly.aof file (usually at /var/vcap/store/redis) to verify if this is the source of the usage. If so, you can mitigate this by running the BGREWRITEAOF command.

  • The redis-odb fails if arbitrary parameters are changed in an update-service command.

  • Switching Lua Scripting to off for plans with preexisting instances can cause upgrade errand failures. For information about resolving this issue, see Upgrade errand fails with Unknown command eval.

  • Executing a restore may fail to complete and leave the CONFIG command unaliased.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

v1.11.2

Release Date: February 14, 2018

WARNING: If you are upgrading from v1.11.0 or v1.11.1, you might need to take manual steps to avoid data loss. See this Knowledge Base article, Redis Tile Upgrade to v1.11.0 or v1.11.1 May Result in Loss of Persistent Data.

It is safe to upgrade directly from v1.10.

Fixed Issues

  • Fixes a bug where upgrading the Redis for PCF tile may cause the broker to change availability zone and orphan its disk.

Compatibility

Component Version
Stemcell 3445.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.0.0
on-demand-service-broker v0.19.0
consul v191.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

Known Issues

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • Default persistence is set to full persistence using an AOF file. If an instance is restarted frequently (for example, for upgrades), this file can grow significantly, leading to very large persistent disk usage. If your Redis instance has significantly larger persistent disk usage than expected, check the size of your appendonly.aof file (usually at /var/vcap/store/redis) to verify if this is the source of the usage. If so, you can mitigate this by running the BGREWRITEAOF command.

  • Switching Lua Scripting to off for plans with preexisting instances can cause upgrade errand failures. For information about resolving this issue, see Upgrade errand fails with Unknown command eval.

  • Executing a restore may fail to complete and leave the CONFIG command unaliased.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

v1.11.1

Release Date: February 2, 2018

Fixed Issues

  • This release reverts implementation of the colocated errands feature for the Redis for PCF v1.11 line, due to incompatibility with some PCF v1.12 installations.

Compatibility

Component Version
Stemcell 3445.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.0.0
on-demand-service-broker v0.19.0
consul v191.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

Known Issues

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • For some IAASs and Multi AZ configurations, the dedicated and shared-VM broker may shift AZs when upgrading to v1.11.0 or v1.11.1. This can cause the broker to orphan its disk. In this case, shared-VM instances are lost and dedicated VMs may be overwritten. You may need to take manual steps to avoid data loss. See this Knowledge Base article.

  • Default persistence is set to full persistence using an AOF file. If an instance is restarted frequently (for example, for upgrades), this file can grow significantly, leading to very large persistent disk usage. If your Redis instance has significantly larger persistent disk usage than expected, check the size of your appendonly.aof file (usually at /var/vcap/store/redis) to verify if this is the source of the usage. If so, you can mitigate this by running the BGREWRITEAOF command.

  • Switching Lua Scripting to off for plans with preexisting instances can cause upgrade errand failures. For information about resolving this issue, see Upgrade errand fails with Unknown command eval.

  • Executing a restore may fail to complete and leave the CONFIG command unaliased.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

v1.11.0

Release Date: January 25, 2018

Features

  • The on-demand service is now at feature parity with the dedicated-VM service. The dedicated-VM service will be deprecated. Please move apps to the on-demand service.

  • All releases used within the tile use SHA-2 checksums.

  • The tile uses colocated errands to decrease errand runtime and VM footprint for Pivotal Cloud Foundry (PCF) v2.0 and later.

  • Users can manually and automatically back up and restore data to on-demand instances.

  • For security reasons, the permissions for all Redis files for the on-demand service have been reduced to least privileged user and lowered to minimum needed.

  • Defaults for on-demand VM and disk sizes encourage correct configuration and sizing of plans.

  • lua-timeout-limit, a Redis configuration that is exposed to app developers through arbitrary parameters, has been disabled for security concerns.

Compatibility

Component Version
Stemcell 3445.x
PCF* v1.12.x and v2.0.x
cf-redis-release v432.0.0
on-demand-service-broker v0.19.0
consul v191.0.0
routing v0.169.0
service-metrics v1.5.11
service-backup v18.1.9
syslog-migration v10.0.0
loggregator v101.3
Redis OSS v3.2.11

* As of PCF v2.0, Elastic Runtime is renamed Pivotal Application Service (PAS).

Known Issues

  • The errands for Redis for PCF v1.11.0 might not run successfully on some PCF v1.12 environments. The underlying cause is being investigated, and a v1.11.1 patch is planned.

  • The redis-odb service broker listens on 12345. This is inconsistent with other services.

  • The When Changed option for errands has unexpected behavior in what changes trigger the errand. Do not select this option for errands.

  • For some IAASs and Multi AZ configurations, the dedicated and shared-VM broker may shift AZs when upgrading to v1.11.0 or v1.11.1. This can cause the broker to orphan its disk. In this case, shared-VM instances are lost and dedicated VMs may be overwritten. You may need to take manual steps to avoid data loss. See this Knowledge Base article.

  • Default persistence is set to full persistence using an AOF file. If an instance is restarted frequently (for example, for upgrades), this file can grow significantly, leading to very large persistent disk usage. If your Redis instance has significantly larger persistent disk usage than expected, check the size of your appendonly.aof file (usually at /var/vcap/store/redis) to verify if this is the source of the usage. If so, you can mitigate this by running the BGREWRITEAOF command.

  • Switching Lua Scripting to off for plans with preexisting instances can cause upgrade errand failures. For information about resolving this issue, see Upgrade errand fails with Unknown command eval.

  • Executing a restore may fail to complete and leave the CONFIG command unaliased.

  • The Service Brokers do not specify a buildpack in the Redis App pushed during their smoke tests. As a result, if an environment has a large number of buildpacks, the smoke tests may timeout looping through the buildpacks in order to find the appropriate one.

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