What’s new in BOSH — February Issue

A collection of things you already knew

As the PM of the Bosh OpenStack CPI I get to play around with Bosh a lot and have fun with its quirks and subtleties. The learning curve is quite interesting, as pointed out by smarter people before me, so I’d like to compile a few things that hopefully can make your life easier.

To paraphrase a favorite professor of mine

Bosh is a funky beast

So let’s have a look at things that might have been added recently to Bosh, or at least a recent discovery of mine. Everything below works with v250 of Bosh and the corresponding CLI v1.3184.1.0. If you’re on an older version, things may or may not work.

Compiled Releases

I’ve started to use compiled releases because I was sick of waiting for compilation of my releases. So once your release got compiled successfully, do

$ bosh export release test/1 ubuntu-trusty/3181

and you get a nice archive containing the compilation results and the sources of your release which you can upload as you normally would with a release. Notice how the command doesn’t contain a reference to the infrastructure? Indeed, you can compile that stuff on OpenStack on premise and later deploy on AWS.

So when updating your stemcell versions, how do you keep track of which versions are uploaded in a compiled state and which would need to be compiled?

$ bosh inspect release test/1
+---------------+------------------------------------------------+
| Package | Compiled For |
+---------------+------------------------------------------------+
| bad_package |(source) |
| dummy_package |(source) |
| |bosh-openstack-kvm-ubuntu-trusty-go_agent/3140 |
| |bosh-openstack-kvm-ubuntu-trusty-go_agent/3146.6|
+---------------+-------------+----------------------------------+

Showing you that you already have compiled versions for stemcells 3140 and 3146.1. Note that I removed other information from the table output, such as SHA1 and fingerprint.

Orphaned Disks

The director doesn’t delete your disks directly anymore to prevent accidental dataloss. However, that also means that you might have more disks in your IaaS than you would probably think, even if you delete your deployments. You can look at the orphaned disks with

$ bosh disks --orphaned

You can remove everything in your director with

$ bosh cleanup --all

or tune the automatic garbage collection of disks in your director deployment manifest by adjusting the director.disks properties, which is 5 days by default. So watch out if you run a CI which deploys releases in an environment where your quota is tight!

Did you know?

If you’re like me, you probably find yourself switching between several deployments a lot. You don’t need to change `bosh deployment <manifest>` before each and every command you do, just provide `-d <manifest>` as a global switch before your command

$ bosh -d manifests/redis.yml ssh redis_z1 0 "sudo cat /var/vcap/bosh/log/current" 

So the above command returns the agent logfiles on the redis_z1/0 instance without changing the deployment file.

Show your support

Clapping shows how much you appreciated Marco Völz’s story.