cloudfoundry/diego-release v2.7.0

Diego v2.7.0 - DO NOT USE

on GitHub

DO NOT USE

IMPORTANT – DO NOT USE: The Diego team has identified an issue with this release in which the Diego cell reps may crash when in evacuation mode during cell VM draining. This crash may result in reduced availability of application instances during rolling deploys, as replacement application instances may not being scheduled and started for instances on draining cell VMs.

The Diego team will have a resolution for this issue in the next final Diego release, which we will produce as soon as possible. In the meantime, if you have already deployed Diego v2.7.0, we recommend that the next time you update your Diego cells you downgrade to Diego v2.6.0, which does not have this issue with cell rep evacuation.

For CF environments with route integrity enabled, this issue may also result in the gorouters returning 502 errors to clients if they accumulate a large enough number of stale application route registrations. In this case, we also recommend that operators restart their gorouters after any rolling deploy in which Diego cells running v2.7.0 have been drained in order to remove these stale route registrations.

UPDATE: Diego v2.7.1 resolves this issue.

Changes from v2.6.0 to v2.7.0

• Verified with cloudfoundry/cf-deployment @ 94e1d26898a93058160227071d47587f646f35d5.
• Verified with garden-runc-release v1.12.1.
• Verified with garden-windows-bosh-release v0.14.0.
• Verified with cflinuxfs2-release v1.208.0.

Significant changes

Container Execution

• cloudfoundry/executor #31: Why do non-cacheable blobs fail?

App Logging and Metrics

• As a CF app developer, I expect to see log messages that indicate when CF is replacing an app instance on an evacuating cell so that I can understand that my app instance has not itself failed

Component Logging and Metrics

• As a Diego operator, I expect each Locket instance to emit its LocksExpired and PresencesExpired metrics periodically so that I can view them continually and derive rates of change from them
• As a lager library user, I expect the lager/chug package to process the improved lager log format so that I can continue to use it to relog lager-formatted output
• As a CF operator, I expect the route-emitter to log an appropriate volume without redundancies so that I do not have to aggregate logs of little to no value

Dependencies

• As a CF operator, I expect to downgrade to Golang 1.9.6+ so that the cell rep can continue to download assets from external sources over TLS
• Switch to using pxc-release instead of cf-mysql-release in some Diego CI environments

Documentation

• cloudfoundry/diego-release #390: Contributing docs
• cloudfoundry/bbs #29: fix typo

BOSH job changes

None.

BOSH property changes

None.

BOSH link changes

None.