Scenario:
1. Setup OpenStack environment with VMAX storage.
2. Create volumes through cinder
3. Now the cinder database goes away. Examples:
(a) database becomes corrupt
(b) Want to insert these managed volumes into another openstack installation using a product built on openstack - without knowledge of the other openstack install (database was corrupt, or it got uninstalled etc.)
4. When we look at the volume CIM instances from the SMI-S provider, the ElementName property (or any other property) for that matter, does not contain the name that the openstack user originally used when creating the volume. So, on PowerVC (as an example built on openstack), the user does not know which volumes are theirs to import.
The PowerVC team met with the EMC openstack team (Xing, etc.) in September and this was one of the items we discussed. An objection that was brought up at that time was that the ElementName of the volume instance needed to be unique.
Given that restriction, PowerVC was able to easily solve name-persistence-gap by doing the following after the volume was created:
instance = self.common._find_lun(volume)
instance['ElementName'] = instance['DeviceID'] + '+' + volume['display_name']
<SMI-S connection wrapper class>.conn.ModifyInstance(instance)
Perhaps another product would care about volume['name'] instead of display_name, but we believe the general idea bears consideration by the community. Because it probably makes more sense to create the volume instance with that ElementName initially rather than do the ModifyInstnace() later. Today a generic name using ONLY the CIM 'DeviceID' property is used instead.
Yes, ElementName should have a unique name. Cinder volume UUID is the best candidate. 'display_name' can change very easily and doesn't persist at all. 'DeviceID' is already part of the volume object. Cinder volume UUID can help us find a volume on the array quickly too.