[Gluster-devel] How to figure out the transport type of Gluster volume from VDSM host (which is not a gluster peer) ?

[Deepak C Shetty]

On 05/09/2013 10:22 AM, Kaushal M wrote:
> On Thu, May 9, 2013 at 8:17 AM, Vijay Bellur <vbellur at redhat.com> wrote:
>> On 05/07/2013 10:20 AM, Deepak C Shetty wrote:
>>> On 05/07/2013 01:13 AM, Vijay Bellur wrote:
>>>> On 05/06/2013 08:03 PM, Deepak C Shetty wrote:
>>>>> 2) Use gluster ::system getspec <volname>
>>>>>
>>>>> I tried this but it never worked for me... whats the right way of using
>>>>> this ?
>>>>> For me.. it just returned back to shell w/o dumping the volfile at all!
>>>>
>>>> The right way to use would be this:
>>>>
>>>> #gluster --remote-host=<server> system:: getspec <volname>
>>>
>>> This worked for me.. when I was on a non-peer which was in the same
>>> subnet as the gluster host
>>> But when i tried the same from my laptop (not in the same subnet) it
>>> didn't work.. Pls see below
>>>
>>> Also, you had indicated that this may not be a long supported option..
>>> so wondering if it makes sense to use it in VDSM ?
>>
>> Supporting --remote-host for other volume operations doesn't look like a
>> good idea. But we can retain the interface for fetching a volume spec file.
>>
>>
>>>   From my laptop
>>> --------------
>>> [root at deepakcs-lx ~]# gluster --version
>>> glusterfs 3.2.7 built on Aug 27 2012 19:47:26
>>> Repository revision: git://git.gluster.com/glusterfs.git
>>> Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com>
>>> GlusterFS comes with ABSOLUTELY NO WARRANTY.
>>> You may redistribute copies of GlusterFS under the terms of the GNU
>>> General Public License.
>>>
>>>
>>> [root at deepakcs-lx ~]# gluster --remote-host=llmvm02.in.ibm.com system::
>>> getspec fio
>>> [root at deepakcs-lx ~]# echo $?
>>> 255
>>>
>>> and on server side.. the below error was reported...
>>>
>>> [2013-05-07 04:44:06.517924] W [rpcsvc.c:180:rpcsvc_program_actor]
>>> 0-rpc-service: RPC program version not available (req 14398633 1)
>>> [2013-05-07 04:44:06.517992] E
>>> [rpcsvc.c:448:rpcsvc_check_and_reply_error] 0-rpcsvc: rpc actor failed
>>> to complete successfully
>>>
>>> So maybe its due to my gluster being old ?
>>
>> Yes, this is related to interaction between 3.2 and a later version.
>>
>>
>>>   From my colleague's laptop, having recent gluster
>>> ----------------------------------------------------
>>>
>>> <bharata> # gluster --version
>>> <bharata> glusterfs 3.4.0alpha2 built on Apr 10 2013 08:28:37
>>> <bharata> Repository revision: git://git.gluster.com/glusterfs.git
>>> <bharata> Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com>
>>> <bharata> GlusterFS comes with ABSOLUTELY NO WARRANTY.
>>> <bharata> You may redistribute copies of GlusterFS under the terms of
>>> the GNU General Public License.
>>>
>>> It fails here too.. the cli returned error 240 instead of 255 (in my
>>> laptop case) and server side had below error...
>>>
>>> <bharata> [2013-05-07 04:45:08.124567] I
>>> [glusterd-handshake.c:155:server_getspec] 0-management: Client
>>> 9.124.35.231:1023 doesn't support required op-version. Rejecting getspec
>>> request.
>>
>> This seems to be related to the recent op-version implementation. CC'ing
>> Kaushal for that.
>>
> I didn't know about the 'system:: getspec' command before, so didn't
> account for it in the getspec handler.
> I'll do the necessary changes.

Kaushal, thanks, can u pls Cc me on the bug, so that I can track it. 
This is now a dep for me/VDSM work.

Vijay,
     Another Q, with the above fix getting only in 3.4... i believe then 
VDSM dep for gluster will be minm 3.4 ?

>
>>>
>>> So looks like for getspec to work the non-peer host and gluster host
>>> versions should match exactly or something ...and if its so stringent, I
>>> am not sure if it makes sense to use --remote-host approach in
>>> VDSM..concern being there could be too many such version issues and VDSM
>>> failing that Users getting it working... what say ?
>>
>> 3.3 and 3.4 should be interoperable. Anything that impedes this should be
>> treated as a bug. If you have a real need for the fetch spec interface to
>> work with --remote-host, we can retain it.
>>
>> Thanks,
>>
>> Vijay
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>