7cc2e402f9
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 the NFS driver. This patch fixes this in the RemoteFSSnapDriverDistributed class which fixes the NFS driver and a handful of others. A follow up patch should be applied for the RemoteFSSnapDriver class with a similar change, but as 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: I64e041feaeb50c95808da46a34f334a9985018a8
13 lines
604 B
YAML
13 lines
604 B
YAML
---
|
|
fixes:
|
|
- |
|
|
An incorrect lock in the remotefs code, which is used for the NFS driver,
|
|
and other similar drivers, resulted in concurrent clone volume operations
|
|
failing. create_cloned_volume now locks on the source volume id, meaning
|
|
multiple clone operations from the same source volume are serialized.
|
|
|
|
A lock in the volume manager flow generally prevents this on normal clone
|
|
volume operations, but this clone method in the driver is called for
|
|
operations such as cloning from the cinder image-volume cache or cloning
|
|
from a cinder backend used as a glance store.
|