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

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

On Thu, Sep 06, 2012 at 04:47:17PM +0100, Daniel P. Berrange wrote:
> 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
            ^why 3 /// here ? volname is not a path, but image is.

So when transport=socket or rdma, is it acceptable to still use the following
format ?

gluster://server[:port]/volname/path/to/image[?transport=...]

With that, the different options possible are

unix - gluster://testvol/dir/a.img?transport=unix&sockpath=/tmp/glusterd.socket
ipv4 - gluster://1.2.3.4:0/testvol/dir/a.img?transport=socket
ipv6 - gluster://[1:2:3:4:5:6:7:8]:0/testvol/a.img
hostname - gluster://example.org/testvol/dir/a.img
rdma - gluster://1.2.3.4:0/testvol/a.img?transport=rdma

Does this look complete from the specification point of view ?

Regards,
Bharata.