CAPI 1.14.0

IMPORTANT

• This CAPI Release has several new manifest properties that aren’t meant to be required yet. We’ve discovered an issue with BOSH directors before v257 where these properties must still be set. One of the following workarounds should be applied:
  • Upgrade your BOSH deployment to v257 or later or
  • Set the following properties to ”” in your CF Deployment manifest: cc.mutual_tls.ca_cert, cc.mutual_tls.public_cert, and cc.mutual_tls.private_key

CC API Version: 2.68.0 and 3.3.0

Service Broker API Version: 2.11

CAPI Release

Cloud Controller

• Make nginx tls config optional

CAPI 1.13.0

IMPORTANT

• This release accidentally required some work-in-progress manifest properties. Please use CAPI-Release 1.14.0 instead.

CC API Version: 2.67.0 and 3.2.0

Service Broker API Version: 2.11

CAPI Release

• As a CF Security Auditor, I would like components to receive sensitive configuration via config file for cc-uploader details

Cloud Controller

• The bbs can respond to staging callbacks directly to the cc with Mutual TLS details
• As an Operator, I would like to be able to stop an instance of a running app without the nsync-listener running details
• As an Operator, I would like to be able to stop a running app without the nsync-listener running details
• Local V3 Tasks should work with Isolation Segments details
• As an Operator, I would like to run V2 Apps and V3 Processes with out the nsync-listener running details
• Isolation segments should work after bridge consumption - Staging edition details

Pull Requests and Issues

• cloudfoundry/cf-release#1121: duplicated and missing organisations when querying /v2/organizations details

CC Uploader

NSYNC

Stager

TPS

Job Spec Changes

• cc.default_app_ssh_access: Defaults to true to preserve existing behavior where apps pushed to a space where SSH is enabled (and platform allows SSH) will have SSH enabled. Change to false so that apps will have SSH disabled, but can still be enabled on a per app basis.

CAPI 1.12.0

CC API Version: 2.66.0 and 3.1.0

Service Broker API Version: 2.11

CAPI Release

• As a CF Security Auditor, I would like components to receive sensitive configuration via config file for tps details
• As a CF Security Auditor, I would like components to receive sensitive configuration via config file for nsync details
• As a CF Security Auditor, I would like components to receive sensitive configuration via config file for stager details

Cloud Controller

• CAPI should support HTTP health check for applications details
• As an Auditor, I would like to discover when a user is added or removed from an Organization via audit events details
• As an Auditor, I would like to discover when a user is added or removed from an Space via audit events details
• As a Space User, I should be able to Associate Staging Security Group with the Space details
• As an API User, Security Groups should always show a url for staging spaces details
• NSYNC: As an Operator, I would like to be able to cancel V3 tasks without the nsync-listener running details
• As an app developer, I expect CC not to allow setting an environment variable with an empty name so that my app does not fail details
• Developers can stage apps using a disabled buildpack on Diego details
• NSYNC: As an Operator, I would like to be able to run V3 tasks without the nsync-listener running details
• As a Rails Developer, I would like tasks to set the DATABASE_URL environment variable details
• Isolation segments should work after bridge consumption - Staging edition details
• As an Auditor, I would like to be able to filter audit events by space_guid or org_guid details
• As a user, I can start an app in a space that is associated with an isolation-segment details
• As an Operator debugging an issue with a delayed job, it would be helpful to get stack traces in logs instead of in the database record details
• As an API user, I would like to be able to learn a username via GET /v2/users/:user-guid details
• As a CAPI developer, I can easily generate bbs protobuf ruby files details
• STAGER: As an Operator, I would like communication between CC and Diego to always use TLS details
• Updating an isolation segment name should be restricted. Just like assigning IS to spaces or Org Defaults details
• An org with apps in spaces without assigned ISes cannot have its default IS changed details

Pull Requests and Issues

