From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vNN-0005MJ-0p for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:01:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9vNG-0003Vv-VZ for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:01:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vNG-0003Vk-N3 for qemu-devel@nongnu.org; Fri, 07 Sep 2012 06:01:18 -0400 Message-ID: <5049C5D2.2030408@redhat.com> Date: Fri, 07 Sep 2012 12:00:50 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20120809130010.GA7960@in.ibm.com> <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> In-Reply-To: <20120906154717.GI3077@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , Bharata B Rao , Paolo Bonzini 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