Changes from v1.13.0 to v1.14.0
- Verified with garden-runc-release v1.5.0.
- Verified with garden-windows-bosh-release v0.4.0.
- Verified with etcd-release v101.
- Verified with cf-mysql-release v34.
- Verified with cflinuxfs2-rootfs-release v1.114.0.
IMPORTANT: Operators using the experimental locket component to manage Diego component locks and cell registrations will need to drop the ‘locks’ table in the Diego relational database or the upgrade to Diego v1.14.0 will fail on the locket job. This backwards incompatibility results from a schema change introduced in story #141394289. Upcoming work will make the locket component capable of performing these schema and data migrations itself.
IMPORTANT: The manifest-generation system in this version of diego-release allows operators to opt into deploying the new cflinuxfs2 release in place of the cflinuxfs2-rootfs release, by supplying the
-r flag on the script. Since the cflinuxfs2-rootfs release will stop receiving updates in mid-May, within a few minor versions the Diego manifest-generation system will switch to make the new cflinuxfs release the only deployment option, and the
-r flag will be a no-op.
- As a Diego operator, I expect to be able to configure InnoDB log-flushing parameters on the cf-mysql release in order to improve BBS and locket performance at scale
- As a Diego operator, I expect the executor run step always to complete its perform call after being cancelled
De-Consuling Locks (Experimental)
- As a Diego operator, I expect the content of the locket database not to grow without bound
- As a Diego operator, I expect the cell rep to continue running even if unable to maintain its existing cell registration with locket
- As a Diego operator, I expect to be able to opt the Windows Diego cells into registering themselves with locket instead of consul
- As a CF operator, I expect to be able to deploy Diego with the “cflinuxfs2” release instead of the “cflinuxfs2-rootfs” release
cleanup_process_dirs_on_waitto true in the manifest generation
Test Suites and Tooling
- As a Diego contributor, I expect the Diego team CI to run unit tests for Diego cell libraries and components on Windows
- As a Diego operator, I expect to be able to run a vizzini errand VM from the cf-deployment manifest
BOSH job changes
BOSH property changes
benchmark-bbs.reseed_database: Whether to reseed the dataset for the BBS benchmark tests.
BOSH link changes
Upload this release version to the Director:
$ bosh upload-release https://bosh.io/d/github.com/cloudfoundry/diego-release?v=1.14.0 --sha1 130fd675b00490c6b3f552f5593aed4a116ab9d8
Modify deployment manifest to use this release in addition to any other used releases:
releases: - name: diego version: "1.14.0"
Finally add needed deployment jobs and specify values for required properties.
Optionally download sha1: 130fd675b00490c6b3f552f5593aed4a116ab9d8 release tarball locally:
# ...or download it directly using curl $ curl -L -J -O https://bosh.io/d/github.com/cloudfoundry/diego-release?v=1.14.0 # or with wget... $ wget --content-disposition https://bosh.io/d/github.com/cloudfoundry/diego-release?v=1.14.0