From: "Daniel P. Berrange" <berrange@redhat.com>
To: Deepak Shetty <dpkshetty@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Prasanna Kumar Kalever <prasanna.kalever@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
Deepak C Shetty <deepakcs@redhat.com>,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
Raghavendra Talur <rtalur@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers
Date: Thu, 10 Sep 2015 10:30:43 +0100 [thread overview]
Message-ID: <20150910093043.GF11366@redhat.com> (raw)
In-Reply-To: <CAOXiiM=zmmiiE8xr3Z6Kze=zvHWWjYiF9Mha+b9B0=jXqKXc1Q@mail.gmail.com>
On Thu, Sep 10, 2015 at 11:12:46AM +0530, Deepak Shetty wrote:
> [snip]
>
> On Wed, Sep 9, 2015 at 10:37 PM, Raghavendra Talur <rtalur@redhat.com>
> wrote:
>
> >
> >
> > From QEMU's perspective, it would be better to use separate fields
> >
> >> (that have type information) than to encode everything in an opaque
> >> URI string. Fields can do input validation in common code so that
> >> block drivers don't need to check whether something is a valid number,
> >> for example. Fields can also be listed and their type information can
> >> be displayed so the user knows the expected range of inputs
> >> (self-documenting).
> >>
> >
> > Coming from Gluster side of things, the variable/option here is tuple of
> > three
> > transport-type
> > server
> > port
> >
> > volname and file name should be the same in all the URIs. Just pointing
> > out here so that implementation can ensure that all URIs have the same
> > volname and filename;
> > which are testvol and a.img in the above example.
> >
> > By fields if you mean something like
> > -drive
> > file=gluster[+transport]://[server[:port]]/volname/image[?socket=...],\
> > file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port],
> > file.backup-volfile-server=[tcp:|rdma:|unix:]server2[:port]
> >
>
> Raghavendra,
> Thanks for pitching in.
>
> So are you saying that its possible to have different transport types (tcp,
> rdma etc)
> for different gluster server nodes, all of which are part of the same
> cluster ?
>
> If that is true then in the above suggestion of yours, gluster
> [+transport]://
> doesn't make sense, since it gives a feeling that the transport mentioned
> before :// applies to whole URI, only to be overridden by the later
> file.backup-volfile-server= option
>
> Maybe then as kwolf mentioned in prev thread of this mail ...
>
> -drive driver=gluster,uri[0]=gluster[+transport-type]://server1:24007/testvol/a.img,
>
> uri[1]=gluster[+transport-type]://server2:24008/testvol/a.img,
>
> uri[2]=gluster[+transport-type]://server3:24009/testvol/a.img
>
> seems like a better way of representing things, as then we can
>
> change transport:server:port for each server
Yep, if you want to be able to control transport, server & port for
each, then that really suggests using a single URI is no longer
appropriate. So I'd concur, that something like Kevin's / Stefan's
suggestions are better bets. This example you give above looks fine
for example.
Regards,
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 :|
next prev parent reply other threads:[~2015-09-10 9:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 13:04 [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple gluster backup volfile servers Prasanna Kumar Kalever
2015-09-08 14:43 ` Peter Krempa
2015-09-08 15:02 ` Daniel P. Berrange
2015-09-08 15:10 ` Deepak Shetty
2015-09-09 6:06 ` Deepak C Shetty
2015-09-09 9:46 ` Stefan Hajnoczi
2015-09-09 10:19 ` Deepak C Shetty
2015-09-09 12:29 ` Stefan Hajnoczi
2015-09-09 17:07 ` Raghavendra Talur
2015-09-10 5:42 ` Deepak Shetty
2015-09-10 9:30 ` Daniel P. Berrange [this message]
2015-09-10 11:47 ` Kevin Wolf
2015-09-09 10:33 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150910093043.GF11366@redhat.com \
--to=berrange@redhat.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=deepakcs@redhat.com \
--cc=dpkshetty@gmail.com \
--cc=kwolf@redhat.com \
--cc=prasanna.kalever@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rtalur@redhat.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).