qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] block/gluster: add support for multiple glu


From: Daniel P. Berrange
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
User-agent: Mutt/1.5.23 (2014-03-12)

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 <address@hidden>
> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]