cloudfoundry/diego-release v0.1454.0

Diego v0.1454.0

on GitHub

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

• Upgrade cflinuxfs2 rootfs in diego-release to 1.35.0+ 1.36.0+

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

• Document the Tasks API (public and internal) and Actions on the BBS (in flight)

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).