Cinder migrations should prefer efficient mechanisms

Registered by Robert Esker

Cinder migrations are presently (as of Havana) unaware of the means of migration, and should prefer more efficient means (e.g. copy offload) where possible.

Blueprint information

Status:
Complete
Approver:
bodo riediger
Priority:
Undefined
Drafter:
Robert Esker
Direction:
Needs approval
Assignee:
Ben Swartzlander
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

Caitlin Bestler: Why does this need to be visible? Wouldn't each volume driver select the best method of migration on its own?

<bswartz> I think there's confusion between scheduled and unscheduled migration. In Havana we only have unscheduled migration (i.e., the administrator picks the destination). In Icehouse we will have scheduled migrations such as when the user changes the volume type and the backend cannot support the new volume type -- at that point the scheduler will have to get involved to pick a new destination. The suggestion here is that the scheduler should be smart about choosing the destination, taking into account which backends it's more efficient to migrate to.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.