Re: How to figure out the transport type of Gluster volume from VDSM host (which is not a gluster peer) ?

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

 



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 ?

gluster volume name fio running in llmvm02 system
-----------------------------------------------

[root@llmvm02 ~]# gluster volume info fio

Volume Name: fio
Type: Distribute
Volume ID: eea6f1a3-ad52-49cb-8135-670ea5ab23fe
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: llmvm02:/storage/fiobrick

[root@llmvm02 ~]# gluster --remote-host=llmvm02.in.ibm.com volume info fio

Volume Name: fio
Type: Distribute
Volume ID: eea6f1a3-ad52-49cb-8135-670ea5ab23fe
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: llmvm02:/storage/fiobrick

From /var/lib/glusterd/vols/fio/fio.llmvm02.storage-fiobrick.vol
auth allow is set to * as seen below

volume fio-server
    type protocol/server
    option auth.addr./storage/fiobrick.allow *
option auth.login.0656965d-f385-42df-b413-7ba16b09044d.password 99e32205-521a-4343-a65e-8122a8eafd7c option auth.login./storage/fiobrick.allow 0656965d-f385-42df-b413-7ba16b09044d
    option transport-type tcp
    subvolumes /storage/fiobrick




From llmvm03 system .. in the same subnet as 02
-----------------------------------------------

[root@llmvm03 ~]# gluster --remote-host=llmvm02.in.ibm.com volume info fio

Volume Name: fio
Type: Distribute
Volume ID: eea6f1a3-ad52-49cb-8135-670ea5ab23fe
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: llmvm02:/storage/fiobrick

[root@llmvm03 ~]# gluster peer status
peer status: No peers present

From my laptop
--------------
[root@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@deepakcs-lx ~]# gluster --remote-host=llmvm02.in.ibm.com system:: getspec fio
[root@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 ?

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.


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 ?

thanx,
deepak



-Vijay






[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux