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

[Kaushal M]

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.

>
>>
>>
>> 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