Question

How to use cloud-init to mount block storage that's already formatted and ready to mount?

I’m using Ubuntu 16.04 on a droplet using Terraform. I have an existing volume that’s already been formatted that I would like to mount to /home so I can persist my user directory between applications from terraform.

Unfortunately, while /etc/cloud/cloud.cfg lists mounts in it’s cloudinitmodules no entry is ever written to /etc/fstab.

The cloud-config docs are indeed less than ideal… I took some time to investigate this and discussed it with one of our engineers. It looks like due to changes in the version shipping with Ubuntu 16.04, the mounts module is not currently run on our platform requiring some changes in the vendor-data we provide.

I’ve found that automounting only happens when attaching a volume to a droplet that is already running. Start a droplet with its volumes already attached and they won’t get mounted. I filed a support ticket asking about this. This is disappointing because it causes two problems for me:

I must include mount entries in cloud-init. Changing cloud-init causes hosts to be recreated. This makes deployments take longer and ads more risk.

It’s a lot of extra code in my Terraform configs.

I’m starting to understand why people put up with the complexity of Kubernetes. If you try to deploy systems using infrastructure-as-code with plain Docker on VMs, you still have to deal with tons of complexity, it’s just different complexity. And there’s lots of brokenness.

Hi @jkirkham. Volumes should still be identified by the pattern /dev/disk/by-id/scsi-0DO_Volume_$VOLUME_NAME For instance, I was just able to successfully create a volume named “baz” that showed up as /dev/disk/by-id/scsi-0DO_Volume_baz Can you open a support ticket so the team can investigate?

Also, while this approach should still work, it’s worth pointed that we’ve actually made this even easier via our API since I wrote this answer. You can now ask for a pre-formatted volume that will be automatically mounted when attached by specifying a filesystem_type. For the details, check out:

@asb Thanks for the quick follow up.
I was surprised by this behaviour too. Previously I had it working in terraform by deploying a mount script and running it, but (it seems) when I switched to using templated cloud-configs from terraform the “by-id” volume name changed. I suspect it is some interaction between my cloud-config and the standard configs used to setup a new droplet. I prefer to continue to use terraform and templated cloud-configs for my solution so I will open a ticket.
Also, another factor is that the web UI or API auto-format and mount feature doesn’t seem to support custom mount points. Plus once created I will likely want to preserve the volume and remount it on updated droplets (in terraform that means a new droplet).
If I do find a solution I’ll post it here.
Thanks.

Ok, I think I’ve solve the issue. After reading the API docs again I noticed the volume name only permits alphanumeric characters plus the “-”. The example I encounter the problem with had an underscore (“_”) in the volume name. It appears this caused the volume “by-id” name to revert to the “sdb” device.
Thanks again. Hopefully this can be highlighted somewhere so others don’t run into the issue.