Hi Lists, I am looking at options to figure the transport type of a gluster volume (given the volfileserver:volname) from a host that is *not* part of gluster volume (aka not a gluster peer).
The context here is GlusterFS as a storage domain in oVirt/VDSM, which is currently available in upstream oVirt. This features exploits the QEMU-GlusterFS native integration, where the VM disk is specified using gluster+<transport>://... protocol.
For eg. if transport is TCP.. the URI looks liek gluster+tcp://..., otherwise gluster+rdma://...
Thus, to generate the gluster QEMU URI in VDSM, i need to know the Gluster volume's transport type and the only inputs that oVirt gets for GlusterFS storage domain are... a) volfileserver (the host running glusterd) b) volname (the name of the volume)
Currently i use VDSM's gluster plugin to do the eq. of "gluster volume info <volname>" to determine Gluster volume's transport type, but this won't work if the VDSM host is not a gluster peer, which is a constraint! ... and I would like to fix/remove this constraint.
So i discussed a bit on #glsuter-dev IRC and want to put down the options here for the community to help provide inputs on whats the best way to approach this...
1) Use gluster --remote-host=<host_running_glusterd> volume info <volname>
This is not a supported way and there is no guarantee on how long the --remote-host option be supported in gluster, since it has some security issues
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!
3) Have oVirt user provide the transport type as well (while creating Gluster storgae domain) in addition to volfileserver:volname options
This would be easiest, since VDSM can form the gluster QEMU URI by directly using the transport type specified by the user, and this won't have a need to use the vdsm-gluster plugin, hence no need for VDSM host to be part of gluster peer...but this would mean addnl input for user to provide during Gluster domain creation and oVirt UI changes to take the transport type as input in addition to volfileserver:volname
Comments/Opinions/Inputs appreciated
thanx, deepak
(P.S. cross-posting this to VDSM and Gluster devel lists, as it relates to both)
2013-5-6 22:33, Deepak C Shetty:
Hi Lists, I am looking at options to figure the transport type of a gluster volume (given the volfileserver:volname) from a host that is *not* part of gluster volume (aka not a gluster peer).
The context here is GlusterFS as a storage domain in oVirt/VDSM, which is currently available in upstream oVirt. This features exploits the QEMU-GlusterFS native integration, where the VM disk is specified using gluster+<transport>://... protocol.
For eg. if transport is TCP.. the URI looks liek
gluster+tcp://..., otherwise gluster+rdma://...
Thus, to generate the gluster QEMU URI in VDSM, i need to know the Gluster volume's transport type and the only inputs that oVirt gets for GlusterFS storage domain are... a) volfileserver (the host running glusterd) b) volname (the name of the volume)
Currently i use VDSM's gluster plugin to do the eq. of "gluster volume info <volname>" to determine Gluster volume's transport type, but this won't work if the VDSM host is not a gluster peer,
What do you mean by using "gluster peer"? Does "gluster peer" mean the host is running glusterd?
which is a constraint! ... and I would like to fix/remove this constraint.
So i discussed a bit on #glsuter-dev IRC and want to put down the options here for the community to help provide inputs on whats the best way to approach this...
- Use gluster --remote-host=<host_running_glusterd> volume info
<volname>
This is not a supported way and there is no guarantee on how long the --remote-host option be supported in gluster, since it has some security issues
- 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!
- Have oVirt user provide the transport type as well (while creating
Gluster storgae domain) in addition to volfileserver:volname options
This would be easiest, since VDSM can form the gluster QEMU URI by directly using the transport type specified by the user, and this won't have a need to use the vdsm-gluster plugin, hence no need for VDSM host to be part of gluster peer...but this would mean addnl input for user to provide during Gluster domain creation and oVirt UI changes to take the transport type as input in addition to volfileserver:volname
What will happen if a user gives a wrong transport type to VDSM?
Comments/Opinions/Inputs appreciated
thanx, deepak
(P.S. cross-posting this to VDSM and Gluster devel lists, as it relates to both)
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On 05/06/2013 08:47 PM, Shu Ming wrote:
2013-5-6 22:33, Deepak C Shetty:
Hi Lists, I am looking at options to figure the transport type of a gluster volume (given the volfileserver:volname) from a host that is *not* part of gluster volume (aka not a gluster peer).
The context here is GlusterFS as a storage domain in oVirt/VDSM, which is currently available in upstream oVirt. This features exploits the QEMU-GlusterFS native integration, where the VM disk is specified using gluster+<transport>://... protocol.
For eg. if transport is TCP.. the URI looks liek
gluster+tcp://..., otherwise gluster+rdma://...
Thus, to generate the gluster QEMU URI in VDSM, i need to know the Gluster volume's transport type and the only inputs that oVirt gets for GlusterFS storage domain are... a) volfileserver (the host running glusterd) b) volname (the name of the volume)
Currently i use VDSM's gluster plugin to do the eq. of "gluster volume info <volname>" to determine Gluster volume's transport type, but this won't work if the VDSM host is not a gluster peer,
What do you mean by using "gluster peer"? Does "gluster peer" mean the host is running glusterd?
In Gluster, the hosts that are part of a gluster storage volume (serving the bricks (aka storage) to the volume) are called gluster peers. So if VDSM host is not serving storage to the gluster volume, its a non-peer and you cannot invoke gluster cli from a non-peer host, simply because it wouldn't make sense for a non-participating host to know abt gluster volumes ... thus there is the --remote-host option.. which is not encouraged to use and not guaranteed to be supported in future.
Yes.. and all gluster peers run glusterd
which is a constraint! ... and I would like to fix/remove this constraint.
So i discussed a bit on #glsuter-dev IRC and want to put down the options here for the community to help provide inputs on whats the best way to approach this...
- Use gluster --remote-host=<host_running_glusterd> volume info
<volname>
This is not a supported way and there is no guarantee on how long the --remote-host option be supported in gluster, since it has some security issues
- 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!
- Have oVirt user provide the transport type as well (while creating
Gluster storgae domain) in addition to volfileserver:volname options
This would be easiest, since VDSM can form the gluster QEMU URI by directly using the transport type specified by the user, and this won't have a need to use the vdsm-gluster plugin, hence no need for VDSM host to be part of gluster peer...but this would mean addnl input for user to provide during Gluster domain creation and oVirt UI changes to take the transport type as input in addition to volfileserver:volname
What will happen if a user gives a wrong transport type to VDSM?
Simply said... The gluster QEMU URI will be formed wrongly, QEMU would error out, hence VDSM and hence oVirt user will see the error while creating the VM. But.. in oVirt GUI we can have a combo box prefilled with "TCP", "RDMA" so that user has to choose one of the valid types only.. then the problem of giving wrong transport type does not arise.
thanx, deepak
Comments/Opinions/Inputs appreciated
thanx, deepak
(P.S. cross-posting this to VDSM and Gluster devel lists, as it relates to both)
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On 05/06/2013 08:03 PM, Deepak C Shetty wrote:
- 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>
-Vijay
On 05/07/2013 01:13 AM, Vijay Bellur wrote:
On 05/06/2013 08:03 PM, Deepak C Shetty wrote:
- 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
Hi,
Just a random thought: is any of the information required here available through snmp ? You could then send snmp query's from any host without the requirement of it being a 'peer'.
Just my 2$.
Regards,
John Smith.
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:
- 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.
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
On Thu, May 9, 2013 at 8:17 AM, Vijay Bellur vbellur@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:
- 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@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
On 05/09/2013 10:22 AM, Kaushal M wrote:
On Thu, May 9, 2013 at 8:17 AM, Vijay Bellur vbellur@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:
- 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.
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.
Vijay, 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.
Thanks,
Vijay
Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
On 05/09/2013 07:33 PM, Deepak C Shetty wrote:
On 05/09/2013 10:22 AM, Kaushal M wrote:
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.
Vijay, Another Q, with the above fix getting only in 3.4... i believe then VDSM dep for gluster will be minm 3.4 ?
Yes, for the current gluster functionality in vdsm to work properly the dependent version of GlusterFS would be 3.4 minimum.
-Vijay
On 05/09/2013 08:17 AM, Vijay Bellur 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:
- 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.
Thanks!
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.
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.
I hope the VDSM Gluster storage domain usecase satisfied the need to retain --remote-host.
Any idea if --remote-host is supported in VDSM's gluster plugin ? I did a quick find and didn't see it (CCing Bala too)
thanx, deepak
Vijay, Per the discussion over IRC and this thread....
VDSM Gluster Storage domain patch to use gluster cli's --remote-info feature for fetching volume info is merged See http://gerrit.ovirt.org/#/c/14666/ for more details
thanx, deepak
On 05/09/2013 08:17 AM, Vijay Bellur 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:
- 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.
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
vdsm-devel@lists.fedorahosted.org