All of lore.kernel.org
 help / color / mirror / Atom feed
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 :|

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.