From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9p9f-0006NN-G0 for qemu-devel@nongnu.org; Thu, 06 Sep 2012 23:22:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9p9e-0007KE-EW for qemu-devel@nongnu.org; Thu, 06 Sep 2012 23:22:51 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:44459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9p9d-0007K6-Mz for qemu-devel@nongnu.org; Thu, 06 Sep 2012 23:22:50 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 7 Sep 2012 08:52:44 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q873M8Ht39387312 for ; Fri, 7 Sep 2012 08:52:09 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q873M8dD021905 for ; Fri, 7 Sep 2012 13:22:08 +1000 Date: Fri, 7 Sep 2012 08:54:02 +0530 From: Bharata B Rao Message-ID: <20120907032123.GC20421@in.ibm.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120906154717.GI3077@redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , Paolo Bonzini 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.