Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
View analytic
Friday, November 8 • 4:10pm - 4:50pm
Volume Import

Sign up or log in to save this to your schedule and see who's attending!

IBM have some internal implementation of Volume Import that we would like to push back to the community. However, there are some interesting issues around volume import that I think warrant discussion:

1. Some Cinder drivers rely on the name of the volume matching the OpenStack-internal 'name'. This means that a driver either has to rename the volume on import, or support a decoupling between the openstack-internal name and the backend volume name. We have prototyped the Storwize driver using the admin_metadata added for read-only volumes to do this decoupling.

2. Volume Types are used to guide the creation of the backend volumes. If a volume import operation were allowed to specify a volume type, should the drivers be checking that the backend volume is in some way "compliant" with the volume type? Any such check would likely be unreliable, since there may be more features on the backend storage provider than the driver supports, and the driver can't check that it doesn't know about.

3. Our implemented also added an API extension that could retrieve a list of backend volumes that were eligible for import. Is this considered a core feature, or something that could be optional?



(Session proposed by Geraint North)


Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 203

Attendees (43)