• #39: remove properties.capi.stager.docker_registry_address details
• cloudfoundry/cloud_controller_ng#567: Plans should have control over whether they are bindable details
• cloudfoundry/cloud_controller_ng#695: Async Service Brokers can return unrestricted operation data in response body details
• cloudfoundry/cloud_controller_ng#698: Force http basic auth when talking to hm9k details
• cloudfoundry/cloud_controller_ng#701: add service_guid and service_url to service instance entity details
• cloudfoundry/cloud_controller_ng#704: API docs incorrect for v2 spaces details
• cloudfoundry/cloud_controller_ng#705: Missing input validation on security groups details
• cloudfoundry/cloud_controller_ng#708: Fix for rate limiting. nginx sublocations do not inherit all paramete… details
• cloudfoundry/cloud_controller_ng#712: Do not allow removal of default isolation segment if there are more details
• cloudfoundry/cloud_controller_ng#713: allow empty app_domains again details
• cloudfoundry/cloud_controller_ng#715: Generate events for role add/remove for spaces details
• cloudfoundry/cloud_controller_ng#719: Change how to present Isolation Segments from Orgs. details
• cloudfoundry/cloud_controller_ng#723: Isolation segments cleanup details
• cloudfoundry/cloud_controller_ng#725: Service plan bindable details
• cloudfoundry/cloud_controller_ng#737: Cloud controller crashes when primary mysql instance is shutdown details
• cloudfoundry/cloud_controller_ng#744: DB Password written to logs by runner.rb details

Stager

• cloudfoundry-attic/cloud-controller-stager#15: remove docker caching logic from docker backend details

Job Spec Changes

• Removed properties.capi.stager.docker_registry_address

CAPI 1.11.0

CC API Version: 2.65.0 and 3.0.0

Service Broker API Version: 2.10

CAPI Release

• Bumped to Golang 1.7

Cloud Controller

• As a Cloud Controller client, I would like to present a UAA token with cloud_controller.user scope to determine if the user has access to sensitive information and/or insensitive information about an application details
• Buildpacks should not be supplied to Diego if the blob doesn't exist details
• Cloud Controller should protect against a broker that doesn't return credentials details
• Add retry logic around FogBlob and DavBlob details
• Cloud controller should fail more gracefully when blobs are missing or the blobstore is misconfigured. details
• Add clearer documentation for seeding vs modifying/creating security groups details
• All V3 Resources have an updated_at timestamp upon creation instead of null details
• Admin read only cannot curl /v2/spaces/:guid details
• Read-only admin users get unknown error when getting v2 apps details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#699: Make service plans queryable by id provided by the service broker details
• #34: Cloud Controller ctl script should not restart directly the consul_agent details

CAPI 1.10.0

IMPORTANT

• An issue was discovered in CAPI 1.9.0 where the increased communication to UAA via internal URL and HTTPS exposed the Cloud Controller to a known segmentation fault in Ruby 2.3.1. This work has been reverted in CAPI 1.10.0.

CC API Version: 2.64.0 and 3.0.0-alpha.6

Service Broker API Version: 2.10

CAPI Release

Cloud Controller

• V3 Alpha
  • As an App Developer, I would like to be able to specify the disk limit for a V3 task details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#685: Isolation segments <-> Organizations details

Job Spec Changes

• Job Spec Changes from CAPI 1.9.0 related to UAA SSL can remain but will be ignored by the Cloud Controller in this release

CAPI 1.9.0

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

CAPI Release

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

Cloud Controller

• 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

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#672: Last operation API invoked with stale broker credentials details
• cloudfoundry/cloud_controller_ng#693: Always use the broker client details
• cloudfoundry/cloud_controller_ng#697: Fix CLA link 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.

CAPI 1.8.0

IMPORTANT

• This release fixes staging Python apps without a Procfile and apps using buildpacks that do not return a start command

CC API Version: 2.63.0 and 3.0.0-alpha.4

Service Broker API Version: 2.10

CAPI Release

Pull Requests and Issues

• #28: "cf disable-diego" for Docker app results in confusing error message [migrated from diego-release] details

Cloud Controller

• Staging fails for Python apps without Procfile even though a command has been specified via manifest details
• As an Operator, I would like files in my S3 blobstore to be encrypted at rest using SSE-KMS details
• Org Quota errors aren't bubbling up to API response details
• minimum_staging_disk_mb cannot be configured details
• Migrate stored mounts from 2.9 to 2.10 details
• Update DELETE /v2/routes/:guid to document what the recursive flag does details
• Validate Service Broker bind responses details
• Better error message for disk quota too much details
• V3 Alpha
  • V3 is capable of returning multiple errors details
  • Remove environment variables from V3 Tasks details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#684: Docs for service instance updating and deleting only show the HTTP status code for accepts_incomplete=true details

