From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRgGv-0000Gp-8i for qemu-devel@nongnu.org; Fri, 05 Feb 2016 08:18:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRgGq-0002IQ-9f for qemu-devel@nongnu.org; Fri, 05 Feb 2016 08:18:01 -0500 Received: from mx4-phx2.redhat.com ([209.132.183.25]:54824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRgGq-0002IC-2J for qemu-devel@nongnu.org; Fri, 05 Feb 2016 08:17:56 -0500 Date: Fri, 5 Feb 2016 08:17:50 -0500 (EST) From: Prasanna Kumar Kalever Message-ID: <804322261.32795856.1454678270665.JavaMail.zimbra@redhat.com> In-Reply-To: <20160204132215.GD2314@noname> References: <1447323728-2427-1-git-send-email-prasanna.kalever@redhat.com> <1447323728-2427-5-git-send-email-prasanna.kalever@redhat.com> <56451461.4060608@redhat.com> <20160204132215.GD2314@noname> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] block/gluster: add support for multiple gluster servers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pkrempa@redhat.com, stefanha@gmail.com, jcody@redhat.com, qemu-devel@nongnu.org, deepakcs@redhat.com, bharata@linux.vnet.ibm.com, rtalur@redhat.com, ndevos@redhat.com On Thursday, February 4, 2016 6:52:15 PM Kevin Wolf Wrote: > Am 12.11.2015 um 23:36 hat Eric Blake geschrieben: > > On 11/12/2015 03:22 AM, Prasanna Kumar Kalever wrote: > > > +static struct glfs *qemu_gluster_init(BlockdevOptionsGluster **gconf, > > > + const char *filename, > > > + QDict *options, Error **errp) > > > +{ > > > + int ret; > > > + > > > + if (filename) { > > > + ret = qemu_gluster_parseuri(gconf, filename); > > > + if (ret < 0) { > > > + error_setg(errp, "Usage: > > > file=gluster[+transport]://[host[:port]]/" > > > + "volume/path[?socket=...]"); > > > > Hmm, just noticing this now, even though this error message is just code > > motion. It looks like the optional [?socket=...] part of a URI is only > > important when using gluster+unix (is it silently ignored otherwise?). > > And if it is used, you are then assigning it to the host field? > > > > I almost wonder if GlusterServer should be a discriminated union. That > > is, in qapi-pseudocode (won't actually compile yet, because it depends > > on features that I have queued for 2.6): > > > > { 'union':'GlusterServer', 'base':{'transport':'GlusterTransport'}, > > 'discriminator':'transport', 'data':{ > > 'tcp':{'host':'str', '*port':'uint16'}, > > 'unix':{'socket':'str'}, > > 'rdma':{...} } } > > > > Hmm. Qapi doesn't (yet) allow for an optional discriminator (where the > > omission of the discriminator picks a default branch) - another RFE for > > my qapi work for 2.6. > > Eric, Prasanna, is this QAPI extension what we're waiting for or what is > the status of this series? Niels (CCed) was hacking on the same thing, > so maybe it's time to get this moving again. Kevin, correct me if I am wrong, union discriminator support is not yet added into qemu, I am waiting for this. I spoke to Eric Blake regarding the same may be a month ago from now. -Prasanna > > Kevin > > > Command-line wise, this would mean you could do in JSON: > > > > 'servers':[{'transport':'tcp', 'host':'foo'}, > > {'transport':'unix', 'socket':'/path/to/bar'}, > > {'host':'blah'}] > > > > where the third entry defaults to transport tcp. > > > > If we think that description is better than what we proposed in 3/4, > > then it's really late to be adding it now, especially since (without > > qapi changes) we'd have a mandatory rather than optional 'transport'; > > but worse if we commit to the interface of 3/4 and don't get the > > conversion made in time to the nicer interface. At least it's okay from > > back-compat perspective to make a mandatory field become optional in > > later releases. > > > > If it were just gluster code I was worried about, then I could live with > > the interface proposal. But since seeing this error message is making > > me double-guess the interface correctness, and that will have an impact > > on libvirt, I'm starting to have doubts on what it means for qemu 2.5. > >