On Thu, May 9, 2013 at 8:17 AM, Vijay Bellur <vbellur@xxxxxxxxxx> 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@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 ? > > > 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@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel
