Skip to content
This repository
branch: master
Octocat-spinner-32 app Update error message during broker create/update April 17, 2014
Octocat-spinner-32 bin Merge pull request #156 from drnic/rm_document_api February 27, 2014
Octocat-spinner-32 bosh-templates Add the app_bits_upload_grace_period_in_seconds to BOSH config templates April 15, 2014
Octocat-spinner-32 config Remove deprecated bootstrap_admin_email property from config and temp… April 15, 2014
Octocat-spinner-32 db Add detected_buildpack_name to apps. April 08, 2014
Octocat-spinner-32 docs add a note about url encoding in the readme September 13, 2013
Octocat-spinner-32 lib Update error message during broker create/update April 17, 2014
Octocat-spinner-32 spec Fix the build April 17, 2014
Octocat-spinner-32 vendor Return meaningful errors when the UAA returns an error during April 08, 2014
Octocat-spinner-32 .gitignore Add buildpack information to app usage event. March 28, 2014
Octocat-spinner-32 .gitmodules Use https:// rather than git:// for submodules March 11, 2013
Octocat-spinner-32 .rspec Revert "Revert "Add transactional tests. Remove #reset_database. Add … October 22, 2013
Octocat-spinner-32 .rspec_parallel Log tests runtime to distribute test evenly December 19, 2013
Octocat-spinner-32 .rubocop.yml Ignore vendor directory during Rubocop run February 24, 2014
Octocat-spinner-32 .ruby-version Use the correct version of ruby December 12, 2013
Octocat-spinner-32 .travis.yml Add :rubocop rake task, run as a dependency of :spec task March 28, 2014
Octocat-spinner-32 Call out rubocop for static code analysis March 28, 2014
Octocat-spinner-32 Gemfile Change app bits upload controller to reauthorize with grace period April 15, 2014
Octocat-spinner-32 Gemfile.lock Change app bits upload controller to reauthorize with grace period April 15, 2014
Octocat-spinner-32 Guardfile drop version in Guardfile June 29, 2013
Octocat-spinner-32 LICENSE new license files August 28, 2013
Octocat-spinner-32 NOTICE new license files August 28, 2013
Octocat-spinner-32 Introduce default rake task March 31, 2014
Octocat-spinner-32 Rakefile Introduce default rake task March 31, 2014
Octocat-spinner-32 rubocop-todo.yml Remove unused exceptions, extract the rest to their files April 01, 2014

Build Status Code Climate


This repository contains the code for the Cloud Controller. The NG signifies that this is a "next generation" component and this is not backward-compatible with the original cloud_controller. This version adds significant new functionality including the additional mandatory "organization" and "space" hierarchy that all users, applications and services must use.


Cloud Controller

The Cloud Controller itself is written in Ruby and provides REST API endpoints for clients to access the system. The Cloud Controller maintains a database with tables for orgs, spaces, apps, services, service instances, user roles, and more.

Database (CC_DB)

The Cloud Controller database has been tested with Postgres, Mysql, and Sqlite.

Blob Store

The Cloud Controller manages a blob store for:

  • resources - files that are uploaded to the Cloud Controller with a unique SHA such that they can be reused without re-uploading the file

  • app packages - unstaged files that represent an application

  • droplets - the result of taking an app package and staging it (processesing a buildpack) and getting it ready to run

The blob store uses FOG such that it can use abstractions like Amazon S3 or an NFS-mounted file system for storage.

NATS Messaging

The Cloud Controller interacts with other core components of the Cloud Foundry platform using the NATS message bus. For example, it performs the following using NATS:

  • Instructs a DEA to stage an application (processes a buildpack for the app) to prepare it to run
  • Instructs a DEA to start or stop an application
  • Receives information from the Health Manager about applications


To maintain a consistent and effective approach to testing, please refer to spec/ and keep it up to date, documenting the purpose of the various types of tests.

By default rspec will run test suite with sqlite3 in-memory database; however, you can specify connection string via DB_CONNECTION environment variable to test against postgres and mysql. Examples:

DB_CONNECTION="postgres://postgres@localhost:5432" rspec
DB_CONNECTION="mysql2://root:password@localhost:3306/ccng" rspec

Travis currently runs 3 build jobs against sqlite, postgres, and mysql.

Running tests on a single file

The development team typically will run the specs to a single file as (e.g.)

bundle exec rspec spec/controllers/runtime/users_controller_spec.rb

Running all the tests

bundle exec rake spec

Due to the large number of tests, the rake spec task is configured to run in parallel using parallel_rspec.

Integration and acceptance tests, however, do not support concurrent testing (e.g. starting NATS on the same port at the same time), and are thus run serially.

Static Analysis

To help maintain code consistency, rubocop is used to enforce code conventions and best practices.

Running static analysis

bundle exec rubocop

Travis currently runs rubocop as part of the CI process.

API documentation

To genenerate the API documentation

bundle exec rspec spec/api/documentation --format RspecApiDocumentation::ApiFormatter
open doc/api/index.html


Cloud Controller uses Steno to manage its logs. Each log entry includes a "source" field to designate which module in the code the entry originates from. Some of the possible sources are '', 'cc.app_stager', 'cc.dea.client' and 'cc.healthmanager.client'.

Here are some use cases for the different log levels:

  • error - the CC received a malformed HTTP request, or a request for a non-existent droplet
  • warn - the CC failed to delete a droplet, CC received a request with an invalid auth token
  • info - CC received a token from UAA, CC received a NATS request
  • debug2 - CC created a service, updated a service
  • debug - CC syncs resource pool, CC uploaded a file

Database migration logs

The logs for database migrations are written to standard out.


The Cloud Controller uses a YAML configuration file. For an example, see config/cloud_controller.yml. Some of the keys that are read from this configuration file are:

  • logging - a steno configuration hash
  • bulk_api - basic auth credentials for the application state bulk API. In Cloud Foundry, this endpoint is used by the health manager to retrieve the expected state of every user application.
  • uaa - URL and credentials for connecting to the UAA, Cloud Foundry's OAuth 2.0 server.


Please read the contributors' guide

Something went wrong with that request. Please try again.