Skip to content

Releases: cloudfoundry/capi-release

CAPI 1.18.0

31 Jan 21:19
Compare
Choose a tag to compare

CC API Version: 2.72.0 and 3.7.0

Service Broker API Version: 2.11

CAPI Release

  • TPS: As an Operator, I would like communication between CC and Diego to always use Mututal TLS details
  • bump pcre dependency to 8.40 details
  • cloudfoundry/tps#10: Special characters in cc.basic_auth_password not being encoded correctly details

Cloud Controller

CAPI 1.17.0

28 Jan 01:18
Compare
Choose a tag to compare

The previous release added requirements for TLS properties in order to successfully deploy. This release updates the Cloud Controller spec files to enforce that the properties are in the manifest before the deploy begins.

CC API Version: 2.71.0 and 3.6.0

Service Broker API Version: 2.11

CAPI Release

Cloud Controller

  • /v2/route_mappings/not-exist returns 500 details
  • As an Operator, I must provide mutual TLS configuration details

CAPI 1.16.0

25 Jan 19:23
Compare
Choose a tag to compare

IMPORTANT

  • This release requires the Nginx for Cloud Controller to have valid SSL configuration as part of requiring all internal communication within Cloud Foundry to use Mutual TLS. The Diego BBS and Cloud Controller should use a common CA. For existing deployments, use the Diego CA to generate a key and cert using cloud-controller-ng.service.cf.internal as the CN. The Diego CA and Cloud Controller Cert and Key should be configured per the job spec changes below.
  • This release contains a fix for the bulk query used by HM9K for those using the DEA Runtime. We recommend scaling HM9K to 0 instances, deploying this CAPI-Release, then scaling HM9K back to original number of instances.
  • This release changes how we've included the fog gem dependency. Previously, we included the entire fog gem and all providers. This release only includes supported fog providers listed below. If there's a provider that you need that is missing, let us know and we'll happily add it back.
    • fog-azure-rm
    • fog-aws
    • fog-local
    • fog-openstack
    • fog-google

CC API Version: 2.70.0 and 3.5.0

Service Broker API Version: 2.11

CAPI Release

  • Bump to Ruby 2.3.3, Golang 1.7.4, Nginx 1.11.8 details

Cloud Controller

  • API Client can list apps in alphabetical order details
  • API client can specify an array of buildpacks for V3 App details
  • API client can specify an array of buildpacks for V3 Droplet details
  • Appears as though push and restage are using different memory calculations details
  • As a CF operator, I expect all app instances, app tasks, and staging tasks to have reasonable container-wide PID limits details
  • As an API user, I can List all Staging Security Groups for the Space details
  • As an app developer, I would like my app to emit logs with a "hostname" to my syslog drains details
  • BUILDPACK CACHE should use SHA-256 to ensure they have not been corrupted or tampered with details
  • BUILDPACKS should use SHA-256 to ensure they have not been corrupted or tampered with details
  • Expose app_domains property as a link details
  • Expose system_domain property as a link details
  • Operator does not observe increased error rate in New Relic due to HTTP 404 details
  • Operator does not observe increased error rate in New Relic due to expired tokens details
  • PACKAGES should use SHA-256 to ensure they have not been corrupted or tampered with details
  • Rate limiting blocks concurrent requests resulting in long request times for heavy users details
  • Recursive app deletion with app bound to services that fail to unbind should fail gracefully details
  • system_domain_organization should be defaulted to "system" details
  • deleting a security group or space that have a staging_security_group association fails details
  • explicitly require fog metagems in our gemfile instead of fog details
  • minimum staging memory is not configurable. details

Pull Requests and Issues

Job Spec Changes

  • Cloud Controller now requires SSL configuration with the following properties:
    • cc.mutual_tls.ca_cert: PEM-encoded CA certificate for secure, mutually authenticated TLS communication
    • cc.mutual_tls.public_cert: PEM-encoded certificate for secure, mutually authenticated TLS communication
    • cc.mutual_tls.private_key: PEM-encoded key for secure, mutually authenticated TLS communication

CAPI 1.15.0

09 Jan 21:38
Compare
Choose a tag to compare

IMPORTANT

  • The cloud_controller_clock can now be deployed in an HA configuration. For users of cf-release manifest generation, this will happen in an upcoming version of cf-release. For users customizing their deployment manifest, we now recommend running the cloud_controller_clock job in 2 availability zones. These jobs can be on their own VM or colocated with other jobs.

CC API Version: 2.69.0 and 3.4.0

Service Broker API Version: 2.11

CAPI Release

Cloud Controller

  • Cloud Controller has a TLS server on the Internal Consul DNS hostname details
  • Cloud Controller should set VCAP_APP_PORT environment variable to the same thing as PORT environment variable on Diego details
  • Scaling an app on Diego while it is staging results in an Unknown Error details
  • DROPLETS should use SHA-256 to ensure they have not been corrupted or tampered with details
  • Make cloud_controller_clock HA details

Pull Requests and Issues

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.
  • Added cc.diego_sync.frequency_in_seconds, the frequency with which we'll enqueue a job to ensure Diego is in sync. This synchronization is still experimental and is not used by default yet. Defaults to 30-seconds.

CAPI 1.14.0

20 Dec 00:05
Compare
Choose a tag to compare

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

CAPI 1.13.0

19 Dec 23:55
Compare
Choose a tag to compare
CAPI 1.13.0 Pre-release
Pre-release

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

15 Dec 22:06
Compare
Choose a tag to compare

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

Stager

Job Spec Changes

  • Removed properties.capi.stager.docker_registry_address

CAPI 1.11.0

07 Nov 23:21
Compare
Choose a tag to compare

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

CAPI 1.10.0

02 Nov 21:42
Compare
Choose a tag to compare

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

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

25 Oct 22:58
Compare
Choose a tag to compare
CAPI 1.9.0 Pre-release
Pre-release

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

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.