Important
There is an issue with MySQL 5.5 that can cause application downtime when deploying this release. Other databases and versions are not affected by application downtime, but may have other issues.
| Database | Issue |
|---|---|
| MySQL 5.5 and earlier, MariaDB using InnoDB 5.5 | Application downtime. |
| MySQL 5.6 or later, MariaDB using InnoDB/XtraDb 5.6 | No issues. |
| PostgresSQL | No application downtime. In rare cases a deploy may fail, but succeed on a subsequent attempt. If subsequent attempts fail, follow the mitigation plan below. |
Mitigation Plan
Mitigation for cf-release
There is a cloud_controller_clock job running on each of the clock_z* instances.
If the only jobs on a clock instance are cloud_controller_clock, metron_agent, consul_agent,
and system_localhost, you can stop the entire instance with this command:
bosh stop -d DEPLOYMENT_NAME clock_z1
Repeat for each clock_z* instance.
Otherwise, for each clock instance i, do the following:,
bosh ssh -d DEPLOYMENT_NAME clock_z[i]
sudo
monit stop cloud_controller_clock
After the upgrade deployment has completed, bosh vms should report that all
clock_* instances are running. If any aren't, bosh ssh to each non-running
clock_* instance, sudo, and run monit start cloud_controller_clock.
Mitigation for cf-deployment
There is a cloud_controller_clock job on each of the scheduler instances. Unlike
for cf-release, there is only one option. The cloud_controller_clock job should be explicitly stopped
on each node as follows:
bosh ssh -d DEPLOYMENT_NAME scheduler/i
sudo
monit stop cloud_controller_clock
After the upgrade deployment has completed, bosh vms should report that all
scheduler instances are running. If any aren't, bosh ssh to each non-running
scheduler instance, sudo, and run monit start cloud_controller_clock.
Notes
Highlights
- Resolves an issue that causes tasks to sometimes be canceled prematurely or marked as failed after completing successfully.
CC API Version: 2.101.0 and 3.36.0
Service Broker API Version: 2.13
CAPI Release
- As an operator I can take a backup of only the relevant parts of the cc blobstore details
Cloud Controller
- A Cloud Foundry administrator should see a log when there is a discrepancy between Perm and CC details
- As an app dev (receiver), I can continue to bind apps to a service instance that has been shared with me when the feature flag is disabled details
- As an app dev (sharer), I can unshare a service instance from a space where I do not have access details
- As an app dev (sharer), I cannot rename a service instance that has been shared details
- As an app dev (sharer), I cannot share a service instance that is using an inactive plan details
- As an app dev (sharer), if I try to share a service instance into a space where access to that service is not enabled, the share fails details
- As an app dev (sharer), if the service instance sharing feature flag is disable, I should still be able to unshare existing shares details
- As an app dev I can filter v3 service instances by space guid details
- As an app dev, I can only see bindings in spaces that I have access to for shared service instances details
- Cloud Controller should check to see if a user can perform an action with Perm (V3) details
- Improve performance of GET /v2/service_instances details
- Permission denied while trying to V3 copy a droplet with NFS blobstore details
- Service instance sharing-related errors should usually return 422 instead of 400 details
- V3 droplet/package/other blobstore resources downloads don't work when using an NFS server details
- change tld to apps.internal details