diego/0.1454.0
You can find the source of this version on GitHub at cloudfoundry/diego-release. It was created based on the commit 72b65532.
Release Notes¶
Changes from v0.1453.0 to v0.1454.0
- Depends on garden-linux-release v0.333.0.
- Depends on etcd-release v36.
Significant changes
Operators can now install a set of trusted system certificates in the default /etc/ssl/certs trust store of the cflinuxfs2 rootfs. This is particularly useful if your cflinuxfs2-based instances communicate with external services signed by a custom CA, in which case you can use this feature to install that CA certificate in all the instances.
To install the certificates, supply the contents of the PEM-encoded certificates in the diego.rootfs_cflinuxfs2.trusted_certs property in the Diego deployment manifest. As with other PEM-encoded manifest data, you may wish to use the YAML | block-literal syntax to specify the property, as follows:
properties:
diego:
rootfs_cflinuxfs2:
trusted_certs: |
-----BEGIN CERTIFICATE-----
(cert number 1 data)
-----END CERTIFICATE-----
# comments outside the PEM boundaries will be ignored
-----BEGIN CERTIFICATE-----
(cert number 2 data)
-----END CERTIFICATE-----
If you are using the spiff-based manifest-generation scripts, this property can also be specified in the property-overrides stub.
Custom CAs
- As a CF user, I expect all Tasks and LRPs using the cflinuxfs2 rootfs to contain trusted certificates in their default trust store
- As a CF user, I expect trusted certificates to be available to cflinuxfs2- and Docker-image app instances in a conventional location (in flight)
SSH
- investigate whether we can use CF_INSTANCE_PORTS instead of rewriting diego-sshd port arguments
- cloudfoundry-incubator/diego-ssh #17: Rewrite listen address using CF_INSTANCE_PORTS on Windows
Routing
- The route-emitter should log and emit metrics if it detects two distinct instances with the same address in its in-memory routing table
- cloudfoundry-incubator/nsync #6: Dont populate cf-routes if CC does not send routes
- developer should be able to verify that when deleting an app or route, it’s route_mappings are also deleted (in flight)
Manifest Generation
- As a CF+Diego operator, I would like to use the Diego team’s tooling to deploy CF and Diego to an AWS environment
- As a Diego operator, I would like a script to generate a vizzini errand manifest for my Diego deployment
Dependencies
Test Suites and Tooling
- The dusts should work against the latest bosh-lite box.
- cloudfoundry-incubator/diego-release #135: 132 - Verify this repos isn’t a submodule before invoking install-git-hooks
Documentation
Cleanup
- cloudfoundry-incubator/cf_http #2: Common response generation methods were present throughout Diego.
BOSH job changes
None.
BOSH property changes
- Added
diego.rootfs_cflinuxfs2.trusted_certs: Bundle of certificates to install in the cflinuxfs2 rootfs default trust store (/etc/ssl/certs).
Usage¶
You can reference this release in your deployment manifest from the releases section:
- name: "diego" version: "0.1454.0" url: "https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1454.0" sha1: "4175435ff2e5c81494a0398f93c53807424edb0c"
Or upload it to your director with the upload-release command:
bosh upload-release --sha1 4175435ff2e5c81494a0398f93c53807424edb0c \ "https://bosh.io/d/github.com/cloudfoundry/diego-release?v=0.1454.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