| 2015-04-30 21:54:46 |
Sean McGinnis |
bug |
|
|
added bug |
| 2015-04-30 21:55:14 |
Sean McGinnis |
bug |
|
|
added subscriber Tom Swanson |
| 2015-04-30 23:11:28 |
John Griffith |
cinder: status |
New |
Confirmed |
|
| 2015-05-01 15:49:20 |
Steve Currie |
bug |
|
|
added subscriber Steve Currie |
| 2015-05-05 16:02:52 |
Mike Perez |
cinder: importance |
Undecided |
High |
|
| 2015-05-05 16:03:04 |
Mike Perez |
cinder: milestone |
|
liberty-1 |
|
| 2015-05-05 23:52:23 |
John Griffith |
summary |
Retyping to new backend not renaming volume on array |
Retyping with migrate to new backend not renaming volume on backend device |
|
| 2015-05-05 23:56:24 |
John Griffith |
description |
When doing a retype volumes are being lost. Cinder calls in to the driver to have a new volume created an the second backend. It then copies the data over from the first backend to the new lun on the second backend. After the migration of the data completes the original lun on the first backend is deleted.
The problem with this is the new volume is given a new ID, but the cinder database keeps the original volume id. There is a missing step where cinder should instruct the driver to update the new volume's ID so that it matches the old deleted volume.
Subsequent calls in to the driver to manipulate the volume fail because cinder still has the old ID but the array only has the new ID. |
When doing a retype volumes are being lost. Cinder calls in to the driver to have a new volume created an the second backend. It then copies the data over from the first backend to the new lun on the second backend. After the migration of the data completes the original lun on the first backend is deleted.
The problem with this is the new volume is given a new ID, but the cinder database keeps the original volume id. There is a missing step where cinder should instruct the driver to update the new volume's ID so that it matches the old deleted volume.
Subsequent calls in to the driver to manipulate the volume fail because cinder still has the old ID but the array only has the new ID.
<jdg>
Just a little clarification:
The issue here is that some backend devices use the volume UUID from Cinder at create time to create their internal mapping. The migration process however does a UUID swap in the DB but doesn't actively send an update request or notification to the backend driver to tell it that it also needs to update its internal mapping information WRT the volume.
Suggestion is the addition of a general "update_volume_info" or something along those lines being setup up for drivers to be informed that they have to change something on the backend (ie: update_voume_info(notification=id_change, 'old_id: xxx, new_id: xxx')
maybe a generalized method like that is more trouble than it's worth, but I can see other places where a notification like this would be handy. |
|
| 2015-05-05 23:56:27 |
John Griffith |
cinder: status |
Confirmed |
Triaged |
|
| 2015-05-06 03:57:51 |
Vincent Hou |
cinder: assignee |
|
Vincent Hou (houshengbo) |
|
| 2015-05-07 05:57:26 |
OpenStack Infra |
cinder: status |
Triaged |
In Progress |
|
| 2015-05-07 18:38:03 |
Tom Barron |
bug |
|
|
added subscriber Tom Barron |
| 2015-06-05 05:52:02 |
Xi Yang |
bug |
|
|
added subscriber Xi Yang |
| 2015-06-23 14:08:13 |
Mike Perez |
cinder: milestone |
liberty-1 |
liberty-2 |
|
| 2015-07-01 22:16:33 |
OpenStack Infra |
cinder: assignee |
Vincent Hou (houshengbo) |
Peter Penchev (openstack-dev-s) |
|
| 2015-07-02 02:19:40 |
OpenStack Infra |
cinder: assignee |
Peter Penchev (openstack-dev-s) |
Vincent Hou (houshengbo) |
|
| 2015-07-14 05:23:35 |
Vincent Hou |
cinder: status |
In Progress |
Fix Committed |
|
| 2015-07-28 18:29:53 |
Doug Hellmann |
cinder: status |
Fix Committed |
Fix Released |
|
| 2015-10-15 11:45:12 |
Thierry Carrez |
cinder: milestone |
liberty-2 |
7.0.0 |
|
| 2015-11-11 09:06:03 |
Chen Kaihua |
bug |
|
|
added subscriber Chen Kaihua |
