IMPORTANT

Communication between Cloud Controller and UAA now defaults to using the UAA internal URL and HTTPS. This requires UAA to be configured with a valid SSLCertificate and SSLPrivateKey, and a corresponding CACert in the case of a self-signed certificate. See the Job Spec Changes for more information.

CC API Version: 2.64.0 and 3.0.0-alpha.5

Service Broker API Version: 2.10

As a CF operator, I expect that the CC-Bridge services' debug servers listen only on localhost by default details

As an app developer, I expect staging tasks that run on Diego to allocate 4096 MB of disk instead of 6144 MB by default so that I am not consuming system resources unnecessarily details
As a CF operator, I would like my deploy to fail if buildpack blobstore is misconfigured details
As a CAPI client, I can remove a user from an org details
Creating a v2 app with a non-existent space causes an UnknownError details
Root of API should include links to UAA server. details
Root of api.some-cloud-foundry.com/v3 should include link to apps details
CC UAA interactions can be configured with a custom CA cert details
As an app developer, I would like VCAP_APPLICATION to have cf api endpoint details
Retrieving the roles of all Users in the Organization should be filterable by user guid details

Job Spec Changes

Valid properties.uaa.sslPrivateKey, properties.uaa.sslCertificate, and properties.uaa.ca_cert are now required for the CC to communicate with UAA via the internal HTTPS endpoint (normally to uaa.service.cf.internal). The script in cf-release can be used to generate a self-signed certificate, private key, and ca cert.
CC-Bridge services' debug servers listen only on localhost by default. These components are typically deployed with Diego and no change is required if using defaults. If not using defaults, we recommend changing these properties to 127.0.0.1 and an available port number: capi.cc_uploader.debug_addr, capi.nsync.listener_debug_addr, capi.nsync.bulker_debug_addr, capi.stager.debug_addr, and capi.tps.listener.debug_addr.
dea_next.staging_disk_limit_mb now defaults to 4096, down from 6144, although there was a long standing bug where Cloud Controller would ignore this configuration and always use 4096. We don't expect this to amount to any required change for operators. This property affects the staging disk limit for both DEA and Diego and can now be changed to an operators desired amount of disk for application staging.

Provide feedback