Previously, the Block Storage service did not check first if it had the required permissions to write to a GlusterFS share before creating a snapshot. As a result, if the Block Storage service did not have write permissions to a GlusterFS share, any attempts to create a snapshot on the share would fail. No indication would be given to the user of why the attempt failed, and the volume/snapshot data could be left in an inconsistent state.
With this fix, the Block Storage service now checks if it has write permissions to a GlusterFS share before creating a snapshot. Any attempt to create a snapshot would fail with the correct notification (before any data is modified) if the Block Storage service does not have write permissions to the share.
I suspect we should be ensuring that the volume permissions are configured with something like this, which should ensure the cinder user can write in the directory.
# gluster volume set cinder-vol storage.owner-uid=165
# gluster volume set cinder-vol storage.owner-gid=165
I'm planning to add code to Cinder to detect when the share is not writable, so that snapshot operations will fail earlier, rather than putting the qcow2 files/metadata tracking into an inconsistent state.
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.
http://rhn.redhat.com/errata/RHEA-2013-1859.html