cowley-tech/content/blog/identify-and-mounting-cinder-volumes-in-openstack-heat/index.md

---
date: 2015-05-05
title: Identify and mounting Cinder Volumes in Openstack Heat
category: devops
---

I\'m back playing with Openstack again. The day job once again Openstack
based, and as of last week my lab is all Openstack too. While
[oVirt](http://ovirt.org) is awesome, I felt like a change.

Anyway, the meat of today\'s problem comes from the day job. I have some
instances deployed via heat that have multiple Cinder volumes attached
to them, these then need to be mounted in a certain way. The syntax for
attaching a cinder volume to an instance is:

    instance_vol_att:
        type: OS::Cinder::VolumeAttachment
        properties:
          instance_uuid:  { get_resource: instance }
          volume_id: { get_resource: instance_vol_data }
          mountpoint: /dev/vdb

See at the end there is `mountpoint`? Awesome, my device will always
appear as /dev/vdb!

No! Unfortunately, there is no link between Cinder/Nova and *udev*
within the instance. As a result, udev will simply assign it a device
name in the same way your workstation does to a USB key: it could be
anything.

So what is a poor Openstack admin to do?

Each volume has a UUID, which in the example above. Lets start with a
simple HOT template to create a single instance and volume:

    heat_template_version: 2014-10-16
    description: A simple server to run Jenkins

    parameters:
      imageid:
        type: string
        default: Centos-7-x64
        description: Image use to boot a server

    resources:
      jenkins:
        type: OS::Nova::Server
        properties:
          image: { get_param: ImageID }
          flavor: m1.tiny
          networks:
          - network: { get_param: NetID }
      jenkins_data:
        type: OS::Cinder::Volume
        properties:
          size: 50G
      jenkins_data_att:
        type: OS::Cinder::VolumeAttachment
        properties:
          instance_uuid: { get_resource: jenkins }
          volume_id: { get_resource: jenkins_data}

That will create everything we need. The rest we need to pass though
from Nova to the instance somehow. While Nova does not talk to udev, it
does pass the `volume_id` though, albeit with a caveat. the ID is
truncated to **20** characters and is available as
`/dev/disk/by-id/virtio-volid20chars`. We can now access this using the
userdata property and `cloud-init`.

I actually create a small bash script then run it later, so now my
*Server* resource will look like:

    jenkins:
      type: OS::Nova::Server
        properties:
          image: { get_param: ImageID }
          flavor: m1.tiny
          networks:
            - network: { get_param: NetID }
          user_data_format: RAW
          user_data:
            str_replace:
              template: |
                #cloud-config
                write_files:
                  - content: |
                      #!/bin/bash
                      voldata_id="%voldata_id%"
                      voldata_dev="/dev/disk/by-id/virtio-$(echo ${voldata_id} | cut -c -20)"
                      mkfs.ext4 ${voldata_dev}               
                      mkdir -pv /var/lib/jenkins
                      echo "${voldata_dev} /var/lib/jenkins ext4 defaults 1 2" >> /etc/fstab
                      mount /var/lib/jenkins
                    path: /tmp/format-disks
                    permissions: '0700'
                runcmd:
                  - /tmp/format-disks
              params:
                "%voldata_id%": { get_resource: jenkins_data }
    jenkins_data:
      type: OS::Cinder::Volume
      properties:
        size: 50
    jenkins_data_att:
      type: OS::Cinder::VolumeAttachment
      properties:
        instance_uuid: { get_resource: jenkins }
        volume_id: { get_resource: jenkins_data}

What is happenning here? I create 3 resources:

-   a server
-   a volume
-   a volume attachment

Within the server there is a *cloud-init* script passed in via
*user*data\_. This cloud-init script is created using a template which
has a single parameter. This parameter is `%voldata_id%` - I put `%`
symbols around all my variables in this context, it makes false matches
pretty much impossible. The `get_resource` command collects the ID of
the Cinder volume I created.

Now we move into the *cloud-init* script created which does 2 things:

-   creates a bash script, including the variable for the ID
-   launches that scripts

The Bash script calculates what the device will be (`$voldata_dev`),
formats it and mounts it at the mountpoint it creates. It also adds this
into `/etc/fstab` for the future.

This can easily be used for multiple volumes. All one does is add an
extra parameter to collect the extra resources, then extend the Bash
script to do them too.