The Cloud Controller in VMware Tanzu Application Service for VMs (TAS for VMs) provides REST API endpoints for clients to access the system. The Cloud Controller maintains a database with tables for orgs, spaces, services, user roles, and more.
The Cloud Controller uses the Diego Auction to balance application processes over the Diego Cells in a TAS for VMs installation.
The Cloud Controller database has been tested with MySQL.
To stage and run apps, TAS for VMs manages and stores the following types of binary large object (blob) files:
|Blob Type||Description||Location in Blobstore|
|App Packages||Full contents of app directories, including source code and resource files, zipped into single blob files.||
|Buildpacks||Buildpack directories, which Diego cells download to compile and stage apps with.||
|Resource Cache||Large files from app packages that the Cloud Controller stores with a SHA for later re-use. To save bandwidth, the TAS for VMs Command Line Interface (cf CLI) only uploads large application files that the Cloud Controller has not already stored in the resource cache.||
|Buildpack Cache||Large files that buildpacks generate during staging, stored for later re-use. This cache lets buildpacks run more quickly when staging apps that have been staged previously.||
|Droplets||Staged apps packaged with everything needed to run in a container.||
TAS for VMs blobstores use the Fog Ruby gem to store blobs in services like Amazon S3, WebDAV, or the NFS filesystem. The file system location of an internal blobstore is
A single blobstore typically stores all five types of blobs, but you can configure the Cloud Controller to use separate blobstores for each type.
After a blob deletion fails silently or something else goes wrong, the blobstore may contain blobs that the Cloud Controller no longer needs or lists in its database. These are called orphan blobs, and they waste blobstore capacity.
The Cloud Controller detects and removes orphan blobs by scanning part of the blobstore daily and checking for any blobs that its database does not account for. The process scans through the entire blobstore every week, and only removes blobs that show as orphans for three consecutive days.
The Cloud Controller performs this automatic cleanup when the
cloud_controller_worker job property
cc.perform_blob_cleanup is set to
The Cloud Controller does not track resource cache and buildpack cache blob types in its database, so it does not clean them up automatically as it does with app package, buildpack, and droplet type blobs.
To clean up the buildpack cache, admin users can run
cf curl -X DELETE /v2/blobstores/buildpack_cache. This empties the buildpack cache completely, which is a safe operation.
To clean up the resource cache, delete it as follows:
bosh sshto connect to the blobstore VM (NFS or WebDav) and
rm *the contents of the
Do not manually delete app package, buildpack, or droplet blobs from the blobstore. To free up resources from those locations, run
cf delete-buildpack for buildpacks or
cf delete for app packages and droplets.
rspec runs a test suite with the SQLite in-memory database. Specify a connection string using the
DB_CONNECTION environment variable to test against MySQL. For example: