From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9ujT-0002ua-U7 for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:20:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9ujO-0006aW-AF for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:20:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9ujO-0006YG-2B for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:20:06 -0400 Date: Fri, 7 Sep 2012 10:19:35 +0100 From: "Daniel P. Berrange" Message-ID: <20120907091935.GA23416@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> <20120907032123.GC20421@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120907032123.GC20421@in.ibm.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: Bharata B Rao Cc: Kevin Wolf , Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , Paolo Bonzini On Fri, Sep 07, 2012 at 08:54:02AM +0530, Bharata B Rao wrote: > 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. The first 2 '/' are the protocol/hostname separator and the 3rd / is the hostname/path separator. Since there is no hostname in this example, you get /// > So when transport=socket or rdma, is it acceptable to still use the following > format ? > > gluster://server[:port]/volname/path/to/image[?transport=...] Of course. > 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 I assume you intend 'transport=socket' to be optional here > 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 ? Yes, this looks like a reasonable use of URIs. 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 :|