AWS::EC2::VolumeAttachment Device doesn't work

[Kevin Fox]

Due to this bug:
https://bugs.launchpad.net/nova/+bug/1004328

The Device listed is ignored by heat instanciated templates. At very least, a warning should be placed in the documentation that your drives may be attached in unexpected/unsafe orders.

[Steve Baker (steve-stevebaker)]

According to bug #1004328, this was fixed in Nova before the folsom release. We definitely do not support Heat running on Essex or earlier, so could you please provide more information on why you are hitting this bug?

[Kevin Fox (kevin-fox-y)]

Please review the bug #1004328 details. The bug thread says that its a libvirt/kvm issue that will be difficult to fix and they submitted a patch that makes the cinder id available in /dev/disks. It does not fix the /dev/vdX showing up as /dev/vdY issue though, which is what heat relies on.

Thanks,
Kevin

[Kevin Fox (kevin-fox-y)]

I'm using heat on RDO Grizzly. I'm trying to instantiate a template that has one vm and 4 volumes. The volumes where not getting attached to the devices as specified in the template file. They are getting /dev/vdb - /dev/vde instead of the specified /dev/vdh - /dev/hdk. And in a totally random order.

[Steve Baker (steve-stevebaker)]

The Description for VolumeAttachment currently says:
    The device where the volume is exposed on the instance

How about the following wording?
    The device where the volume is exposed on the instance. This assignment may not be honored and it is advised that the path /dev/disk/by-id/virtio-<VolumeId> be used instead.

Feel free to suggest an alternative wording.

Also, you might want to evaluate OS::Cinder::Volume and OS::Cinder::VolumeAttachment to see if it meets your needs better.

OS::Cinder::VolumeAttachment mountpoint is currently mandatory, but a bug could be raised to make it optional if its use should be discouraged.

[Kevin Fox (kevin-fox-y)]

That wording seems good to me. It would have prevented me from tripping over it and spending an hour trying to figure out what was going on.

Yeah, I could try the OS::Cinder::VolumeAttachment option too. I think its going to run into the exact same problem though.

If it is a source of confusion and it is just ignored by the system, maybe it should be optional and maybe even warn people when its used. In my case, I had no data yet relying on it, but it could have eaten production data if it went unnoticed.

Thanks,
Kevin

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/61324

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/61324
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=c1fae45fe729f065928b138b29c9caaa0be54ffa
Submitter: Jenkins
Branch: master

commit c1fae45fe729f065928b138b29c9caaa0be54ffa
Author: Angus Salkeld <email address hidden>
Date: Wed Dec 11 17:28:40 2013 +1100

    Make the mountpoint property description clearer

    There is an issue where the mountpoint may not be honored
    so add this note to the property documentation so users can be
    aware of the issue.

    Change-Id: Iddab9b1f6e5fadddd00e651e92b8b9c922a59347
    Closes-bug: #1231705