BBS

Buildpack App Lifecycle

CC Uploader

CF HTTP

Clock

Diego SSH

Docker App Lifecycle

Locket

NSYNC

Stager

TPS

Blobstore URL Signer

Dropsonde

NOAA

Sonde-Go

CAPI 1.7.0

IMPORTANT

• This release fixes a database migration that caused issues with certain app start commands.
• An issue was found staging Python buildpack based apps and apps using any buildpack that doesn't return process types in the staging result. We've prioritized this bug at the top of our backlog. Workaround is to add a Procfile containing any command, e.g. web: foo.

CC API Version: 2.63.0 and 3.0.0-alpha.3

Service Broker API Version: 2.10

CAPI Release

Cloud Controller

• BUGFIX: apps that have double quotes in the start command break after the v3 migration is applied details
• As an app developer, I should be able to upload a droplet for an app details
• CloudController sets v3 App guid on DesiredAppMessage details
• BUGFIX: v2 apps with environment variables starting with CF_ become invalid after deploying the v3 migration details
• As a space developer, I expect Cloud Foundry / Diego to gracefully handle my app being stopped or deleted while an app is staging. details
• Increase the width of the dashboard_url column in service instance table details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#668: No error thrown when route path exceeds 128 characters details

CAPI 1.6.0

IMPORTANT

• An issue was found in the migration below that can affect application start commands. This release should not be used, a fix is being worked on for CAPI 1.7.0.

CC API Version: 2.63.0

Service Broker API Version: 2.10

CCDB Migration for V3 API

This release includes a significant migration of the CCDB that is the first step to releasing the CC V3 API.

ALL EXPERIMENTAL V3 DATA WILL BE REMOVED WITH THIS MIGRATION

The migration will cause temporary API downtime as Cloud Controller jobs that have not been updated will not be able to use the migrated database schema. Users will not be able to use the CC API to push apps, update apps or get app information, but it will not affect apps currently deployed to Cloud Foundry.

User Impact

• Apps will continue to run normally.
• The Cloud Controller API will be unavailable or raise errors during the deploy meaning users will be unable to push apps, update existing apps or get app information.
• Crashing apps will not be restarted while the Cloud Controllers are being deployed.
• App logs will not be aggregated to syslog drains while the Cloud Controllers are being deployed if the deployment takes longer than the “properties.syslog_drain_binder.drain_url_ttl_seconds” manifest property. The default value for this property is 60 seconds.

Operator Procedure

Operators are not required to do anything differently for this deploy, but due to the size of the migration, operators may wish to take some additional steps to minimize user facing errors. See the Deployment Options below for information on steps an operator may take for this deployment.

1. Ensure there is a current CCDB backup prior to deploying.
2. Ensure there is adequate disk space available on the database server. This migration moves around significant amounts of data in the CCDB. The amount of disk space required will vary by RDBMS, it is recommended to err on the safe side.
3. Alert consumers of the API that there is a maintenance period, specifically any GUI client may want to display a maintenance page.
4. Consider temporarily increasing the value of “properties.syslog_drain_binder.drain_url_ttl_seconds” to prevent app logs failing to propagate to syslog drains during the deploy.
5. Select a deployment method from below and deploy.

Deployment Options

Deploy Normally

This is the simplest option. It should result in the shortest downtime period, but may be the most surprising to users as requests will appear to fail randomly as a result of a rolling deploy.

Procedure

1. Deploy the updated cf-release

Impact

• Users and clients will receive 500 errors from the API.
• Cloud Foundry components continue to attempt to access the database resulting in errors until the deploy is completed.

Scale API jobs to zero instances

This option prevents access to CCDB by Cloud Foundry components that do not know the updated schema. It also prevents clients from seeing seemingly random errors; they will only see unavailability errors.

Procedure

1. Prior to deploying the new cf-release, perform a manifest only deploy that scales down the following jobs
   • api_z(x)
   • api_worker_z(x)
   • clock_global
2. Deploy the updated cf-release with the original scale of the above jobs

Impact

• Cloud Foundry components will not attempt to access CCDB until they are able to complete requests.
• Users and clients will get 404 errors instead of 500 errors
• Requests will begin completing successfully when the first instances of the API server come up part way through the deploy
• VMs will need to be created during the deploy which may be slow in some environments

