From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vPs-00068z-6U for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:04:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9vPn-0003tm-Fc for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:04:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vPn-0003ta-6s for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:03:55 -0400 Date: Fri, 7 Sep 2012 11:03:40 +0100 From: "Daniel P. Berrange" Message-ID: <20120907100340.GC23416@redhat.com> References: <20120809130216.GC7960@in.ibm.com> <5028F815.40309@redhat.com> <20120814043801.GB24944@in.ibm.com> <502A0C66.3060107@redhat.com> <20120814093430.GE24944@in.ibm.com> <502A2140.9050703@redhat.com> <50485EF0.70505@redhat.com> <20120906154004.GB20421@in.ibm.com> <20120906154717.GI3077@redhat.com> <5049C5D2.2030408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5049C5D2.2030408@redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , Bharata B Rao , Paolo Bonzini 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 :|