What’s new in BOSH — March Issue

Is two already a series? Why not.

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.

This is the second post in a series. Find the first one here.

Everything below works with v255.3 of Bosh and the corresponding CLI v1.3202.0. If you’re on an older version, things may or may not work.

Backup/restore of the Director Database

For quite some time the Bosh CLI offered a command to backup your Director.

$ bosh backup
Acting as user ‘admin’ on ‘inner-bosh’
Director task 269
Started backing up director
Started backing up director > Backing up database. Done (00:00:01)
Task 269 done
Started 2016–03–01 13:03:37 UTC
Finished 2016–03–01 13:03:38 UTC
Duration 00:00:01
Backup of BOSH director was put in `/Users/vcap/deployments/bosh /bosh_backup_inner-bosh_1456837413.tgz’.

It creates a file containing unix timestamp in UTC, in this case 1456837413 means Tue, 01 Mar 2016 13:03:33 GMT. Note that this file is quite small, as it only is a snapshot of the database and does not contain the blobstore or anything else.

So now we have a backup, but what about restore? Be sure to use the same Director version where the backup was taken from!

$ bosh restore bosh_backup_inner-bosh_1456837413.tgz
You are going to restore the director’s database.

Now your database reports a bunch of releases

$ bosh releases
| Name | Versions | Commit Hash |
| dummy | 0+dev.2 | e1ffce69+ |

However, if you don’t have an external blobstore, you don’t have the blobs anymore. So go ahead and re-upload them with the `fix` parameter

$ bosh upload release <release name> --fix

And also re-upload your stemcells

$ bosh upload stemcell <stemcell name> --fix

And then you can deploy as usual.

If you’re like us and update your Director pretty aggressively, this now allows for rolling back the Director’s version. Simply downgrading doesn’t work most of the time, due to database migrations in the Director’s schema. With this process at hand, you can do a backup every time before an upgrade and simply roll back if it doesn’t work out!

At some point in time, a script might come in handy, which automates all the re-uploading, so you don’t have to think when things go belly-up.

Did you know?

You can use URLs in the `releases` and `stemcells` sections of your manifest:

- name: bosh-openstack-cpi
url: https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-openstack-cpi-release?v=23
sha1: 94fc3b5f72fec737c5ccba223dc5622d8eca4b5d
version: 23
name: bosh-openstack-kvm-ubuntu-trusty-go_agent
version: 3202
url: https://bosh.io/d/stemcells/bosh-openstack-kvm-ubuntu-trusty-go_agent?v=3202
sha1: f3b0ed251700048c14c722cd995eb7d27e743fe9

And you’ll see something like this before the usual manifest diff and deploy:

Checking whether release bosh-openstack-cpi/ already exists…NO
Using remote release `https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-openstack-cpi-release?v=23'

Using remote stemcell `https://bosh.io/d/stemcells/bosh-openstack-kvm-ubuntu-trusty-go_agent?v=3202'

No need to manually `bosh upload release <url>` or `bosh upload stemcell <url>` before deploying!

Show your support

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