Stop the API jobs

This option prevents access to CCDB by Cloud Foundry components that do not know the updated schema. It also prevents clients from seeing seemingly random errors; they will only see unavailability errors.

Procedure

1. Prior to deploying the new cf-release, perform a bosh stop command on the following jobs.
   • api_z(x)
   • api_worker_z(x)
   • clock_global
2. Deploy the updated cf-release
3. Perform a bosh start command on the jobs that were previously stopped.

Impact

• Cloud Foundry components will not attempt to access CCDB until they are able to complete requests.
• Users and clients will get 404 errors instead of 500 errors
• API requests will not be served until the entire deploy has completed and the API servers have been started. This will create a larger maintenance window than the option to scale down instances.

Failing Deployment Procedure

In the event of a failing deployment related to this migration, operators will have to deploy the previously deployed version of CF Release and restore a CCDB backup. Other components using the database will need to be backed up and restored to roll back to a previously deployed CF release version.

Important Notes

• V3 Service Bindings should be deleted before deploy as the V3 Service Bindings will be deleted without calling out to the broker.
• V2 Apps keep an extra droplet when changing to the most recent droplet. The database record for this droplet will be removed during the migration. We intend to write a background clean up job to remove orphaned blobs from the blobstore in the near future.
• V2 Apps can no longer be moved between spaces.
• V2 Apps can no longer be changed from buildpack to docker and vice versa.
• V2 App usage events recently got "previous" entries for several fields. It is no longer possible to determine previous_package_state so this field has been deprecated.
• V2 Apps running on Diego will now be tagged APP/PROC/WEB/n (where n is the instance number) in application logs sent to syslog drains.
• V2 Apps that are staging during this deploy will likely fail without updating the app. The app should simply be restaged as it will be stuck in the PENDING package state.
• V2 Apps using environment variables beginning with CF_ will be in a bad state after the migration. We plan on releasing a quick follow to fix this.

Job Spec Changes

• pending_packages.expiration_in_seconds has been removed. pending packages will now be expired 5 minutes after the staging timeout.
• pending_packages.frequency_in_seconds has been renamed to pending_droplets.frequency_in_seconds.
• capi.tps.traffic_controller_url now defaults to the internal traffic controller url instead of being dynamically configured to reach the traffic controller through the gorouter. Feel free to remove this from whatever deployment contains TPS (normally Diego deployment). There is an upcoming story to do this automatically for those using the Diego manifest generation scripts.

CAPI Release

• Jobs in CAPI release should use internal URL for traffic controller details

stager

• As a BBS API client, I would like to observe that my LRP instances are not running or my Tasks have failed because there are no cells available matching those placement tags details

Cloud Controller

• CVE-2016-6658: As a CF operator, I expect buildpack urls to be stored and displayed with obfuscated credentials for Audit Events and App Usage Events. details
• CVE-2016-6658: As a CF operator, I expect buildpacks in droplet results to be obfuscated details
• service_plan_guid shouldn't be null in /v2/spaces/:space_guid/service_instances when service plan is private / inactive details
• As a CF operator, I expect to see the CC nginx access and error logs in my syslog data details
• Specifying a buildpack for an app can lead to not being able to GET /v2/apps details
• packages and droplets should be removed from the blobstore when they are expired details
• cc could return a better error when the blobstore is unavailable/misconfigured details
• V3 Alpha
  • V3 links should include protocol and host details
  • As an API user, I would like to list tasks by app with filter for sequence_id details
  • As an app developer, I want tasks for an app to be numbered sequentially details
  • Root of api.some-cloud-foundry.com/v3 should return JSON representation of all resources available in the V3 API. details
  • List tasks for an app optionally shows command and environment_variables details
  • Get a task optionally shows command and environment variables details
  • List tasks never shows command or environment variables details
  • As an app developer, I want tasks for an app to generate their ow...

CAPI 1.5.0

CC API Version: 2.62.0

Service Broker API Version: 2.10

NSYNC

• Revert: As a CF operator, I expect the CC-Bridge components to set nproc limits on RunActions for Diego LRPs and Tasks details

Stager

• Revert: As a CF operator, I expect the CC-Bridge components to set nproc limits on RunActions for Diego LRPs and Tasks details