CAPI 1.79.0
Highlights
- Added Sidecar support for processes
- Added Metadata for Service Instances
- Initial support for staging apps on Eirini
CC API Version: 2.134.0 and 3.69.0
Service Broker API Version: 2.14
CAPI Release
- [Feature Improvement] improve PDRATs reliability by improving the way autoscaling, usage-service and notifications block on CAPI availability in their BBR scripts details
- As a Platform Engineer, I should be able to easily automate downloading and validating the checksum of BBR details
- As a user, to make things simple, I expect to be able to
cf push
using only eirini (ie staging works) details - Consume url from cc_uploader link in OPI config and remove property from jobs that dont perform staging details
- Platform engineers should be able to perform selective backups against internal blobstores details
- Update tps-watcher and cc-uploader to work with bbs and locket versions that ship with diego-release v2.29.0 details
- cloudfoundry/capi-release #118: Enable selective backups for internal blobstore details
- cloudfoundry/capi-release #123: Introduce optional staging on OPI details
- cloudfoundry/capi-release #128: Add v2 logging endpoint to CAPI root details
- cloudfoundry/capi-release #132: Ensure that cc ng waits to populate routes - second try details
- cloudfoundry/capi-release #134: CAPI will need to set
cflinuxfs3
as the default stack before cf-deployment v8 release details - log-stream endpoint in CAPI's root path (aka /) details
Cloud Controller
- API client can create a domain on the v3 API details
- API client can create a resource match on the v3 API details
- API client can get details of a domain on the v3 API details
- API client can list domains on the v3 API details
- API client can create a domain scoped to an organization (private domain) on the v3 API details
- API client can specify a path and a mode when resource matching on the v3 API details
- API client can specify matched resources using the v3 format when uploading packages on the v3 API details
- API client should not need to upload a zip when uploading a package if resources are provided on the v3 API details
- API Client can DELETE
/v3/sidecars/:guid
details - API Client can GET
/v3/app/:guid/sidecars
details - API Client can GET
/v3/processes/:guid/sidecars
details - API Client can GET
/v3/sidecars/:guid
details - API Client can PATCH
/v3/sidecars/:guid
details - API Client can POST /v3/app/:guid/sidecars with process command & a list of process types details
- API User can generate a manifest with sidecars details
- API can rollback to a revision with a custom start command details
- API client add, modify, and remove metadata on a Service Instance details
- API client can observe the metadata section in docs examples for service instances details
- API client can query services instances with label_selector details
- Add and update app metadata via a server side manifest details
- Always set encryption_key_label for resources with encrypted columns details
- As a service author, I see instance_name, organization_name and space_name in the context object on a rename request from a customer using CF details
- As an operator, in order to make maintenance and debugging easier, I expect statefulset names to be named after the space and app name details
- Cache and reuse UAA client tokens when fetching usernames details
- Consume url from cc_uploader link in OPI config and remove property from jobs that dont perform staging details
- Explicitly set CURRENT_TIMESTAMP for created_at in web processes backfill migration details
- Getting instance information should fail with insufficient resources details
- Given a process with an associated sidecar resource, that sidecar runs in the same LRP container along with the process details
- Make sure bbs proto3 protobufs work with capi-release details
- Non web processes should have a default port details
- Pruning number of revisions details
- Server-side app manifests can apply changes to sidecars details
- Write the ADR talking about why factory_bot is harder than machinist details
application_id
environment variable should be the application guid details- log-stream endpoint in CAPI's root path (aka /) details
- v2 push fails with
UnknownError
when revisions are enabled for an app details
Cloud Controller Database Migrations
- 20190227175600_add_allow_context_updates_to_services.rb
- 20190319220026_create_sidecars.rb
- 20190320234126_create_service_instance_labels_table.rb
- 20190320234146_create_service_instance_annotations_table.rb
- 20190321214408_change_sidecar_process_type_name_to_type.rb
- 20190326212736_add_app_guid_to_sidecar_process_types.rb
Pull Requests and Issues
- cloudfoundry/cloud_controller_ng #1288: Enable OPI staging details
- cloudfoundry/cloud_controller_ng #1301: Add v2 logging endpoint to CAPI root details
- cloudfoundry/cloud_controller_ng #1308: POST /v3/apps/:app_guid/tasks does not ignore null values for the parameters details
- cloudfoundry/cloud_controller_ng #1309: Non original admins cannot update service instances details
- cloudfoundry/cloud_controller_ng #1315: Allow token-scope-based admins to update service parameters. details
- cloudfoundry/cloud_controller_ng #1316: Update opi apps client tests to reflect changes in eirini details