On 02/25/2014 03:36 AM, Peter Krempa wrote:
The problem you are describing here is that two different keys may map to a single volume. The issue I'm trying to solve is that one key may map to two distinct volumes.
As a first step we should thus clarify which way the key should be unique.
If we want to make sure the mapping is always just 1:1, we might want to choose the gluster volume UUID as the first part of the key instead of the name.
That actually sounds like a reasonable idea - if we are trying to ensure that a key lookup will find exactly one volume across multiple pools, then encoding the pool UUID into the volume key name seems reasonable.
unique for some pools, but best effort for others, and not change what we have already been outputting. But if we DO keep this patch, you also need to change the documentation that gives examples of gluster keys.
This is still true - we'd need to document the choice, as well as mention that early implementations of gluster pools were buggy with regards to key generation. As it would be a bug fix, I think we can still try to get this done in time for 1.2.2. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org