During Index 2018 in San Francisco, CA, IBM hosted a Cloud Foundry (CF) Day with multiple speakers from the community. This is a summary of one talk during that meeting. This post is co-authored with Dmitriy Kalinin, BOSH Product Manager, of Pivotal, Inc.

In what may have been the most succinct yet thorough presentation of BOSH’s latests features that I have seen, BOSH anchor and lead engineer Danny Berger presented four key recent and important features that are used to help better BOSH in general and simplify its use. The features are presented in turn with examples and also finished with how to help various actors in the BOSH ecosystem. Let’s take a look at each feature.

Deployment variables

First let’s look at the changes related to deployment variables. These can be of many types, but a great example are the passwords that need to be embedded into a BOSH manifest. Having such passwords in the clear poses a security threat. There was no easy way to replace and manage them securely. Now the manifest can use placeholder variables with a special syntax, e.g., password: ((password)), and at deployment time each variable can be replaced either by passing the variable value during BOSH CLI invocation or auto-generating them or fetching from CredHub. Passwords are one example usage but other variables are possible and even other parts of the manifest can also be parameterized, e.g., certificates and credentials. Danny highlighted the value of deployment variables for BOSH director operators, release authors, and deployment authors.

Cross-deployment links

Another feature created to help simplify managing variable information in the BOSH manifest are cross-deployment links. These are links exposed by one job and consumed by another. For example the network IP information from an ElasticSearch job to a consumer of that service. By simply naming what the job provides and referring to it in a consumes section for another job, the director will populate the right information and make sure the right jobs output and input are propagated and delivered correctly. These cross-deployment links (and any links for that matter) help environment operators isolate their settings for experimentations and make the release authors and deployment and environment operators’ jobs easier.


DNS was never a first class feature in BOSH. With BOSH DNS the BOSH team created a full-blown, highly distributed, flexible, and health checking DNS server that is shipped with BOSH and can be deployed as an add-on to existing environment. No longer do release authors have to refer to fixed IPs when creating their links. They can just consume DNS addresses and the machinery in BOSH DNS will take care of resolving the correct IPs.

BOSH manifest

Finally, while the BOSH manifest is a great source of truth for the deployment and resulting environment, for any decent size deployment of CF for instance, the resulting manifest is huge (even with the changes mentioned before) and can be hard to maintain. To fundamentally solve this issue the BOSH team has gone through a classic divide-and-conquer strategy to simplify the manifest into smaller chunks. A good example of this are named configs which allow operators to separate global director configuration in a more manageable way, e.g., having multiple runtime or cloud configs for each team. The BOSH CLI also supports these as first class objects. In many ways, named config is a generalization of the BOSH cloud-config which was introduced to extract and simplify cloud property management and specification in a BOSH manifest.

With these four new features, the BOSH team is showing their relentless goal to keep BOSH as a premier release engineering tool for cloud software. They are doing so by intently listening to their customers, innovating, and improving the overall BOSH toolset to address their in-the-field concerns.

Join The Discussion

Your email address will not be published. Required fields are marked *