[libvirt] [for-1.2.3 PATCHv3] gluster: Fix "key" attribute for gluster volumes

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 and document the possible change to UUID. --- Notes: Version 3: - fix the example too, also state that UUID might be used - repost so we don't have yet another release containing this docs/storage.html.in | 8 +++++--- src/storage/storage_backend_gluster.c | 10 ++++++++-- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/docs/storage.html.in b/docs/storage.html.in index 2706bc5..4bbf378 100644 --- a/docs/storage.html.in +++ b/docs/storage.html.in @@ -711,12 +711,14 @@ 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> + the <code>key</code> is a string that identifies a single volume + uniquely. Currently the <code>key</code> attribute consists of the + URI of the volume but it may be changed to an UUID of the volume + in the future.</p> <pre> <volume> <name>myfile</name> - <key>volname/myfile</key> + <key>gluster://localhost/volname/myfile</key> <source> </source> <capacity unit='bytes'>53687091200</capacity> diff --git a/src/storage/storage_backend_gluster.c b/src/storage/storage_backend_gluster.c index fe92f15..337ddf4 100644 --- a/src/storage/storage_backend_gluster.c +++ b/src/storage/storage_backend_gluster.c @@ -187,6 +187,7 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state, const char *name) { int ret = -1; + char *path = NULL; char *tmp; VIR_FREE(vol->key); @@ -201,12 +202,12 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state, goto cleanup; } - if (virAsprintf(&vol->key, "%s%s%s", state->volname, state->dir, + if (virAsprintf(&path, "%s%s%s", state->volname, state->dir, vol->name) < 0) goto cleanup; tmp = state->uri->path; - if (virAsprintf(&state->uri->path, "/%s", vol->key) < 0) { + if (virAsprintf(&state->uri->path, "/%s", path) < 0) { state->uri->path = tmp; goto cleanup; } @@ -218,9 +219,14 @@ virStorageBackendGlusterSetMetadata(virStorageBackendGlusterStatePtr state, VIR_FREE(state->uri->path); state->uri->path = tmp; + /* the path is unique enough to serve as a volume key */ + if (VIR_STRDUP(vol->key, vol->target.path) < 0) + goto cleanup; + ret = 0; cleanup: + VIR_FREE(path); return ret; } -- 1.9.1

On 03/31/2014 06:18 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 and document the possible change to UUID. ---
+++ b/docs/storage.html.in @@ -711,12 +711,14 @@ 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> + the <code>key</code> is a string that identifies a single volume + uniquely. Currently the <code>key</code> attribute consists of the + URI of the volume but it may be changed to an UUID of the volume
s/an UUID/a UUID/ The rule on article selection with 'u' is determined by pronunciation: 'an umbrella' vs. 'a unicorn', based on whether the leading vowel has a hard 'you' sound vs. a soft 'uh' sound. In this case, the acronym is pronounced 'you-you-eye-dee'. (Similar for 'an hour' vs. 'a house' on whether an 'h' is pronounced). ACK with that fix, and I agree about getting it in for 1.2.3 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On 03/31/14 17:23, Eric Blake wrote:
On 03/31/2014 06:18 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 and document the possible change to UUID. ---
+++ b/docs/storage.html.in @@ -711,12 +711,14 @@ 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> + the <code>key</code> is a string that identifies a single volume + uniquely. Currently the <code>key</code> attribute consists of the + URI of the volume but it may be changed to an UUID of the volume
s/an UUID/a UUID/ The rule on article selection with 'u' is determined by pronunciation: 'an umbrella' vs. 'a unicorn', based on whether the leading vowel has a hard 'you' sound vs. a soft 'uh' sound. In this case, the acronym is pronounced 'you-you-eye-dee'. (Similar for 'an hour' vs. 'a house' on whether an 'h' is pronounced).
ACK with that fix, and I agree about getting it in for 1.2.3
Fixed and pushed; Thanks
participants (2)
-
Eric Blake
-
Peter Krempa