diego/0.1440.0
You can find the source of this version on GitHub at cloudfoundry/diego-release. It was created based on the commit deb51e25.
Release Notes¶
Changes from v0.1439.0 to v0.1440.0
- Depends on garden-linux-release v0.326.0.
- Depends on etcd-release 18.
Important changes
The recommended version of garden-linux-release, v0.326.0, has changed its backing layer system to use aufs instead of btrfs. Please see the notes for this Garden-Linux final release for more details.
If you are upgrading from garden-linux-release v0.316.0 or earlier, we recommend you recreate your Diego Cells during the upgrade to v0.326.0 and later, to avoid issues with residual containers on the btrfs volume that garden-linux will be unable to delete. You can do this intentionally with the --recreate flag on bosh deploy, or incidentally by deploying a new stemcell at the same time. If you’ve been waiting to upgrade your stemcell, now’s a great time!
Also, if you are using the generate-deployment-manifest script to produce your Diego deployment manifest, please be aware that it has incorporated a few changes to its arguments:
- The optional ‘director-uuid’ stub argument is now removed, as the BOSH director UUID will be taken from the CF manifest.
- There is a new required argument that expects a stub optionally specifying the versions of the Diego, Garden-Linux, and ETCD releases to deploy. If any of these versions are missing, they will default to ‘latest’.
Other significant changes
- Errors about invalid DesiredLRPs should not prevent the nsync-bulker from bumping the cf-apps domain
- As a Diego developer, I would like documentation about which BBS API endpoints are public or private
- If the rep gets an unrecoverable error from garden when starting up, it should exit immediately
- Diego ssh proxy template should not require
ssh_proxy.diego_credentialsto be set if the diego authenticator is not enabled - environment variables from the default running group sometimes do not appear in the apps environment
- Remove director_uuid argument from generate-deployment-manifest
- diego manifest generation should use the cf release version specified in the cf-release manifest used as a stub rather than defaulting to latest
- As a Diego operator, I should be able to specify versions of the diego, etcd, and garden-linux releases when generating a manifest
- cloudfoundry-incubator/diego-release #85: Enables other stub configurations to be merged in after the enable_ss…
- cloudfoundry-incubator/consuladapter #1: Add KillWithFire func
- cloudfoundry-incubator/candiedyaml #16: Fix panic for strings less than 3 chars
- cloudfoundry-incubator/executor #15: Fix race condition in run step test
- Roll back garden-linux-release on CI to 0.316
- enable aufs on ci
- Enable aufs on CI
BOSH property changes
None.
Usage¶
You can reference this release in your deployment manifest from the releases section:
- name: "diego" version: "0.1440.0" url: "https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1440.0" sha1: "fbbdc3ac1fe5b48332f5703cf021d5022cbd7ca4"
Or upload it to your director with the upload-release command:
bosh upload-release --sha1 fbbdc3ac1fe5b48332f5703cf021d5022cbd7ca4 \ "https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1440.0"
Jobs¶
- acceptance-tests
- auctioneer
- bbs
- benchmark-bbs
- canary
- cc_uploader
- converger
- file_server
- nsync
- rep
- rootfses
- route_emitter
- smoke-tests
- ssh_proxy
- stager
- tps
- vizzini