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

CAPI 1.4.0

IMPORTANT

• An issue was discovered in the nproc resource limit in Diego RunActions feature which has been reverted in CAPI 1.5.0. As CAPI 1.4.0 never appeared in a final cf-release, this should be a non-issue for those using CAPI release as distributed with cf-release.

CC API Version: 2.62.0

Service Broker API Version: 2.10

CAPI Release

Cloud Controller

• Cloud controller should support Google Cloud Storage details
• Seeding App Domains should support a Sub-domain of the system domain details
• Isolation Segments - Experimental
  • As an admin, I can remove the isolation segment associated with a space. details
  • As an admin, I can associate an isolation segment with a space details
  • As an admin, I can update an isolation segment details
  • As an admin, I can delete an isolation segment details
  • As an admin, I can view the isolation segments details
  • As an admin, I can create an isolation segment details

NSYNC

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

Stager

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

Pull Requests and Issues

• #27: PostgreSQL recommends updating to 9.4.9, capi-release libpq package uses 9.4.6 details

CAPI 1.3.0

CC API Version: 2.61.0

Service Broker API Version: 2.10

CAPI Release

• Update the Service Broker API to v2.10 Volume Services details
• Implement support for v2.10 service bindings in Diego details

Cloud Controller

• Update Rails and it's dependencies to latest 4.x details
• Update error message for invalid file mode to indicate minimum permissions required details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng#655: Doc: net_info in detailed stats is undocumented details
• cloudfoundry/cloud_controller_ng#656: Create Organization Quota Definition fails with unlimited routes and zero (default) total_reserved_route_ports details
• cloudfoundry/cloud_controller_ng#658: Pass ACL and encryption headers on copy. details

CAPI 1.2.0

CC API Version: 2.60.0

Service Broker API Version: 2.9

Cloud Controller

• Document recently added feature flags on CF docs details
• CVE-2016-6638: As a CF auditor, I expect credentials in buildpack urls to be obfuscated in /v2/events metadata details
• CVE-2016-6638: As a CF developer, I expect my git credentials in a buildpack URL to always be obfuscated for GET requests details
• CVE-2016-6638: As a CF operator, I expect buildpacks specified for apps to be encrypted at rest details
• Missing detected_buildpack_guid on /v2/apps/:guid/summary details
• As an operator, I would like to grant an API client global read scope for a Cloud Foundry deployment details
• Staging on DEA should report unavailable during drain/evac details

Pull Requests and Issues

• #24: nsync fails to update desired state in BBS silently details
• cloudfoundry/cloud_controller_ng#641: pre-start script fails more quickly than I think it needs to details
• cloudfoundry/cloud_controller_ng#646: app_ssh.host_key_fingerprint property should specify required format details

CAPI 1.1.0

CC API Version: 2.59.0

Service Broker API Version: 2.9

CAPI Release

• Upgrade Golang to 1.6.3 in capi-release / cf-release details

Cloud Controller

• V2 Creating a Docker App should not be marked experimental details
• The user facing error when the blobstore url signer is unavailable while pushing an app is not very helpful details
• CEF logs on vsphere, openstack, and possibly bosh-lite have src=127.0.0.1 details
• Can nginx_newrelic_plugin_ctl and logger run as vcap? details
• Documentation for SSE-S3 encryption at rest details
• Users can remove themselves from Orgs and Spaces details
• CC sets network.policy_group_id = app_guid on DesiredLRPs details

NSYNC

• As a Diego operator, I expect that the diego-sshd process command line does not contain credentials so that unauthorized actors on the Cell VM cannot enter the container via SSH details

Pull Requests and Issues

• cloudfoundry/cf-release#1001: Fail to deploy a CF v238 on single node details
• #19: CC, worker, and clock jobs require hm9000.port property even if using Diego backend details
• #20: Spec description for cc.default_quota_definition wrong details
• #25: blobstore job fails to start after vm crash or reboot details
• cloudfoundry/cloud_controller_ng#608: user_provided_service_instances returns 500 on empty name property details
• cloudfoundry/cloud_controller_ng#623: Contributor's guide does not mention need to have correct release of capi-release details
• cloudfoundry/cloud_controller_ng#624: blobstore excon connection hanging can bring cloudcontroller queue to a halt details

CAPI 1.0.0

Bump src/cloud_controller_ng

Bump src/cloud_controller_ng
  Amelia Downs:
     run nginx_plugin_ctl as vcap