Bug 1214158 - Failed to register or add RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z
Summary: Failed to register or add RHEV-H 7.1 for RHEV 3.5.1 to RHEV-M 3.4.z
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.5.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.6.0
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard: node
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-22 06:28 UTC by cshao
Modified: 2016-02-10 20:03 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-29 21:45:25 UTC
oVirt Team: Node


Attachments (Terms of Use)
rhevh7.1-failed.png (36.28 KB, image/png)
2015-04-22 06:28 UTC, cshao
no flags Details
rhevh6.6-can-up.png (30.28 KB, image/png)
2015-04-22 06:29 UTC, cshao
no flags Details
failed-rhevm3.4.z.tar.gz (138.51 KB, application/x-gzip)
2015-04-22 06:29 UTC, cshao
no flags Details

Description cshao 2015-04-22 06:28:29 UTC
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.

Comment 1 cshao 2015-04-22 06:29:18 UTC
Created attachment 1017276 [details]
rhevh6.6-can-up.png

Comment 2 cshao 2015-04-22 06:29:51 UTC
Created attachment 1017277 [details]
failed-rhevm3.4.z.tar.gz

Comment 3 Ying Cui 2015-04-22 06:39:43 UTC
Yaniv, could you please to check this bug and weight it whether it is blocker rhev 3.5.1?

Comment 4 Ying Cui 2015-04-22 06:42:08 UTC
This bug block all test cases of rhevh 7.1 for rhev 3.5.1 on rhevm 3.4.z testing.

Comment 5 Fabian Deutsch 2015-04-22 08:23:06 UTC
Please attach the Engine logs as well.

Comment 6 Fabian Deutsch 2015-04-22 08:29:44 UTC
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.

Comment 7 Yaniv Lavi 2015-04-22 08:55:34 UTC
Removing blocker since el7 was tech preview in RHEV 3.4.

Comment 10 Douglas Schilling Landgraf 2015-04-23 13:22:57 UTC
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.

Comment 11 Fabian Deutsch 2015-04-23 13:42:58 UTC
I agree with Douglas, this really looks like a dupe of 1128033.

Comment 12 cshao 2015-04-24 06:33:29 UTC
> > 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

Comment 13 Fabian Deutsch 2015-04-24 06:46:27 UTC
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 ***

Comment 14 Fabian Deutsch 2015-04-24 07:08:02 UTC
Reopening this to let decide if a fix is backported for host-deploy

Comment 15 Alon Bar-Lev 2015-04-24 13:01:45 UTC
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.

Comment 16 Fabian Deutsch 2015-04-24 13:04:40 UTC
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.

Comment 17 Alon Bar-Lev 2015-04-24 13:08:51 UTC
(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.

Comment 18 Fabian Deutsch 2015-04-24 13:14:24 UTC
(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.

Comment 19 Fabian Deutsch 2015-04-24 13:17:16 UTC
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.

Comment 20 Alon Bar-Lev 2015-04-24 15:08:14 UTC
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.

Comment 21 Alon Bar-Lev 2015-04-24 18:25:02 UTC
btw: all what we can ask is to tag ovirt-host-deploy-1.3 into the 3.4 channel.

Comment 22 Fabian Deutsch 2015-04-27 10:01:10 UTC
(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?

Comment 23 Yaniv Lavi 2015-04-29 21:45:25 UTC
Yes


Note You need to log in before you can comment on or make changes to this bug.