From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vKC-0004TK-Iw for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:58:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9vKB-00029x-GH for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:58:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9vKB-00029s-6I for qemu-devel@nongnu.org; Fri, 07 Sep 2012 05:58:07 -0400 Message-ID: <5049C526.20901@redhat.com> Date: Fri, 07 Sep 2012 11:57:58 +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> <20120907032123.GC20421@in.ibm.com> <5049C014.8010305@redhat.com> In-Reply-To: <5049C014.8010305@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Paolo Bonzini Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity , bharata@linux.vnet.ibm.com Am 07.09.2012 11:36, schrieb Paolo Bonzini: > Il 07/09/2012 05:24, Bharata B Rao ha scritto: >>> gluster:///volname/image?transport=unix&sockpath=/path/to/unix/sock >> ^why 3 /// here ? volname is not a path, but image is. > > Because the host is the local computer, i.e. empty. > >> 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 ? > > Hmm, why don't we do the exact same thing as libvirt (http://libvirt.org/remote.html): > > ipv4 - gluster+tcp://1.2.3.4:0/testvol/dir/a.img > ipv6 - gluster+tcp://[1:2:3:4:5:6:7:8]:0/testvol/a.img > host - gluster+tcp://example.org/testvol/dir/a.img > unix - gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket > rdma - gluster+rdma://1.2.3.4:0/testvol/a.img > > Where the default transport is tcp (i.e. gluster+tcp is the same as gluster). > This is easily extensible, theoretically you could have something like this: > > ssh - gluster+ssh://user@host/testvol/a.img?socket=/tmp/glusterd.socket I like this. Having the type only as a parameter when it decides how the schema must be parsed has bothered me from the start, but I hadn't thought of this way. Strong +1 from me. Kevin