Skip to content
This repository

Revert "Merge pull request #353 from thansmann/cf-jobs-haproxy-fix"

This reverts commit 605c3f3, reversing
changes made to 98356a8.
latest commit c8f6723c94
James Myers jfmyers9 authored
Octocat-spinner-32 .final_builds add blobs for release v168 April 14, 2014
Octocat-spinner-32 config Update lucid64 stack to include up-to-date git version March 28, 2014
Octocat-spinner-32 git Merge branch 'master' into services-r11 by squash April 25, 2012
Octocat-spinner-32 jobs Revert "Collector to support clustered gnatsd" April 14, 2014
Octocat-spinner-32 packages Install buildpacks as part of deploy March 30, 2014
Octocat-spinner-32 releases Delete v167 release data April 14, 2014
Octocat-spinner-32 scripts remove unused blobs October 16, 2013
Octocat-spinner-32 shared @ a33125b Bump shared/ January 20, 2014
Octocat-spinner-32 src Revert "Collector to support clustered gnatsd" April 14, 2014
Octocat-spinner-32 templates Revert "Merge pull request #353 from thansmann/cf-jobs-haproxy-fix" April 15, 2014
Octocat-spinner-32 .gitattributes fix .gitattributes May 07, 2012
Octocat-spinner-32 .gitignore Remove outdated submodule `src/vcap-common/` with Gemfile for depende… February 03, 2014
Octocat-spinner-32 .gitmodules Install buildpacks as part of deploy March 30, 2014
Octocat-spinner-32 .ruby-version Update ruby package to 1.9.3-p484 November 26, 2013
Octocat-spinner-32 CONTRIBUTING.md Update contribution guidelines to indicate target branch for PRs February 20, 2014
Octocat-spinner-32 Gemfile Stop using .pre for bosh_cli, gems are final now. February 05, 2014
Octocat-spinner-32 LICENSE Upgrade Nginx to 1.4.5 [Finishes #61846156] February 24, 2014
Octocat-spinner-32 NOTICE Update NOTICE October 07, 2013
Octocat-spinner-32 README.md Change README to refer to develop as the development branch. March 03, 2014
Octocat-spinner-32 check_travis.rb Move scripts needed by mysql release into shared release repo September 27, 2013
Octocat-spinner-32 commit_with_shortlog Move scripts needed by mysql release into shared release repo September 27, 2013
Octocat-spinner-32 generate_deployment_manifest initial vsphere deployment infrastructure September 30, 2013
Octocat-spinner-32 outdated use travis everywhere August 15, 2013
Octocat-spinner-32 outdated_stats Count submodule commits since last pointer bump March 21, 2013
Octocat-spinner-32 staged_shortlog Move scripts needed by mysql release into shared release repo September 27, 2013
Octocat-spinner-32 update Simplify the `update` script. March 27, 2014
README.md

Welcome to Cloud Foundry

Cloud Foundry is an open platform as a service (PaaS), providing a choice of clouds, developer frameworks and application services. Cloud Foundry makes it faster and easier to build, test, deploy and scale applications.

This repository contains the Cloud Foundry source code.

Our documentation, currently a work in progress, is available here: http://cloudfoundry.github.com/

About Branches

The develop branch is where we do active development. Although we endeavor to keep the develop branch stable, we do not guarantee that any given commit will deploy cleanly.

If you want a stable branch, we recommend that you use the release-candidate branch.

Repository Contents

This repository is structures for use with BOSH, an open source tool for release engineering, deployment and lifecycle management of large scale distributed services. The directories are for two purposes:

Source:

  • jobs: start and stop commands for each of the jobs (processes) running on Cloud Foundry nodes.
  • packages: packaging instructions used by BOSH to build each of the dependencies.
  • src: the source code for the components in Cloud Foundry. Note that each of the components is a submodule with a pointer to a specific sha. So even if you do not use BOSH to deploy Cloud Foundry, the list of submodule pointers

Releases:

  • releases: yml files containing the references to blobs for each package in a given release; these are solved within .final_builds
  • .final_builds: references into the public blostore for final jobs & packages (each referenced by one or more releases)
  • config: URLs and access credentials to the bosh blobstore for storing final releases
  • git: Local git hooks

See the documentation for deploying Cloud Foundry for more information about using BOSH.

In order to deploy Cloud Foundry with BOSH, you will need to create a manifest. To do so, run ./generate_deployment_manifest <infrastructure-type>, where <infrastructure-type> is one of aws, vsphere, or warden. This script merges together several manifest stubs from the templates directory using the spiff tool, which must be installed beforehand. Consult the spiff repository or http://spiff.cfapps.io for more information on installing and using spiff. A complete sample manifest is also available in the Cloud Foundry documentation.

Cloud Foundry Components (V2)

The current development effort centers on V2, also known as NG. For information on what the core team is working on, please see our roadmap.

The components in a V2 deployment are:

Component Description Build Status
Cloud Controller (ccng) The primary entry point for Cloud Foundry. When you use vmc to push an application to Cloud Foundry, you target it against the Cloud Controller. Build Status
gorouter The central router that manages traffic to applications deployed on Cloud Foundry. Written in go, the v2 router represents a significant performance improvement over v1. Build Status
DEA (dea_next) The droplet execution agent (DEA) performs two key activities in Cloud Foundry: staging and hosting applications. Build Status
Health Manager The health manager monitors the state of the applications and ensures that started applications are indeed running, their versions and number of instances correct. Build Status
documentation in progress...more to come

Creating a release

Building a CF-Release later than 99be208f requires BOSH version 1.5.0 or later. The latest version of BOSH CLI can be found here: https://github.com/cloudfoundry/bosh/tree/master/bosh_cli

Useful scripts

  • ./update pulls cf-release and updates all submodules (recursively) to the correct commit. This is useful after:
    • You've first cloned the repo
    • Before you make changes to the directory, to avoid a rebase
  • ./update_sub takes an argument of the name of a submodule (partial matches okay), pulls that submodule to master, and stages that change in cf-release. Typically, only people developing Cloud Foundry should use update_sub. This script is useful after:
    • You've made changes to a submodule and you need those changes made available for deployment
  • ./commit_with_shortlog commits changes you've made using update_sub.

Ask Questions

Questions about the Cloud Foundry Open Source Project can be directed to our Google Groups.

File a bug

Bugs can be filed using Github Issues within the various repositories of the Cloud Foundry components.

Contributions

Please read the contributors' guide

Something went wrong with that request. Please try again.