cloudfoundry/capi-release 1.30.0

CAPI 1.30.0

on GitHub

Important

• This release includes large, internal changes for handling staging. As a result, some staging tasks may fail during deployment when the cloud controller jobs are updating.
• DEA is no longer supported as a backend runtime.

Highlights

• Introduce a read permission for service brokers to query when displaying dashboards for service instances. Read here for more.
• Fixes some issues regarding tasks erroneously failing or being stuck in a RUNNING state.
• Introduce Builds resource in the V3 API to represent the staging process.

CC API Version: 2.84.0 and 3.19.0

Service Broker API Version: 2.11

CAPI Release

Cloud Controller

• API client can discover the network-policy api location details
• API client can observe STAGING_START and STAGING_STOP usage events based on builds details
• API client can see that LANG environment variable is set for tasks details
• API client should NOT receive errors when creating/deleting buildpacks concurrently details
• API client should NOT see any fields related to builds on droplet details
• API client should create droplet by POST /v3/builds instead of POST /v3/packages/:guid/droplets details
• API client should see fields nested under result move to the top level on droplet details
• API client should see that builds that do not finish staging are eventually marked failed details
• As a platform, I can send a context parameter to brokers when creating a service instance details
• Bit service can update package status and checksums details
• Bump nokogiri to >= 1.7.2 details
• CF users should need cloud_controller.read scope rather than cloud_controller.write to view isolation segment for org an space details
• Cloud Controller double-counts memory (and disk?) against quota when updating a task details
• Operator should observe that an interrupted sync job does not result in waiting 4 hours until bulking continues details
• Sync job should continue to update LRPs, tasks, and bump freshness even if a LRP Update returns a Error_InvalidRequest details
• API Client should NOT see 500 error when GET /v2/organizations/:guid/users has an error communicating with UAA details
• API client can discover from a build the user that created the resource details
• API client can observe build create and droplet create audit events at the correct points in the staging lifecycle details
• investigate route deduping issue for buildpack vs docker with legacy bridge details

Pull Requests and Issues

• cloudfoundry/cloud_controller_ng #792: Service instance permissions should distinguish between read and write details
• cloudfoundry/cloud_controller_ng #814: Organization Memory not properly calculated details