Re: [Qemu-devel] [PATCH v19 3/5] block/gluster: remove rdma transport

[Markus Armbruster <armbru@redhat.com>]

Raghavendra Talur <rtalur@redhat.com> writes:

> On Mon, Jul 18, 2016 at 5:48 PM, Markus Armbruster <armbru@redhat.com>
> wrote:
>
>> Prasanna Kalever <pkalever@redhat.com> writes:
>>
>> > On Mon, Jul 18, 2016 at 2:23 PM, Markus Armbruster <armbru@redhat.com>
[...]
>> >> This is fine if gluster+rdma never actually worked.  I tried to find out
>> >> at https://github.com/gluster/glusterfs/blob/master/api/src/glfs.h.
>> >> Transport rdma is mentioned there.  Does it work?
>> >
>> > this is transport used for fetching the volume file from the nodes.
>> > Which is of type tcp previously and then now it also supports the unix
>> > transport.
>> >
>> > More response from gluster community
>> > @http://www.gluster.org/pipermail/gluster-devel/2016-July/050112.html
>>
>> Quote Raghavendra Talur's reply:
>>
>>     > My understanding is that @transport argumet in
>>     > glfs_set_volfile_server() is meant for specifying transport used in
>>     > fetching volfile server,
>>     >
>>
>>     Yes, @transport arg here is transport to use for fetching volfile.
>>
>>
>>     > IIRC which currently supports tcp and unix only...
>>     >
>>     Yes, this is correct too.
>>
>> Here, Raghavendra seems to confirm that only tcp and unix are supported.
>>
>>     >
>>     > The doc here
>>     > https://github.com/gluster/glusterfs/blob/master/api/src/glfs.h
>>     > +166 shows the rdma as well, which is something I cannot digest.
>>     >
>>     This is doc written with assumption that rdma would work too.
>>
>>
>>     >
>>     >
>>     > Can someone correct me ?
>>     >
>>     > Have we ever supported volfile fetch over rdma ?
>>     >
>>
>>     I think no. To test, you would have to set rdma as only transport
>> option in
>>     glusterd.vol and see what happens in volfile fetch.
>>
>> But here, it sounds like it might work anyway!
>>
>
> Prasanna, Rafi and I tested this. When rdma option is specified, gluster
> defaults to tcp silently.

Good to know.  Thanks!

>                           I do not like this behavior.

Understandable :)

>>     IMO, fetching volfile over rdma is an overkill and would not be
>> required.
>>     RDMA should be kept only for IO operations.
>>
>>     We should just remove it from the docs.
>>
>> Don't misunderstand me, I'm very much in favor of removing the rdma
>> transport here.  All I'm trying to do is figure out what backward
>> compatibility ramifications that might have.
>>
>> If protocol gluster+rdma has never actually worked, we can safely remove
>> it.
>>
>> But if it happens to work even though it isn't really supported, the
>> situation is complicated.  Dropping it might break working setups.
>> Could perhaps be justified by "your setup works, but it's unsupported,
>> and I'm forcing you to switch to a supported setup now, before you come
>> to grief."
>>
>> If it used to work but no more, or if it will stop working, it's
>> differently complicated.  Dropping it would still break working setups,
>> but they'd be bound to break anyway.
>>
>> Thus, my questions: does protocol gluster+rdma work before your patch?
>> If no, did it ever work?  "I don't know" is an acceptable answer to the
>> latter question, but not so much to the former, because that one is
>> easily testable.
>>
>
> Yes, it appeared to user that the option worked and removing the option
> would break such setups. I agree with Markus that removing the option right
> away would hurt users and we should follow a deprecation strategy for
> backward compatibility.

Since Gluster maps rdma to tcp, I think the following should do:

* If the user asks for file=gluster+rdma:..., print a warning and use
  file=gluster+tcp:... instead.  Deprecate this usage.

* Don't add transport 'rdma' to the QAPI schema.

What do you think?

[...]