Migration of attached volumes does not delete old volume

Bug #1797181 reported by Tiago Pasqualini da Silva on 2018-10-10
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
High
Unassigned

Bug Description

When migrating an attached volume, after creating the new one, copying the data, attaching the new one, the old never gets deleted and stays 'available'.

The interesting part is that retype with migration of an attached volume works fine.

Steps to reproduce:
1) Create a volume
2) Attach it
3) Migrate it
4) New volume is created, data is copied and attachment is moved
5) Old volume should be deleted, but it stays as available

Tested it on Queens, Rocky and master (Stein), with LVM and NetApp drivers

description: updated
Eric Harney (eharney) on 2018-10-12
Changed in cinder:
importance: Undecided → High
Yikun Jiang (yikunkero) wrote :

It's the expected behavior of in-used volume migration, and there already was a "_migrate_volume_completion" [1] since [2], you need call it to complete the migrations. The tmp volume will be deleted.

BTW, I test this case in my env, this api is valid in V3.

curl -g -i -X POST http://XXX/volume/v3/4be2d7fa445d4faa94fd5c722b36417f/volumes/6d9a4e2c-8e37-471f-8418-10800989a49d/action -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-cinderclient" -H "X-Auth-Token: $TOKEN" -d '{"os-migrate_volume_completion": {"new_volume": "bf5edf8d-aa89-474d-80a7-cfd6d9d51aad"}}'

So, I think what we need to do is :
1. Add this migrate_volume_completion to api-ref
2. Improve the volume migration doc [3]
3. Add something like cinder migration-complete API to cinder client

[1] https://github.com/openstack/cinder/blob/558f7b0/cinder/api/contrib/admin_actions.py#L224
[2] https://review.openstack.org/#/c/41285/
[3] https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-migration.html

Yikun Jiang (yikunkero) wrote :

"The interesting part is that retype with migration of an attached volume works fine."

-----------

And it seems your retype operations didn't triggered the migration, so, no tmp vol left.

Yikun Jiang (yikunkero) wrote :

But I found a other unexptected

1. First attach a volume to a instance
2. Migrate the volume to ubuntubase@lvmdriver-1
3. Complete the migrate operation using os-migrate_volume_completion

The nova side volumes_attached is wrong....

See more in http://paste.openstack.org/show/733764/

Yikun Jiang (yikunkero) wrote :

Ignore #1, and it is the same bug mentioned in: https://bugs.launchpad.net/nova/+bug/1803961

The migrate_volume_completion should be called by nova.

Hey Yikun, I think migrate_volume_completion won't be called by nova because the Cinder manager never updates the volume status as "migrating.". It works when you attempt a retype because the manager updates the volume status as "retyping", thus calling the migrate_volume_completion module

Changed in cinder:
assignee: nobody → Aleksei Kazaev (kazaev-alex)
status: New → In Progress
Aleksei Kazaev (kazaev-alex) wrote :

Hi there. I tried to solve it by adding a missing status "migrating" (https://review.openstack.org/#/c/638995/). I think it's logical to have an additional status for migrating like it realized for retyping. After that, Nova has no problem to run Cinder's migrate_volume_completion callback. Fell free to review my bugfix.

Lee Yarwood (lyarwood) wrote :

https://bugs.launchpad.net/nova/+bug/1803961 is a duplicate of this and attempts to resolve the issue by using the migration_status of the volume within Nova.

I'm happy resolving this in Cinder API FWIW.

Note the above also includes Tempest test coverage for this bug so please feel free to reuse.

Changed in cinder:
assignee: Aleksei Kazaev (kazaev-alex) → Bangari Giri Varshini (bangari514)
tags: added: test-coverage
Changed in cinder:
assignee: Bangari Giri Varshini (bangari514) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers