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

[Deepak Shetty]

[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

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