[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend |
Date: |
Fri, 7 Sep 2012 11:03:40 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Sep 07, 2012 at 12:00:50PM +0200, Kevin Wolf wrote:
> 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.
The issue here is that the volume/path/to/image part is something that is
required for all gluster transports. The /path/to/unix/sock is something
that is only required for the unix transport. To have consistent URI
scheme across all transports, you really want the volume/path/to/image
bit to use the URI path component.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, (continued)
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Daniel P. Berrange, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, ronnie sahlberg, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Avi Kivity, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Bharata B Rao, 2012/09/06
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Daniel P. Berrange, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Kevin Wolf, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Bharata B Rao, 2012/09/12
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/12
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Kevin Wolf, 2012/09/07
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend,
Daniel P. Berrange <=
- Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend, Paolo Bonzini, 2012/09/07