gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] [libvirt] [RFC PATCH v1 1/2] Qemu/Gluster: Add Glust


From: Bharata B Rao
Subject: Re: [Gluster-devel] [libvirt] [RFC PATCH v1 1/2] Qemu/Gluster: Add Gluster protocol as supported network disk formats.
Date: Thu, 6 Sep 2012 20:54:01 +0530

On Wed, Sep 5, 2012 at 8:45 PM, Eric Blake <address@hidden> wrote:
> On 09/05/2012 09:08 AM, Bharata B Rao wrote:
>> On Wed, Sep 5, 2012 at 7:03 PM, Jiri Denemark <address@hidden> 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.



reply via email to

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