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 <rta...@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 :|
