You can find the source of this version on GitHub at cloudfoundry/diego-release. It was created based on the commit
Changes from v0.1478.0 to v0.1479.0
- Verified with garden-linux-release v0.339.0.
- Verified with garden-runc-release v0.4.0.
- Verified with etcd-release v58.
- Verified with cflinuxfs2-rootfs-release v1.17.0.
IMPORTANT: This release corrects a bug in the execution of Docker-image-based CF apps wherein the
TMPDIR environment variables were always set to
app/tmp. With this release, they will instead be set to the values specified in the CF app configuration, in the Docker image itself, or, in the case of
HOME, the default home directory of the user running the start command, in that order.
- As a CF Community member, I would like to see the Diego team’s benchmark BBS results
- BBS benchmarks should organize report files in one folder per benchmark run
BBS Relational Datastore (Experimental)
- Explore Diego BBS performance with a Postgres 9.4.6 backing store to discover any performance issues resulting from hand-rolled upserts
- As a Diego operator, I expect garden-linux to be configured to destroy containers on startup so that the rep does not always have to do it itself
- As a Diego operator, I expect components that register themselves as services with consul DNS should continue to register correctly after interruptions in consul server availability
- As an app developer, I expect that the system should unregister HTTP routes for instances that are no longer desired (in flight)
Volume Support (Experimental)
- Add metrics and logging to volman
- extract voldriver into it’s own repo
- minimal test coverage for cmd/volman
- As a CF user, I expect Docker-image-based apps to have their HOME and TMPDIR env vars set either from the image environment or from the app environment so that they operate correctly (in flight)
App Logging and Metrics
- As a CF app operator, I would like to see more frequent updates of metrics for my app instances (in flight)
- As an developer, I expect to see log lines from the cell when my app containers are destroyed so that I can better understand the lifespan of my instances
Component Logging and Metrics
- As a Diego operator, I would like each final version of diego-release to have a complete list of metrics emitted by the Diego components with types and descriptions (in flight)
Test Suites and Tooling
- As a Diego developer, I expect the vizzini errand script to write its stdout and stderr out to files in /var/vcap/sys/log
- Fix failing tests in docker_app_lifecycle/builder
- Fix data race in dockerapplifecycle tests
- Explore diego-release deployment and ctl scripts with credentials with special characters to discover failures to encode credentials correctly
- As a Diego operator, I would like the diego-release documentation to include instructions for deploying Diego to a minimal AWS environment
- Document the public Cells API on the BBS
- Document the Diego container runtime environment
- As a CF contributor, I expect to find the Diego-owned CF Golang repositories in the cloudfoundry GitHub organization, imported and referred to via the code.cloudfoundry.org domain
- As a CF contributor, I expect to find the Diego-owned pivotal-golang repositories migrated into the cloudfoundry GitHub organization, imported and referred to via the code.cloudfoundry.org domain
BOSH job changes
BOSH property changes
diego.executor.container_metrics_report_interval: Interval on which the cell rep should report container metrics.
You can reference this release in your deployment manifest from the
- name: "diego" version: "0.1479.0" url: "https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1479.0" sha1: "9bf81c034afe32da3ae29e93f99cde7b6dee8ad5"
Or upload it to your director with the
bosh upload-release --sha1 9bf81c034afe32da3ae29e93f99cde7b6dee8ad5 \ https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1479.0