Created attachment 1017275 [details] rhevh7.1-failed.png Description of problem: Failed to register RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z ========================================================================= java.io.IOException: Command returned failure code 1 during SSH session root@... Version-Release number of selected component (if applicable): rhev-hypervisor7-7.1-20150420.0.el7ev ovirt-node-3.2.2-3.el7.noarch vdsm-4.16.13.1-1.el7ev.x86_64 RHEV-M: AV14.3 (3.4.5-0.3.el6ev) How reproducible: 100% Steps to Reproduce: 1. Install rhev-hypervisor7-7.1-20150420.0.el7ev. 2. Register RHEV-H to RHEVM 3.4.z build(compatibility version 3.4). 3. Or add rhevh via rhevm side. 4. Check the result. Actual results: 1. Failed to register RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z 2. Register and add rhevh via rhevm both are failed. Expected results: Register RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z can succeed. Additional info: Register RHEV-H 6.6 for RHEV 3.5.1 (rhev-hypervisor6-6.6-20150421.0) to RHEV-M 3.4.z can succeed.
Created attachment 1017276 [details] rhevh6.6-can-up.png
Created attachment 1017277 [details] failed-rhevm3.4.z.tar.gz
Yaniv, could you please to check this bug and weight it whether it is blocker rhev 3.5.1?
This bug block all test cases of rhevh 7.1 for rhev 3.5.1 on rhevm 3.4.z testing.
Please attach the Engine logs as well.
Okay, it is included in the same tarball. From the host deploy logs: 2015-04-22 05:43:06 DEBUG otopi.context context._executeMethod:138 Stage closeup METHOD otopi.plugins.ovirt_host_deploy.node.persist.Plugin._closeup 2015-04-22 05:43:06 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/tmp/ovirt-dv7eDHCy0i/pythonlib/otopi/context.py", line 142, in _executeMethod method['method']() File "/tmp/ovirt-dv7eDHCy0i/otopi-plugins/ovirt-host-deploy/node/persist.py", line 51, in _closeup from ovirtnode import ovirtfunctions File "/usr/lib/python2.7/site-packages/ovirtnode/ovirtfunctions.py", line 34, in <module> ImportError: could not import gobject (could not find _PyGObject_API object) 2015-04-22 05:43:06 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Closing up': could not import gobject (could not find _PyGObject_API object) It seems to be an python import problem, when importing ovirtfunctions.
Removing blocker since el7 was tech preview in RHEV 3.4.
Hi shaochen, (In reply to Fabian Deutsch from comment #6) > Okay, it is included in the same tarball. > > From the host deploy logs: > > 2015-04-22 05:43:06 DEBUG otopi.context context._executeMethod:138 Stage > closeup METHOD otopi.plugins.ovirt_host_deploy.node.persist.Plugin._closeup > 2015-04-22 05:43:06 DEBUG otopi.context context._executeMethod:152 method > exception > Traceback (most recent call last): > File "/tmp/ovirt-dv7eDHCy0i/pythonlib/otopi/context.py", line 142, in > _executeMethod > method['method']() > File > "/tmp/ovirt-dv7eDHCy0i/otopi-plugins/ovirt-host-deploy/node/persist.py", > line 51, in _closeup > from ovirtnode import ovirtfunctions > File "/usr/lib/python2.7/site-packages/ovirtnode/ovirtfunctions.py", line > 34, in <module> > ImportError: could not import gobject (could not find _PyGObject_API object) > 2015-04-22 05:43:06 ERROR otopi.context context._executeMethod:161 Failed to > execute stage 'Closing up': could not import gobject (could not find > _PyGObject_API object) > > > It seems to be an python import problem, when importing ovirtfunctions. Could you please update the ovirt-host-deploy in the RHEV-M machine and re-test? To my eyes, this one is a dup of bz#1128033.
I agree with Douglas, this really looks like a dupe of 1128033.
> > It seems to be an python import problem, when importing ovirtfunctions. > > Could you please update the ovirt-host-deploy in the RHEV-M machine and > re-test? > To my eyes, this one is a dup of bz#1128033. Hi dougsland and fabiand, Good eye! after update ovirt-host-deploy from 1.2.5-1 to 1.3.0-2.el6ev, register and add RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z both successful. Test version: rhev-hypervisor7-7.1-20150420.0.el7ev ovirt-node-3.2.2-3.el7.noarch vdsm-4.16.13.1-1.el7ev.x86_64 RHEV-M: AV14.3 (3.4.5-0.3.el6ev) ovirt-host-deploy-1.3.0-2.el6ev
Good catch Douglas, and thanks for the quick checking Chen. Closed as a dupe according to comment 10 and 12. *** This bug has been marked as a duplicate of bug 1128033 ***
Reopening this to let decide if a fix is backported for host-deploy
this is not host-deploy issue but ovirtfunctions not functional or not backward compatible, same will happen to older engines as well. please fix the issue in node or close.
It would be nice if host-deploy could switch over to use ovirt-node.fs.Config().persist() and .unpersist() instead of ovirtfunctions. Are you willing to use that API? Otherwise we can close it as won't fix.
(In reply to Fabian Deutsch from comment #16) > It would be nice if host-deploy could switch over to use > ovirt-node.fs.Config().persist() and .unpersist() instead of ovirtfunctions. > > Are you willing to use that API? Otherwise we can close it as won't fix. it does not enable you to break backward compatibility. newer host-deploy is working as intended per bug#1128033, as you broke the interface older host deploy 3.0->3.4 will not be able to deploy nodes. pushing a fix to all past manager versions instead of resolving the issue at node side is incorrect. it is ok to use newer api in newer versions if it have value, but if you expect to support older managers, you cannot just break interfaces. if you do not wish to be able to use this node with older engines please close this and issue a clear release notes.
(In reply to Alon Bar-Lev from comment #17) … > it does not enable you to break backward compatibility. > > newer host-deploy is working as intended per bug#1128033, as you broke the > interface older host deploy 3.0->3.4 will not be able to deploy nodes. We did not break it, it is a bug which only surfaces when some imports are combined. And we can not fix the import problems in ovirtfunctions, because then we _would_ berak backwards compatibility. The semantics of ovirtnode.* and ovirt.node.fs.Config().* are the same, just the synatx is different. > pushing a fix to all past manager versions instead of resolving the issue at > node side is incorrect. > > it is ok to use newer api in newer versions if it have value, but if you > expect to support older managers, you cannot just break interfaces. > > if you do not wish to be able to use this node with older engines please > close this and issue a clear release notes. Agreed.
It's actually a different problem than I thought. It is a problem with mixing pygobject and gobject gi: 2015-04-22 05:43:06 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/tmp/ovirt-dv7eDHCy0i/pythonlib/otopi/context.py", line 142, in _executeMethod method['method']() File "/tmp/ovirt-dv7eDHCy0i/otopi-plugins/ovirt-host-deploy/node/persist.py", line 51, in _closeup from ovirtnode import ovirtfunctions File "/usr/lib/python2.7/site-packages/ovirtnode/ovirtfunctions.py", line 34, in <module> ImportError: could not import gobject (could not find _PyGObject_API object) This can result when some library whgich is also used by host-deploy imports gobject gi.
it worked at one version then does not, a solution should be provided if we want it to work. host-deploy does not import anything by its own all it imports out of python are the following, except of ovirt-node stuff all are well behaved. from distutils.version import LooseVersion from rpmUtils.miscutils import compareEVR from M2Crypto import X509, BIO, RSA,EVP from ovirtnode import ovirtfunctions from ovirt.node.utils.fs import Config so I am unsure where the problem is in ovirtfunctions. you could provide the same service by adding a stub that calls the new api, or query the modules that are loaded and apply some workaround if ovirtfunctions is special, for example import whatever you need within specific function and not at global scope.
btw: all what we can ask is to tag ovirt-host-deploy-1.3 into the 3.4 channel.
(In reply to Alon Bar-Lev from comment #20) > it worked at one version then does not, a solution should be provided if we > want it to work. host-deploy does not import anything by its own all it > imports out of python are the following, except of ovirt-node stuff all are > well behaved. > > from distutils.version import LooseVersion > from rpmUtils.miscutils import compareEVR > from M2Crypto import X509, BIO, RSA,EVP > from ovirtnode import ovirtfunctions > from ovirt.node.utils.fs import Config IIUIC the only functions you use from ovirtfunctions is around persistence. And the Config class from utils.fs is reimplementing that persistence functionality, because we know that importing ovirtfunctions is doing bad stuff. Maybe on of the host-deploy plugins is now indirectly importing gobject gi. > so I am unsure where the problem is in ovirtfunctions. you could provide the > same service by adding a stub that calls the new api, or query the modules > that are loaded and apply some workaround if ovirtfunctions is special, for > example import whatever you need within specific function and not at global > scope. There are many assumptions in ovirtfunctions and the modules importing ovirtfunctions that we do not want to change this. Yaniv, are you fine with closing this bug as WONTFIX?
Yes