On 05/09/2013 10:22 AM, Kaushal M wrote:
On Thu, May 9, 2013 at 8:17 AM, Vijay Bellur <vbel...@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
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@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::
[root@deepakcs-lx ~]# echo $?
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
220.127.116.11:1023 doesn't support required op-version. Rejecting getspec
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.
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.
Gluster-devel mailing list
vdsm-devel mailing list