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

[Vijay Bellur]

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.

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