[libvirt] [PATCHv2 7/7] gluster: Fix "key" attribute for gluster volumes

[Eric Blake]

On 03/03/2014 09:05 AM, Peter Krempa wrote:
> According to our documentation the "key" value has the following
> meaning: "Providing an identifier for the volume which identifies a
> single volume." The currently used keys for gluster volumes consist of
> the gluster volume name and file path. This can't be considered unique
> as a different storage server can serve a volume with the same name.
> 
> Unfortunately I wasn't able to figure out a way to retrieve the gluster
> volume UUID which would avoid the possibility of having two distinct
> keys identifying a single volume.
> 
> Use the full URI as the key for the volume to avoid the more critical
> ambiguity problem.
> ---
>  src/storage/storage_backend_gluster.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)

Still incomplete: storage.html.in mentions:

    <h3>Example volume output</h3>
    <p>Libvirt storage volumes associated with a gluster pool
      correspond to the files that can be found when mounting the
      gluster volume.  The <code>name</code> is the path relative to
      the effective mount specified for the pool; and
      the <code>key</code> is a path including the gluster volume
      name and any subdirectory specified by the pool.</p>
    <pre>
       <volume>
         <name>myfile</name>
         <key>volname/myfile</key>

and needs to be updated.  I'm also still a bit worried whether existing
clients will be thrown off by a change in key between old and new
versions of libvirt, but gluster pools are still relatively new so
sooner rather than later is better if we are going to make the change.


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140304/5438e310/attachment-0001.sig>