Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend

[Kevin Wolf <kwolf@redhat.com>]

Am 06.09.2012 17:47, schrieb Daniel P. Berrange:
> On Thu, Sep 06, 2012 at 09:10:04PM +0530, Bharata B Rao wrote:
>> On Thu, Sep 06, 2012 at 11:29:36AM +0300, Avi Kivity wrote:
>>> On 08/14/2012 12:58 PM, Kevin Wolf wrote:
>>>>
>>>>> While we are at this, let me bring out another issue. Gluster supports 3
>>>>> transport types:
>>>>>
>>>>> - socket in which case the server will be hostname, ipv4 or ipv4 address.
>>>>> - rdma in which case server will be interpreted similar to socket.
>>>>> - unix in which case server will be a path to unix domain socket and this
>>>>>   will look like any other filesystem path. (Eg. /tmp/glusterd.socket)
>>>>>
>>>>> I don't think we can fit 'unix' within the standard URI scheme (RFC 3986)
>>>>> easily, but I am planning to specify the 'unix' transport as below:
>>>>>
>>>>> gluster://[/path/to/unix/domain/socket]/volname/image?transport=unix
>>>>>
>>>>> i,e., I am asking the user to put the unix domain socket path within
>>>>> square brackets when transport type is unix.
>>>>>
>>>>> Do you think this is fine ?
>>>>
>>>> Never saw something like this before, but it does seem reasonable to me.
>>>> Excludes ] from the valid characters in the file name of the socket, but
>>>> that shouldn't be a problem in practice.
>>>
>>> Bikeshedding, but I prefer
>>>
>>>   gluster:///path/to/unix/domain/socket:/volname/image?transport=unix
>>
>> So if the unix domain socket is /tmp/glusterd.socket, then this would look like:
>>
>> gluster:///tmp/glusterd.socket:/volname/image?transport=unix.
>>
>> So you are saying : will the separator b/n the unix domain socket path
>> and rest of the URI components.
>>
>> Unless you or others strongly feel about this, I would like to go with
>> [ ] based spec, which I feel is less prone to errors like missing a colon
>> by mistake :)
>>
>>>
>>> as being more similar to file://, or even
>>>
>>>   gluster:///path/to/unix/domain/socket/volname/image?transport=unix
>>>
>>> with the last two components implied to be part of the payload, not the
>>> path.
>>
>> Note that image is a file path by itself like /dir1/a.img. So I guess it
>> becomes difficult to figure out where the unix domain socket path ends
>> and rest of the URI components begin w/o a separator in between.
> 
> IMHO this is all gross. URIs already have a well defined way to provide
> multiple parameters, dealing with escaping of special characters. ie query
> parameters. The whole benefit of using URI syntax is to let apps process
> the URIs using standard APIs. We should not be trying to define some extra
> magic encoding to let us stuff 2 separate parameters into the path component
> since that means apps have to now write custom parsing code again. Either
> the UNIX socket path, or the volume path should be in the URI path, not
> both. The other part should be a URI parameter. I'd really expect us to
> use:
> 
>   gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock

I think doing it the other way round would be more logical:

  gluster+unix:///path/to/unix/sock?image=volname/image

This way you have the socket first, which you also must open first.
Having it as a parameter without which you can't make sense of the path
feels a bit less than ideal.

Kevin