Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam wrote: Rob, It seems that a bug in vdsm code is hiding the real issue. Could you do a sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py restart vdsmd, and retry? Bala, would you send a patch fixing the ParseError issue (and adding a Ok, both issues have fixes which are in the ovirt-3.2 git branch. I believe this deserves a respin of vdsm, as having an undeclated requirement is impolite. Federico, Mike, would you take care for that? Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Balamurugan Arumugam barum...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Mike Burns mbu...@redhat.com Cc: Rob Zwissler r...@zwissler.org, users@ovirt.org, a...@ovirt.org, Aravinda VK avish...@redhat.com, Ayal Baron aba...@redhat.com Sent: Wednesday, March 13, 2013 9:03:39 PM Subject: Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3 On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam wrote: Rob, It seems that a bug in vdsm code is hiding the real issue. Could you do a sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py restart vdsmd, and retry? Bala, would you send a patch fixing the ParseError issue (and adding a Ok, both issues have fixes which are in the ovirt-3.2 git branch. I believe this deserves a respin of vdsm, as having an undeclated requirement is impolite. Federico, Mike, would you take care for that? Since we're at it... I have the feeling that this might be important enough to be backported to 3.2 too: http://gerrit.ovirt.org/#/c/12178/ -- Federico ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Wed, Mar 13, 2013 at 04:10:56PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Balamurugan Arumugam barum...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Mike Burns mbu...@redhat.com Cc: Rob Zwissler r...@zwissler.org, users@ovirt.org, a...@ovirt.org, Aravinda VK avish...@redhat.com, Ayal Baron aba...@redhat.com Sent: Wednesday, March 13, 2013 9:03:39 PM Subject: Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3 On Mon, Mar 11, 2013 at 12:34:51PM +0200, Dan Kenigsberg wrote: On Mon, Mar 11, 2013 at 06:09:56AM -0400, Balamurugan Arumugam wrote: Rob, It seems that a bug in vdsm code is hiding the real issue. Could you do a sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py restart vdsmd, and retry? Bala, would you send a patch fixing the ParseError issue (and adding a Ok, both issues have fixes which are in the ovirt-3.2 git branch. I believe this deserves a respin of vdsm, as having an undeclated requirement is impolite. Federico, Mike, would you take care for that? Since we're at it... I have the feeling that this might be important enough to be backported to 3.2 too: http://gerrit.ovirt.org/#/c/12178/ Yes, it is quite horrible. Could you include that, too? ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Wed, Mar 06, 2013 at 02:34:10PM +0530, Balamurugan Arumugam wrote:
On 03/06/2013 01:20 PM, Dan Kenigsberg wrote:
On Tue, Mar 05, 2013 at 10:08:48AM -0800, Rob Zwissler wrote:
On Mon, Mar 4, 2013 at 11:46 PM, Dan Kenigsberg dan...@redhat.com wrote:
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError
/usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: class ElementTree has no attribute 'ParseError'
My guess has led us nowhere, since etree.ParseError is simply missing
from python 2.6. It is to be seen only in python 2.7!
That's sad, but something *else* is problematic, since we got to this
error-handling code.
Could you make another try and temporarily replace ParseError with
Exception?
sed -i s/etree.ParseError/Exception/ /usr/share/vdsm/gluster/cli.py
(this sed is relative to the original code).
More specific sed is
sed -i s/etree.ParseError/SyntaxError/ /usr/share/vdsm/gluster/cli.py
Bala, Aravinda, I have not seem a vdsm patch adding an explicit
dependency on the correct gluster-cli version. Only a change for for
this ParseError issue http://gerrit.ovirt.org/#/c/12829/
Is there anything blocking this? I would really like to clear this
hurdle quickly.
Dan.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
Hi Rob, On 03/06/2013 05:59 PM, Rob Zwissler wrote: On one hand I like oVirt, I think you guys have done a good job with this, and it is free software so I don't want to complain. But on the other hand, if you release a major/stable release (ie: oVirt 3.2), but it relies on a major/critical component (clustering filesystem server) that is in alpha, not even beta, but alpha prerelease form, you really should be up front and communicative about this. My searches turned up nothing except an offhand statement from a GlusterFS developer, nothing from the oVirt team until now. It is not acceptable to expect people to run something as critical as a cluster filesystem server in alpha form on anything short of a development test setup. Are any other components of oVirt 3.2 dependent on non-stable general release packages? What is the latest release of oVirt considered to be stable and considered safe for use on production systems? It seems like there has been conflation of two things here - I may be wrong with what I say, but having checked, I do not believe so. With oVirt 3.2/Gluster 3.4, you will be able to manage Gluster clusters using the oVirt engine. This is a completely new integration, which is still not in a production Gluster release. However, it is still completely fine to use Gluster as storage for an oVirt 3.1 or 3.2 managed cluster. The ability to use Gluster easily as a storage back-end was added in oVirt 3.1, and as far as I know, there is no problem using glusterfs 3.3 as a POSIX storage filesystem for oVirt 3.2. Vijay, Shireesh, Ayal, is my understanding correct? I am worried that we've been giving people the wrong impression here. Thanks! Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On 03/07/2013 04:36 PM, Dave Neary wrote: Hi Rob, On 03/06/2013 05:59 PM, Rob Zwissler wrote: On one hand I like oVirt, I think you guys have done a good job with this, and it is free software so I don't want to complain. But on the other hand, if you release a major/stable release (ie: oVirt 3.2), but it relies on a major/critical component (clustering filesystem server) that is in alpha, not even beta, but alpha prerelease form, you really should be up front and communicative about this. My searches turned up nothing except an offhand statement from a GlusterFS developer, nothing from the oVirt team until now. It is not acceptable to expect people to run something as critical as a cluster filesystem server in alpha form on anything short of a development test setup. Are any other components of oVirt 3.2 dependent on non-stable general release packages? What is the latest release of oVirt considered to be stable and considered safe for use on production systems? It seems like there has been conflation of two things here - I may be wrong with what I say, but having checked, I do not believe so. With oVirt 3.2/Gluster 3.4, you will be able to manage Gluster clusters using the oVirt engine. This is a completely new integration, which is still not in a production Gluster release. However, it is still completely fine to use Gluster as storage for an oVirt 3.1 or 3.2 managed cluster. The ability to use Gluster easily as a storage back-end was added in oVirt 3.1, and as far as I know, there is no problem using glusterfs 3.3 as a POSIX storage filesystem for oVirt 3.2. Vijay, Shireesh, Ayal, is my understanding correct? I am worried that we've been giving people the wrong impression here. Yes, your description is right. Thanks, Vijay ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On 03/05/2013 06:08 AM, Rob Zwissler wrote:
Running CentOS 6.3 with the following VDSM packages from dre's repo:
vdsm-xmlrpc-4.10.3-0.30.19.el6.noarch
vdsm-gluster-4.10.3-0.30.19.el6.noarch
vdsm-python-4.10.3-0.30.19.el6.x86_64
vdsm-4.10.3-0.30.19.el6.x86_64
vdsm-cli-4.10.3-0.30.19.el6.noarch
And the following gluster packages from the gluster repo:
glusterfs-3.3.1-1.el6.x86_64
glusterfs-fuse-3.3.1-1.el6.x86_64
glusterfs-vim-3.2.7-1.el6.x86_64
glusterfs-server-3.3.1-1.el6.x86_64
oVirt 3.2 needs a newer (3.4.0) version of glusterfs, which is currently
in alpha and hence not available in stable repositories.
http://bits.gluster.org/pub/gluster/glusterfs/3.4.0alpha/
This issue has been reported multiple times now, and I think it needs an
update to the oVirt 3.2 release notes. Have added a note to this effect at:
http://www.ovirt.org/OVirt_3.2_release_notes#Storage
I get the following errors in vdsm.log:
Thread-1483::DEBUG::2013-03-04
16:35:27,427::BindingXMLRPC::913::vds::(wrapper) client
[10.33.9.73]::call volumesList with () {}
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,429::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,480::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err
= ''; rc = 0
MainProcess|Thread-1483::ERROR::2013-03-04
16:35:27,480::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 352, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 430, in volumeInfo
except (etree.ParseError, AttributeError, ValueError):
AttributeError: 'module' object has no attribute 'ParseError'
Thread-1483::ERROR::2013-03-04
16:35:27,481::BindingXMLRPC::932::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: 'module' object has no attribute 'ParseError'
Which corresponds to the following in the engine.log:
2013-03-04 16:34:46,231 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) START,
GlusterVolumesListVDSCommand(HostName = xor-q-virt01, HostId =
b342bf4d-d9e9-4055-b662-462dc2e6bf50), log id: 987aef3
2013-03-04 16:34:46,365 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Failed in GlusterVolumesListVDS method
2013-03-04 16:34:46,366 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Error code unexpected and error message
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
2013-03-04 16:34:46,367 ERROR
[org.ovirt.engine.core.vdsbroker.VDSCommandBase]
(QuartzScheduler_Worker-86) Command GlusterVolumesListVDS execution
failed. Exception: VDSErrorException: VDSGenericException:
VDSErrorException: Failed to GlusterVolumesListVDS, error = Unexpected
exception
2013-03-04 16:34:46,369 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) FINISH, GlusterVolumesListVDSCommand, log
id: 987aef3
2013-03-04 16:34:46,370 ERROR
[org.ovirt.engine.core.bll.gluster.GlusterManager]
(QuartzScheduler_Worker-86) Error while refreshing Gluster lightweight
data of cluster qa-cluster1!:
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
at
org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:168)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVdsCommand(VDSBrokerFrontendImpl.java:33)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.runVdsCommand(GlusterManager.java:258)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.fetchVolumes(GlusterManager.java:454)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.fetchVolumes(GlusterManager.java:440)
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On 03/05/2013 01:16 PM, Dan Kenigsberg wrote:
On Mon, Mar 04, 2013 at 04:38:50PM -0800, Rob Zwissler wrote:
Running CentOS 6.3 with the following VDSM packages from dre's repo:
vdsm-xmlrpc-4.10.3-0.30.19.el6.noarch
vdsm-gluster-4.10.3-0.30.19.el6.noarch
vdsm-python-4.10.3-0.30.19.el6.x86_64
vdsm-4.10.3-0.30.19.el6.x86_64
vdsm-cli-4.10.3-0.30.19.el6.noarch
And the following gluster packages from the gluster repo:
glusterfs-3.3.1-1.el6.x86_64
glusterfs-fuse-3.3.1-1.el6.x86_64
glusterfs-vim-3.2.7-1.el6.x86_64
glusterfs-server-3.3.1-1.el6.x86_64
I get the following errors in vdsm.log:
Thread-1483::DEBUG::2013-03-04
16:35:27,427::BindingXMLRPC::913::vds::(wrapper) client
[10.33.9.73]::call volumesList with () {}
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,429::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,480::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err
= ''; rc = 0
MainProcess|Thread-1483::ERROR::2013-03-04
16:35:27,480::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 352, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 430, in volumeInfo
except (etree.ParseError, AttributeError, ValueError):
AttributeError: 'module' object has no attribute 'ParseError'
Thread-1483::ERROR::2013-03-04
16:35:27,481::BindingXMLRPC::932::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: 'module' object has no attribute 'ParseError'
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
python 2.7 throws ParseError whereas python 2.6 throws SyntaxError.
Aravinda is sending a fix for it.
Regards,
Bala
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On 03/06/2013 01:20 PM, Dan Kenigsberg wrote:
On Tue, Mar 05, 2013 at 10:08:48AM -0800, Rob Zwissler wrote:
On Mon, Mar 4, 2013 at 11:46 PM, Dan Kenigsberg dan...@redhat.com wrote:
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: class ElementTree has no attribute 'ParseError'
My guess has led us nowhere, since etree.ParseError is simply missing
from python 2.6. It is to be seen only in python 2.7!
That's sad, but something *else* is problematic, since we got to this
error-handling code.
Could you make another try and temporarily replace ParseError with
Exception?
sed -i s/etree.ParseError/Exception/ /usr/share/vdsm/gluster/cli.py
(this sed is relative to the original code).
More specific sed is
sed -i s/etree.ParseError/SyntaxError/ /usr/share/vdsm/gluster/cli.py
Regards,
Bala
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Wed, Mar 06, 2013 at 02:04:29PM +0530, Shireesh Anjal wrote:
On 03/05/2013 06:08 AM, Rob Zwissler wrote:
Running CentOS 6.3 with the following VDSM packages from dre's repo:
vdsm-xmlrpc-4.10.3-0.30.19.el6.noarch
vdsm-gluster-4.10.3-0.30.19.el6.noarch
vdsm-python-4.10.3-0.30.19.el6.x86_64
vdsm-4.10.3-0.30.19.el6.x86_64
vdsm-cli-4.10.3-0.30.19.el6.noarch
And the following gluster packages from the gluster repo:
glusterfs-3.3.1-1.el6.x86_64
glusterfs-fuse-3.3.1-1.el6.x86_64
glusterfs-vim-3.2.7-1.el6.x86_64
glusterfs-server-3.3.1-1.el6.x86_64
oVirt 3.2 needs a newer (3.4.0) version of glusterfs, which is
currently in alpha and hence not available in stable repositories.
http://bits.gluster.org/pub/gluster/glusterfs/3.4.0alpha/
Shireesh, this should be specifed in vdsm.spec - please patch both
master and ovirt-3.2 branches.
Beyond that, there's a problem of Python 2.6 missing ParseError.
This issue has been reported multiple times now, and I think it
needs an update to the oVirt 3.2 release notes. Have added a note to
this effect at:
http://www.ovirt.org/OVirt_3.2_release_notes#Storage
I get the following errors in vdsm.log:
Thread-1483::DEBUG::2013-03-04
16:35:27,427::BindingXMLRPC::913::vds::(wrapper) client
[10.33.9.73]::call volumesList with () {}
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,429::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,480::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err
= ''; rc = 0
MainProcess|Thread-1483::ERROR::2013-03-04
16:35:27,480::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 352, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 430, in volumeInfo
except (etree.ParseError, AttributeError, ValueError):
AttributeError: 'module' object has no attribute 'ParseError'
Thread-1483::ERROR::2013-03-04
16:35:27,481::BindingXMLRPC::932::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: 'module' object has no attribute 'ParseError'
Which corresponds to the following in the engine.log:
2013-03-04 16:34:46,231 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) START,
GlusterVolumesListVDSCommand(HostName = xor-q-virt01, HostId =
b342bf4d-d9e9-4055-b662-462dc2e6bf50), log id: 987aef3
2013-03-04 16:34:46,365 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Failed in GlusterVolumesListVDS method
2013-03-04 16:34:46,366 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Error code unexpected and error message
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
2013-03-04 16:34:46,367 ERROR
[org.ovirt.engine.core.vdsbroker.VDSCommandBase]
(QuartzScheduler_Worker-86) Command GlusterVolumesListVDS execution
failed. Exception: VDSErrorException: VDSGenericException:
VDSErrorException: Failed to GlusterVolumesListVDS, error = Unexpected
exception
2013-03-04 16:34:46,369 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) FINISH, GlusterVolumesListVDSCommand, log
id: 987aef3
2013-03-04 16:34:46,370 ERROR
[org.ovirt.engine.core.bll.gluster.GlusterManager]
(QuartzScheduler_Worker-86) Error while refreshing Gluster lightweight
data of cluster qa-cluster1!:
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
at
org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:168)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVdsCommand(VDSBrokerFrontendImpl.java:33)
[engine-bll.jar:]
at
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
Hi,
Sent a patch to handle ParseError attribute issue. vdsm still depends on
newer(3.4) version of glusterfs, but Python ParseError is fixed.
http://gerrit.ovirt.org/#/c/12752/
--
regards
Aravinda
On 03/06/2013 01:20 PM, Dan Kenigsberg wrote:
On Tue, Mar 05, 2013 at 10:08:48AM -0800, Rob Zwissler wrote:
On Mon, Mar 4, 2013 at 11:46 PM, Dan Kenigsberg dan...@redhat.com wrote:
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: class ElementTree has no attribute 'ParseError'
My guess has led us nowhere, since etree.ParseError is simply missing
from python 2.6. It is to be seen only in python 2.7!
That's sad, but something *else* is problematic, since we got to this
error-handling code.
Could you make another try and temporarily replace ParseError with
Exception?
sed -i s/etree.ParseError/Exception/ /usr/share/vdsm/gluster/cli.py
(this sed is relative to the original code).
Dan.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Wed, Mar 6, 2013 at 12:34 AM, Shireesh Anjal san...@redhat.com wrote: oVirt 3.2 needs a newer (3.4.0) version of glusterfs, which is currently in alpha and hence not available in stable repositories. http://bits.gluster.org/pub/gluster/glusterfs/3.4.0alpha/ This issue has been reported multiple times now, and I think it needs an update to the oVirt 3.2 release notes. Have added a note to this effect at: http://www.ovirt.org/OVirt_3.2_release_notes#Storage On one hand I like oVirt, I think you guys have done a good job with this, and it is free software so I don't want to complain. But on the other hand, if you release a major/stable release (ie: oVirt 3.2), but it relies on a major/critical component (clustering filesystem server) that is in alpha, not even beta, but alpha prerelease form, you really should be up front and communicative about this. My searches turned up nothing except an offhand statement from a GlusterFS developer, nothing from the oVirt team until now. It is not acceptable to expect people to run something as critical as a cluster filesystem server in alpha form on anything short of a development test setup. Are any other components of oVirt 3.2 dependent on non-stable general release packages? What is the latest release of oVirt considered to be stable and considered safe for use on production systems? Rob ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On 03/06/2013 10:29 PM, Rob Zwissler wrote: On Wed, Mar 6, 2013 at 12:34 AM, Shireesh Anjal san...@redhat.com wrote: oVirt 3.2 needs a newer (3.4.0) version of glusterfs, which is currently in alpha and hence not available in stable repositories. http://bits.gluster.org/pub/gluster/glusterfs/3.4.0alpha/ This issue has been reported multiple times now, and I think it needs an update to the oVirt 3.2 release notes. Have added a note to this effect at: http://www.ovirt.org/OVirt_3.2_release_notes#Storage On one hand I like oVirt, I think you guys have done a good job with this, and it is free software so I don't want to complain. But on the other hand, if you release a major/stable release (ie: oVirt 3.2), but it relies on a major/critical component (clustering filesystem server) that is in alpha, not even beta, but alpha prerelease form, you really should be up front and communicative about this. My searches turned up nothing except an offhand statement from a GlusterFS developer, nothing from the oVirt team until now. It is not acceptable to expect people to run something as critical as a cluster filesystem server in alpha form on anything short of a development test setup. Are any other components of oVirt 3.2 dependent on non-stable general release packages? What is the latest release of oVirt considered to be stable and considered safe for use on production systems? Hi Rob, Your points are completely valid, and it's my fault (and not the oVirt release team's) not mentioning this important information when providing details of gluster related features to be included in the oVirt 3.2 release notes. Genuine apologies for the same. Having said this, I believe the stable release of glusterfs 3.4.0 should be coming out very soon (some time this month if I'm correct), which will provide some relief. Regards, Shireesh Rob ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Mon, Mar 4, 2013 at 11:46 PM, Dan Kenigsberg dan...@redhat.com wrote:
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Regards,
Dan.
Hi Dan, thanks for the quick response. I did that, and here's what I
get now from the vdsm.log:
MainProcess|Thread-51::DEBUG::2013-03-05
10:03:40,723::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
Thread-52::DEBUG::2013-03-05
10:03:40,731::task::568::TaskManager.Task::(_updateState)
Task=`aa1990a1-8016-4337-a8cd-1b62976032a4`::moving from state init -
state preparing
Thread-52::INFO::2013-03-05
10:03:40,732::logUtils::41::dispatcher::(wrapper) Run and protect:
repoStats(options=None)
Thread-52::INFO::2013-03-05
10:03:40,732::logUtils::44::dispatcher::(wrapper) Run and protect:
repoStats, Return response: {'4af726ea-e502-4e79-a47c-6c8558ca96ad':
{'delay': '0.00584101676941', 'lastCheck': '0.2', 'code': 0, 'valid':
True}, 'fc0d44ec-528f-4bf9-8913-fa7043daf43b': {'delay':
'0.0503160953522', 'lastCheck': '0.2', 'code': 0, 'valid': True}}
Thread-52::DEBUG::2013-03-05
10:03:40,732::task::1151::TaskManager.Task::(prepare)
Task=`aa1990a1-8016-4337-a8cd-1b62976032a4`::finished:
{'4af726ea-e502-4e79-a47c-6c8558ca96ad': {'delay': '0.00584101676941',
'lastCheck': '0.2', 'code': 0, 'valid': True},
'fc0d44ec-528f-4bf9-8913-fa7043daf43b': {'delay': '0.0503160953522',
'lastCheck': '0.2', 'code': 0, 'valid': True}}
Thread-52::DEBUG::2013-03-05
10:03:40,732::task::568::TaskManager.Task::(_updateState)
Task=`aa1990a1-8016-4337-a8cd-1b62976032a4`::moving from state
preparing - state finished
Thread-52::DEBUG::2013-03-05
10:03:40,732::resourceManager::830::ResourceManager.Owner::(releaseAll)
Owner.releaseAll requests {} resources {}
Thread-52::DEBUG::2013-03-05
10:03:40,733::resourceManager::864::ResourceManager.Owner::(cancelAll)
Owner.cancelAll requests {}
Thread-52::DEBUG::2013-03-05
10:03:40,733::task::957::TaskManager.Task::(_decref)
Task=`aa1990a1-8016-4337-a8cd-1b62976032a4`::ref 0 aborting False
Thread-53::DEBUG::2013-03-05
10:03:40,742::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`2c59dfa7-442c-46fb-8102-298db1ebc3bf`::Disk hdc stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,742::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`2c59dfa7-442c-46fb-8102-298db1ebc3bf`::Disk vda stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,742::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`2c59dfa7-442c-46fb-8102-298db1ebc3bf`::Disk hdc latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,742::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`2c59dfa7-442c-46fb-8102-298db1ebc3bf`::Disk vda latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,743::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`8555382a-b3fa-4a4b-a61e-a80da47478a5`::Disk hdc stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,743::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`8555382a-b3fa-4a4b-a61e-a80da47478a5`::Disk vda stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,743::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`8555382a-b3fa-4a4b-a61e-a80da47478a5`::Disk hdc latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,743::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`8555382a-b3fa-4a4b-a61e-a80da47478a5`::Disk vda latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,744::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`a2617d92-6145-4ba2-b40f-d793f037e031`::Disk hdc stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,744::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`a2617d92-6145-4ba2-b40f-d793f037e031`::Disk vda stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,744::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`a2617d92-6145-4ba2-b40f-d793f037e031`::Disk hdc latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,744::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`a2617d92-6145-4ba2-b40f-d793f037e031`::Disk vda latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,745::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`c63f8d87-e6bf-49fd-9642-90aefd1aff84`::Disk hdc stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,745::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`c63f8d87-e6bf-49fd-9642-90aefd1aff84`::Disk vda stats not
available
Thread-53::DEBUG::2013-03-05
10:03:40,745::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`c63f8d87-e6bf-49fd-9642-90aefd1aff84`::Disk hdc latency not
available
Thread-53::DEBUG::2013-03-05
10:03:40,745::libvirtvm::308::vm.Vm::(_getDiskLatency)
vmId=`c63f8d87-e6bf-49fd-9642-90aefd1aff84`::Disk vda latency not
available
GuestMonitor-xor-q-nis02::DEBUG::2013-03-05
10:03:40,750::libvirtvm::269::vm.Vm::(_getDiskStats)
vmId=`2c59dfa7-442c-46fb-8102-298db1ebc3bf`::Disk hdc stats not
available
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Tue, Mar 05, 2013 at 10:08:48AM -0800, Rob Zwissler wrote:
On Mon, Mar 4, 2013 at 11:46 PM, Dan Kenigsberg dan...@redhat.com wrote:
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError
/usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: class ElementTree has no attribute 'ParseError'
My guess has led us nowhere, since etree.ParseError is simply missing
from python 2.6. It is to be seen only in python 2.7!
That's sad, but something *else* is problematic, since we got to this
error-handling code.
Could you make another try and temporarily replace ParseError with
Exception?
sed -i s/etree.ParseError/Exception/ /usr/share/vdsm/gluster/cli.py
(this sed is relative to the original code).
Dan.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
[Users] oVirt 3.2 on CentOS with Gluster 3.3
Running CentOS 6.3 with the following VDSM packages from dre's repo:
vdsm-xmlrpc-4.10.3-0.30.19.el6.noarch
vdsm-gluster-4.10.3-0.30.19.el6.noarch
vdsm-python-4.10.3-0.30.19.el6.x86_64
vdsm-4.10.3-0.30.19.el6.x86_64
vdsm-cli-4.10.3-0.30.19.el6.noarch
And the following gluster packages from the gluster repo:
glusterfs-3.3.1-1.el6.x86_64
glusterfs-fuse-3.3.1-1.el6.x86_64
glusterfs-vim-3.2.7-1.el6.x86_64
glusterfs-server-3.3.1-1.el6.x86_64
I get the following errors in vdsm.log:
Thread-1483::DEBUG::2013-03-04
16:35:27,427::BindingXMLRPC::913::vds::(wrapper) client
[10.33.9.73]::call volumesList with () {}
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,429::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,480::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err
= ''; rc = 0
MainProcess|Thread-1483::ERROR::2013-03-04
16:35:27,480::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 352, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 430, in volumeInfo
except (etree.ParseError, AttributeError, ValueError):
AttributeError: 'module' object has no attribute 'ParseError'
Thread-1483::ERROR::2013-03-04
16:35:27,481::BindingXMLRPC::932::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: 'module' object has no attribute 'ParseError'
Which corresponds to the following in the engine.log:
2013-03-04 16:34:46,231 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) START,
GlusterVolumesListVDSCommand(HostName = xor-q-virt01, HostId =
b342bf4d-d9e9-4055-b662-462dc2e6bf50), log id: 987aef3
2013-03-04 16:34:46,365 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Failed in GlusterVolumesListVDS method
2013-03-04 16:34:46,366 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
(QuartzScheduler_Worker-86) Error code unexpected and error message
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
2013-03-04 16:34:46,367 ERROR
[org.ovirt.engine.core.vdsbroker.VDSCommandBase]
(QuartzScheduler_Worker-86) Command GlusterVolumesListVDS execution
failed. Exception: VDSErrorException: VDSGenericException:
VDSErrorException: Failed to GlusterVolumesListVDS, error = Unexpected
exception
2013-03-04 16:34:46,369 INFO
[org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand]
(QuartzScheduler_Worker-86) FINISH, GlusterVolumesListVDSCommand, log
id: 987aef3
2013-03-04 16:34:46,370 ERROR
[org.ovirt.engine.core.bll.gluster.GlusterManager]
(QuartzScheduler_Worker-86) Error while refreshing Gluster lightweight
data of cluster qa-cluster1!:
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to
GlusterVolumesListVDS, error = Unexpected exception
at
org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:168)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVdsCommand(VDSBrokerFrontendImpl.java:33)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.runVdsCommand(GlusterManager.java:258)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.fetchVolumes(GlusterManager.java:454)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.fetchVolumes(GlusterManager.java:440)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.refreshVolumeData(GlusterManager.java:411)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.refreshClusterData(GlusterManager.java:191)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.gluster.GlusterManager.refreshLightWeightData(GlusterManager.java:170)
[engine-bll.jar:]
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
Re: [Users] oVirt 3.2 on CentOS with Gluster 3.3
On Mon, Mar 04, 2013 at 04:38:50PM -0800, Rob Zwissler wrote:
Running CentOS 6.3 with the following VDSM packages from dre's repo:
vdsm-xmlrpc-4.10.3-0.30.19.el6.noarch
vdsm-gluster-4.10.3-0.30.19.el6.noarch
vdsm-python-4.10.3-0.30.19.el6.x86_64
vdsm-4.10.3-0.30.19.el6.x86_64
vdsm-cli-4.10.3-0.30.19.el6.noarch
And the following gluster packages from the gluster repo:
glusterfs-3.3.1-1.el6.x86_64
glusterfs-fuse-3.3.1-1.el6.x86_64
glusterfs-vim-3.2.7-1.el6.x86_64
glusterfs-server-3.3.1-1.el6.x86_64
I get the following errors in vdsm.log:
Thread-1483::DEBUG::2013-03-04
16:35:27,427::BindingXMLRPC::913::vds::(wrapper) client
[10.33.9.73]::call volumesList with () {}
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,429::misc::84::Storage.Misc.excCmd::(lambda)
'/usr/sbin/gluster --mode=script volume info --xml' (cwd None)
MainProcess|Thread-1483::DEBUG::2013-03-04
16:35:27,480::misc::84::Storage.Misc.excCmd::(lambda) SUCCESS: err
= ''; rc = 0
MainProcess|Thread-1483::ERROR::2013-03-04
16:35:27,480::supervdsmServer::80::SuperVdsm.ServerCallback::(wrapper)
Error in wrapper
Traceback (most recent call last):
File /usr/share/vdsm/supervdsmServer.py, line 78, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/supervdsmServer.py, line 352, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 45, in wrapper
return func(*args, **kwargs)
File /usr/share/vdsm/gluster/cli.py, line 430, in volumeInfo
except (etree.ParseError, AttributeError, ValueError):
AttributeError: 'module' object has no attribute 'ParseError'
Thread-1483::ERROR::2013-03-04
16:35:27,481::BindingXMLRPC::932::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 918, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 32, in wrapper
rv = func(*args, **kwargs)
File /usr/share/vdsm/gluster/api.py, line 56, in volumesList
return {'volumes': self.svdsmProxy.glusterVolumeInfo(volumeName)}
File /usr/share/vdsm/supervdsm.py, line 81, in __call__
return callMethod()
File /usr/share/vdsm/supervdsm.py, line 72, in lambda
**kwargs)
File string, line 2, in glusterVolumeInfo
File /usr/lib64/python2.6/multiprocessing/managers.py, line 740,
in _callmethod
raise convert_to_error(kind, result)
AttributeError: 'module' object has no attribute 'ParseError'
Rob,
It seems that a bug in vdsm code is hiding the real issue.
Could you do a
sed -i s/ParseError/ElementTree.ParseError /usr/share/vdsm/gluster/cli.py
restart vdsmd, and retry?
Bala, would you send a patch fixing the ParseError issue (and adding a
unit test that would have caught it on time)?
Regards,
Dan.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
