[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 thanx, deepak > > then +1 from me on that. Is this idea of a simple URI followed by fields > which > are optional allowed in QEMU? > > If not, I prefer URI appended with options in > &backup-volfile-server=[tcp:|rdma:|unix:]server2[:port] format. > > Thanks, > Raghavendra Talur > > > > > >> >> The other problem with URIs is that it becomes hard to encode >> arbitrary data fields into them once you hit escaping. It becomes >> cumbersome for humans to construct these URIs. > > >> > This actually sounds like a lot more typing, and making qemu cmd line a >> lot >> > more lengthier :) >> >> If you are typing a list of volfile backup servers each time then it's >> already too long. Anyone doing this would either use libvirt or a >> shell script, so I'm not concerned about the length of the >> command-line in this use case. >> >> > Is -drive file=gluster://.... same as -drive driver=gluster, >> > uri[0]=gluster..... ? >> >> Yes, the code to make this possible is already in place today. Block >> drivers don't have to parse a single filename string, they can use a >> dictionary of options passed to them. >> >> > Also this would mean we need to change libvirt support for gluster based >> > network disk completely >> > and also maintain the old code for backward compat, right ? >> >> Yes, libvirt would need to emit the new syntax. The old syntax would >> continue to work. >> >> Stefan >> > >
