RemoteFSSnapDriver create_cloned_volume lock is wrong
Bug #1852449 reported by
Eric Harney
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
Undecided
|
Unassigned |
Bug Description
See similar bug 1851512 which fixes this for RemoteFSSnapDis
For non-distributed remotefs drivers, a fix is needed in the locking for create_
This currently only impacts the VZStorage driver.
To post a comment you must log in.
Reviewed: https:/ /review. opendev. org/693186 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=7cc2e402f95 371fa8d94295016 127eb3b716508f
Committed: https:/
Submitter: Zuul
Branch: master
commit 7cc2e402f95371f a8d94295016127e b3b716508f
Author: Eric Harney <email address hidden>
Date: Wed Nov 6 09:22:27 2019 -0500
Fix remotefs clone volume locking
Any method in the remotefs/nfs code that manipulates
the qcow2 snapshot chain must be run separately
from other methods that may touch this snapshot chain.
This code intended to do this with a lock on the
volume id, but it unintentionally locked only on
the destination volume id rather than the source
volume id where the snapshots are.
This causes concurrent clone operations to fail in pDriverDistribu ted class which fixes the
the NFS driver. This patch fixes this in the
RemoteFSSna
NFS driver and a handful of others.
A follow up patch should be applied for the pDriver class with a similar change, but as
RemoteFSSna
that class is only used by one driver (which I can't
test), this patch only adds a TODO for that change.
Related-Bug: #1840712
Related-Bug: #1852449
Closes-Bug: #1851512
Change-Id: I64e041feaeb50c 95808da46a34f33 4a9985018a8