Bug 1740560
Summary: | Cinder retype from non-type to new type on NFS deletes the Volume | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Johannes Beisiegel <j.beisiegel> | ||||
Component: | openstack-cinder | Assignee: | Alan Bishop <abishop> | ||||
Status: | CLOSED ERRATA | QA Contact: | Tzach Shefi <tshefi> | ||||
Severity: | urgent | Docs Contact: | Chuck Copello <ccopello> | ||||
Priority: | high | ||||||
Version: | 13.0 (Queens) | CC: | abishop, amcleod, ebarrera | ||||
Target Milestone: | z9 | Keywords: | Triaged, ZStream | ||||
Target Release: | 13.0 (Queens) | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | openstack-cinder-12.0.7-6.el7ost | Doc Type: | Bug Fix | ||||
Doc Text: |
Previously, the cinder NFS volume migration process renamed the volume file on the destination NFS server so that it matched the name on the source NFS server. This process then deletes the source volume, however, when you retype an NFS volume using migration, the source and destination might be the same. In this scenario, the NFS volume file was deleted if the source and destination back ends were on the same NFS server.
With this update, the volume file is renamed only when the source and destination files reside on different NFS servers, and retyping an NFS volume using migration functions correctly.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 1749491 1752560 (view as bug list) | Environment: | |||||
Last Closed: | 2019-11-07 13:59:50 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 1749491, 1749493 | ||||||
Bug Blocks: | 1752560 | ||||||
Attachments: |
|
Description
Johannes Beisiegel
2019-08-13 09:16:46 UTC
Sorry for the delay, we're taking a look at this now. I am not able to reproduce the problem (I running a newer version of cinder, but the remotefs driver hasn't changed significantly). Please reproduce the problem with debug logging enabled, and attach the cinder logs (especially the cinder-volume log). I need to see the logs during the time the volume is migrated to the Legacy backend. Created attachment 1606433 [details]
Cinder Volume Log (controller)
I was able to replicate the Issue on our Staging Environment with debug enabled. Volume ID is a6277876-c126-4fa8-a3b9-0d99a83c07b5 and the temporary Volume ID for the retype is 7f64ffe7-348f-4dd9-93f0-6be71910bc90. On the NFS Host I can observe the following: # ls -lh total 2 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:17 volume-a6277876-c126-4fa8-a3b9-0d99a83c07b5 # ls -lh total 4 -rw-r--r-- 1 root 42436 5.0G Aug 21 10:20 volume-7f64ffe7-348f-4dd9-93f0-6be71910bc90 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:17 volume-a6277876-c126-4fa8-a3b9-0d99a83c07b5 # ls -lh total 4 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:20 volume-7f64ffe7-348f-4dd9-93f0-6be71910bc90 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:17 volume-a6277876-c126-4fa8-a3b9-0d99a83c07b5 # ls -lh total 4 -rw-rw-rw- 1 root 42436 0B Aug 21 10:20 volume-7f64ffe7-348f-4dd9-93f0-6be71910bc90 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:17 volume-a6277876-c126-4fa8-a3b9-0d99a83c07b5 # ls -lh total 4 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:21 volume-7f64ffe7-348f-4dd9-93f0-6be71910bc90 -rw-rw-rw- 1 root 42436 5.0G Aug 21 10:17 volume-a6277876-c126-4fa8-a3b9-0d99a83c07b5 # ls -lh total 0 I am now able to reproduce the problem, and am investigating its cause. The fix has merged on master, and upstream backports are underway. Verified on: openstack-cinder-12.0.8-2.el7ost.noarch Create vol without a type "None": (overcloud) [stack@undercloud-0 ~]$ openstack volume create --size 1 test-vol01 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2019-10-22T06:57:50.000000 | | description | None | | encrypted | False | | id | a8be099e-3230-40d9-b7f1-608e387c1da4 | | migration_status | None | | multiattach | False | | name | test-vol01 | | properties | | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | type | None | ----> note type is "None" not set. | updated_at | None | | user_id | 74b333bafc2a45ab9d3e50710753f123 | +---------------------+--------------------------------------+ Below we see volume is one type "None" yet created on NFS as requested by this bug (overcloud) [stack@undercloud-0 ~]$ openstack volume show a8be099e-3230-40d9-b7f1-608e387c1da4 +--------------------------------+--------------------------------------+ | Field | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2019-10-22T06:57:50.000000 | | description | None | | encrypted | False | | id | a8be099e-3230-40d9-b7f1-608e387c1da4 | | migration_status | None | | multiattach | False | | name | test-vol01 | | os-vol-host-attr:host | controller-0@nfs#nfs | -> backend is NFS | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 739fb53130c14ca5a6ce887515341000 | | properties | | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available | | type | None | --> Type is "None" | updated_at | 2019-10-22T06:57:53.000000 | | user_id | 74b333bafc2a45ab9d3e50710753f123 | +--------------------------------+--------------------------------------+ Now lets create a Cinder vol type for NFS (overcloud) [stack@undercloud-0 ~]$ openstack volume type create nfs +-------------+--------------------------------------+ | Field | Value | +-------------+--------------------------------------+ | description | None | | id | 7db47c7f-f42d-4c1c-ab9d-e34229117207 | | is_public | True | | name | nfs | +-------------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ openstack volume type set nfs --property volume_backend_name=nfs (overcloud) [stack@undercloud-0 ~]$ openstack volume type list +--------------------------------------+------+-----------+ | ID | Name | Is Public | +--------------------------------------+------+-----------+ | 7db47c7f-f42d-4c1c-ab9d-e34229117207 | nfs | True | +--------------------------------------+------+-----------+ (overcloud) [stack@undercloud-0 ~]$ openstack volume type show nfs +--------------------+--------------------------------------+ | Field | Value | +--------------------+--------------------------------------+ | access_project_ids | None | | description | None | | id | 7db47c7f-f42d-4c1c-ab9d-e34229117207 | | is_public | True | | name | nfs | | properties | volume_backend_name='nfs' | | qos_specs_id | None | +--------------------+--------------------------------------+ Now that we have a volume with a "None" type on NFS we can try to migrate it same NFS type/backend. Before I do this here is the volume on the NFS server -> [root@cougar11 ins_cinder]# ll | grep a8be -rw-rw----. 1 root root 1073741824 אוק 22 09:57 volume-a8be099e-3230-40d9-b7f1-608e387c1da4 (overcloud) [stack@undercloud-0 ~]$ openstack volume set --retype-policy on-demand --type nfs test-vol01 (overcloud) [stack@undercloud-0 ~]$ openstack volume show test-vol01 +--------------------------------+--------------------------------------+ | Field | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2019-10-22T06:57:50.000000 | | description | None | | encrypted | False | | id | a8be099e-3230-40d9-b7f1-608e387c1da4 | ---> Same original ID | migration_status | success | | multiattach | False | | name | test-vol01 | | os-vol-host-attr:host | controller-0@nfs#nfs | ---> Volume remains on NFS backend | os-vol-mig-status-attr:migstat | success | --> migrated | os-vol-mig-status-attr:name_id | 868466f0-0ec2-4eb8-b379-1d30e0baa678 | --> new name/ID | os-vol-tenant-attr:tenant_id | 739fb53130c14ca5a6ce887515341000 | | properties | | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available | | type | nfs | ---> type changed from None to NFS | updated_at | 2019-10-22T07:10:49.000000 | | user_id | 74b333bafc2a45ab9d3e50710753f123 | +--------------------------------+--------------------------------------+ On NFS server side we now only have the new volume [root@cougar11 ins_cinder]# ll | grep 8684 -rw-rw----. 1 qemu qemu 1073741824 אוק 22 10:10 volume-868466f0-0ec2-4eb8-b379-1d30e0baa678 [root@cougar11 ins_cinder]# ll | grep a8be [root@cougar11 ins_cinder]# Successfully attach volume to an instance: (overcloud) [stack@undercloud-0 ~]$ nova volume-attach 08538769-3218-40d4-bab0-fc9169fe1eff a8be099e-3230-40d9-b7f1-608e387c1da4 auto /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:344: SubjectAltNameWarning: Certificate for 10.0.0.101 has no `sck for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow SubjectAltNameWarning /usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:344: SubjectAltNameWarning: Certificate for 10.0.0.101 has no `sck for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow SubjectAltNameWarning +----------+--------------------------------------+ | Property | Value | +----------+--------------------------------------+ | device | /dev/vdb | | id | a8be099e-3230-40d9-b7f1-608e387c1da4 | | serverId | 08538769-3218-40d4-bab0-fc9169fe1eff | | volumeId | a8be099e-3230-40d9-b7f1-608e387c1da4 | +----------+--------------------------------------+ Looks good to verify. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3800 *** Bug 1784020 has been marked as a duplicate of this bug. *** |