Skip to content

CAPI 1.46.0
Compare
Choose a tag to compare
@capi-bot capi-bot released this 08 Dec 17:58
1.46.0
5534906

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
Assets 3
Loading