cloudfoundry/capi-release 1.46.0

CAPI 1.46.0

on GitHub

Highlights

• Default to secure communication between Cloud Controller and Diego. See here for more details.
• Resolves thread leak with diego synchronization.
• Resolves issue causing periodic cleanup jobs to stop running.
• Introduce experimental support for named service bindings.

Job Spec Changes

• Removed cc.users_can_select_backend property. Diego is the only supported backend, so this property is no longer relevant.

Known Issues

• Tasks are sometimes canceled prematurely or marked as failed after completing successfully. Resolved in capi-release 1.47.0

CC API Version: 2.100.0 and 3.35.0

Service Broker API Version: 2.13

CAPI Release

• Add set -o pipefail to the bbr scripts along with set -e details
• As a CF operator, I expect the BBS eventually to exit when its backing Postgres database is unavailable details
• As a CF operator, if I configure the stager with a whitelist of insecure docker registries, I expect the docker app lifecycle builder to allow insecure communication with those registries (regression)4 details
• Operator sees that local bridge is used by default. details
• Potential drain failure on tps_watcher drain script details
• monit_stop_job shouldn't try to run if monit_unmonitor_job is still running in pre-backup-lock script details
• wait_unmonitor_job's regex is not strict enough details

Cloud Controller

• API client can filter service bindings by name details
• API client can observe binding name in VCAP_SERVICES environment variable details
• API client does not see running task for a task that completed but had its droplet deleted details
• API client gets actionable error message when starting an app without a droplet details
• API client observes a audit.app.restart audit event details
• API client with a role that allows service instance read can view dashboard url details
• As a CAPI developer, when I create an org or space with the V3 API, corresponding roles should be created in Perm details
• As an API client I can discover the /v3/service_instances resource details
• As an app dev (receiver), I can see information regarding service instances that have been shared with me details
• As an app dev (receiver), I can see minimal space information in the shared_from endpoint when a service instance has been shared with me details
• As an app dev (receiver), I can see sharing information regarding service instances that have been shared with me (shared_from) details
• As an app dev (receiver), I cannot delete a service instance that has been shared with me details
• As an app dev (receiver), I cannot rename a service instance to the same name of a service instance that has been shared with me details
• As an app dev (receiver), I cannot share a service instance that has been shared with me where I do not have access to the service instance details
• As an app dev (receiver), I cannot update a service instance that has been shared with me details
• As an app dev (receiver), I shouldn't be able to create a service instance with the same name as an instance that has been shared with me details
• As an app dev (sharer), I can see sharing information regarding service instances that I have shared (shared_to) details
• As an app dev (sharer), I can see the number of bindings made to service instances that I have shared details
• As an app dev (sharer), I cannot delete a service instance that I have shared which does not have bindings in another space details
• As an app dev (sharer), I cannot delete a service instance that I have shared which has bindings in another space details
• As an app dev (sharer), I cannot share service instances with myself details
• As an app dev (sharer), if I try to share a service instance into a space when the service has not specified shareable: true the share fails details
• As an app dev (sharer), if I try to share a service instance into a space where a service instance exists with the same name, the share fails details
• As an app dev, I cannot create a service key for a service instance that I do not have access to (i.e. has been shared with me) details
• As an app dev, I cannot list service keys for a service instance that I do not have access to (i.e. has been shared with me) details
• As an app dev, I can list non-shared service instances using the v3 API details
• As an app dev, I can list shared service instances using the v3 API details
• As an app dev, I cannot share a route service details
• As an app dev, I cannot share user provided services details
• As an app dev, I cannot view a specific service key or delete a service key for a service instance that I do not have access to (i.e. has been shared with me) details
• Cloud Controller has a feature flag to enable the querying of perm details
• Threads leak during errors in sync details

Pull Requests and Issues

• cloudfoundry/capi-release #66: some clock_jobs never run if last_completed_at < last_started_at value details
• cloudfoundry/cloud_controller_ng #942: users_can_select_backend defaults to true details
• cloudfoundry/cloud_controller_ng #971: API docs - "Update an Organization" should have example values details
• cloudfoundry/cloud_controller_ng #972: Implement bare-bones GET /v3/service_instances details