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

[ronnie sahlberg]

On Fri, Sep 7, 2012 at 1:47 AM, Daniel P. Berrange <address@hidden> wrote:

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

+1

ronnie sahlberg