Better names for volume mount points
Problem/Opportunity Statement
The situation now:
- Imagine you have two volumes named
raw-data
andprocessed-data
- You attach both of the volumes to an instance
- Linux udev gives them device names
/dev/sdb
and/dev/sdc
respectively - systemd (as set up by Exosphere) mounts them as
/media/volume/sdb
and/media/volume/sdc
- You write code that reads from
raw-data
at/media/volume/sdb
, and writes toprocessed-data
at/media/volume/sdc
- You reboot the instance
- Now, udev has put the
processed-data
volume at/dev/sdb
, andraw-data
at/dev/sdc
, and the volumes are mounted at the opposite mount points as before - Your code breaks, you become sad and create a support ticket
When you first attach volumes, the device order is determined by the order of the attaching. But then when the instance is rebooted, udev might choose a different device order.
What would success / a fix look like?
Optimally, the volume name in Exosphere/OpenStack determines the name of the mount point. So, a volume named raw-data
ends up with a mount point like /media/volume/raw-data
. This was the unanimous choice among a poll of real users:
In order to implement this, we need to:
- prove a way to make the instance aware of volume names as they are attached
- (Nova exposes the volume UUID via hardware identifiers to the instance, but does not expose the volume name)
- Suggestion:
- Exosphere sets an instance metadata item containing a mapping of attached volume UUIDs to names
- on the instance side, the systemd service that mounts volumes looks up the metadata to determine the appropriate mount point
- perform automatic conversion of forbidden characters in the volume name to ones allowed in a mount point
- deal with the situation of someone mounting two volumes with the same name
- deal with the situation of someone renaming a volume while it is attached
- suggestion: don't let user rename a volume in Exosphere until it is detached
A fix for this would also fix #700 (closed).
Edited by Chris Martin