On Wed, Sep 5, 2012 at 8:45 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 09/05/2012 09:08 AM, Bharata B Rao wrote: >> On Wed, Sep 5, 2012 at 7:03 PM, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: >>>> @@ -1042,6 +1043,13 @@ >>>> <attribute name="port"> >>>> <ref name="unsignedInt"/> >>>> </attribute> >>>> + <attribute name="transport"> >>>> + <choice> >>>> + <value>socket</value> >>>> + <value>unix</value> >>>> + <value>rdma</value> >>> >>> This could be a bit confusing as socket is too generic, after all unix is also >>> a socket. Could we change the values "tcp", "unix", "rdma" or something >>> similar depending on what "socket" was supposed to mean? >> >> That is how gluster calls it and hence I am using the same in QEMU and >> the same is true here too. This is something for gluster developers to >> decide if they want to change socket to something more specific like >> tcp as you suggest. > > Just because gluster calls it a confusing name does not mean we have to > repeat the confusion in libvirt - it is feasible to have a mapping where > we name it 'tcp' in the XML but map that to 'socket' in the command line > that eventually reaches gluster. The question then becomes whether > using sensible naming in libvirt, but no longer directly mapped to > underlying gluster naming, will be the cause of its own set of headaches. Vijay - would really like to have your inputs here... - While the transport-type for a volume is shown as tcp in "gluster volume info", libgfapi forces me to use transport=socket to access the same volume from QEMU. So does "socket" mean "tcp" really ? If so, should I just switch over to using transport=tcp from QEMU ? If not, can you explain a bit about the difference b/n socket and tcp transport types ? - Also apart from socket (or tcp ?), rdma and unix, are there any other transport options that QEMU should care about ? - Are rdma and unix transport types operational at the moment ? If not, do you see them being used in gluster any time in the future ? The reason behind asking this is to check if we are spending effort in defining semantics in QEMU for a transport type that is never going to be used in gluster. Also I see that "gluster volume create" supports tcp and rdma but doesn't list unix as an option. Regards, Bharata.
