Bug 1121414 - Can't add RHEL7.0 host to av10.3 engine via UI.
Summary: Can't add RHEL7.0 host to av10.3 engine via UI.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: 3.5.0
Assignee: Yaniv Bronhaim
QA Contact:
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-20 15:19 UTC by Nikolai Sednev
Modified: 2016-02-10 19:13 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 12:06:49 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
engine.log (5.87 MB, text/x-log)
2014-07-20 15:19 UTC, Nikolai Sednev
no flags Details
Both engine's log and host deployment log. (384.71 KB, application/x-gzip)
2014-07-21 08:30 UTC, Nikolai Sednev
no flags Details
logs from engine (401.02 KB, application/x-gzip)
2014-07-21 13:41 UTC, Nikolai Sednev
no flags Details

Description Nikolai Sednev 2014-07-20 15:19:00 UTC
Created attachment 919404 [details]
engine.log

Description of problem:
Can't add RHEL7.0 host to av10.3 engine via UI.

Version-Release number of selected component (if applicable):
rhevm-3.4.1-0.30.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
1.Image to fresh RHEL7 two hosts and edit their repo files accordingly to https://mojo.redhat.com/docs/DOC-949006
2.Try to attach to av10.3 engine both hosts via UI.
3.Receive errors via UI.

Actual results:
Unable to add RHEL7.0 hosts to engine via UI.

Expected results:
Hosts have to be added to setup via av10.3 engine's UI.

Additional info:
log files attached.

Comment 3 Lior Vernia 2014-07-21 07:48:46 UTC
There seem to be quite a few host installation failures in the engine log, earlier ones having to do with management network, but presumably this was fixed because later failures seem unrelated. Setting whiteboard to infra.

Nikolai, several questions:
1. What happened with the earlier failures and how was that fixed?
2. You mentioned that installation via the GUI fails, does this mean it succeeds via REST?
3. Could you please attach the relevant host deploy log? Usually when an installation fails, the audit log contains entries that point you to an installation log file.

Comment 4 Nikolai Sednev 2014-07-21 08:30:11 UTC
Created attachment 919563 [details]
Both engine's log and host deployment log.

Comment 5 Nikolai Sednev 2014-07-21 08:33:13 UTC
(In reply to Lior Vernia from comment #3)
> There seem to be quite a few host installation failures in the engine log,
> earlier ones having to do with management network, but presumably this was
> fixed because later failures seem unrelated. Setting whiteboard to infra.
> 
> Nikolai, several questions:
> 1. What happened with the earlier failures and how was that fixed?
> 2. You mentioned that installation via the GUI fails, does this mean it
> succeeds via REST?
> 3. Could you please attach the relevant host deploy log? Usually when an
> installation fails, the audit log contains entries that point you to an
> installation log file.

1.They weren't fixed, I did fresh image installation on both hosts and after tried to add both hosts to engine without success via UI.
2.Not relevant to my test cases steps, I'm doing only manual testing, REST isn't part of the test steps, user not working with it using UI.
3.Attached both engine.log and host deployment log.

Comment 6 Barak 2014-07-21 11:53:17 UTC
looking in the host deploy logs,

file /usr/lib64/python2.7/site-packages/vdsm/tool/vdsm-id.pyo conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib64/python2.7/site-packages/vdsm/utils.pyc conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib64/python2.7/site-packages/vdsm/utils.pyo conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib64/python2.7/site-packages/vdsm/vdscli.py conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib64/python2.7/site-packages/vdsm/vdscli.pyc conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib64/python2.7/site-packages/vdsm/vdscli.pyo conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/libexec/vdsm/libvirt_configure.sh conflicts between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and vdsm-python-4.14.11-1.el7ev.x86_64
  file /usr/lib/python2.7/site-packages/zombiereaper/__init__.pyc conflicts between attempted installs of vdsm3-python-zombiereaper-4.14.6-0.el7ev.noarch and vdsm-python-zombiereaper-4.14.11-1.el7ev.noarch
  file /usr/lib/python2.7/site-packages/zombiereaper/__init__.pyo conflicts between attempted installs of vdsm3-python-zombiereaper-4.14.6-0.el7ev.noarch and vdsm-python-zombiereaper-4.14.11-1.el7ev.noarch

2014-07-21 11:24:12 DEBUG otopi.transaction transaction.abort:131 aborting 'Yum Transaction'


I don't know where the vdsm3 package is comming from ... it looks like this image was an experimental one done a long time ago.

Please reinstall from scratch a new RHEL 7 host and retest adding it.

Comment 7 Eyal Edri 2014-07-21 12:00:05 UTC
only repo i can think of is baseurl=http://download.lab.bos.redhat.com/rel-eng/repos/rhevm-3.4-rhel-7-candidate/x86_64/

try removing this repo and use only av10.3/el7 and see if it works.

Comment 8 Nikolai Sednev 2014-07-21 13:13:20 UTC
(In reply to Barak from comment #6)
> looking in the host deploy logs,
> 
> file /usr/lib64/python2.7/site-packages/vdsm/tool/vdsm-id.pyo conflicts
> between attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib64/python2.7/site-packages/vdsm/utils.pyc conflicts between
> attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib64/python2.7/site-packages/vdsm/utils.pyo conflicts between
> attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib64/python2.7/site-packages/vdsm/vdscli.py conflicts between
> attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib64/python2.7/site-packages/vdsm/vdscli.pyc conflicts between
> attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib64/python2.7/site-packages/vdsm/vdscli.pyo conflicts between
> attempted installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/libexec/vdsm/libvirt_configure.sh conflicts between attempted
> installs of vdsm3-python-4.14.6-0.el7ev.x86_64 and
> vdsm-python-4.14.11-1.el7ev.x86_64
>   file /usr/lib/python2.7/site-packages/zombiereaper/__init__.pyc conflicts
> between attempted installs of
> vdsm3-python-zombiereaper-4.14.6-0.el7ev.noarch and
> vdsm-python-zombiereaper-4.14.11-1.el7ev.noarch
>   file /usr/lib/python2.7/site-packages/zombiereaper/__init__.pyo conflicts
> between attempted installs of
> vdsm3-python-zombiereaper-4.14.6-0.el7ev.noarch and
> vdsm-python-zombiereaper-4.14.11-1.el7ev.noarch
> 
> 2014-07-21 11:24:12 DEBUG otopi.transaction transaction.abort:131 aborting
> 'Yum Transaction'
> 
> 
> I don't know where the vdsm3 package is comming from ... it looks like this
> image was an experimental one done a long time ago.
> 
> Please reinstall from scratch a new RHEL 7 host and retest adding it.

No connectivity, it all worked just fine with 3.3.1, no connection to image, they all work fine.

Comment 10 Nikolai Sednev 2014-07-21 13:41:59 UTC
Created attachment 919635 [details]
logs from engine

Comment 11 Barak 2014-07-21 14:18:03 UTC
This time the host deploy failed on systemctl starting the service which is entirely different from the initial log.

I have asked nikolai to install from RHEL 7 GA bits (the version of current repo is not clear ... looks like pre GA bits) and do another deploy.

Comment 13 Nikolai Sednev 2014-07-21 15:24:49 UTC
I also retested on alma04 now without http://download.lab.bos.redhat.com/rel-eng/repos/rhevm-3.4-rhel-7-candidate/x86_64/ on fresh image, works for me, the problem was in wrong repo.

Comment 14 Itamar Heim 2014-07-21 18:41:36 UTC
so this can be closed NOTABUG?

Comment 15 Nikolai Sednev 2014-07-22 10:47:26 UTC
(In reply to Itamar Heim from comment #14)
> so this can be closed NOTABUG?

We may close the bug, but you have to edit the HOW-TO accordingly, many people will fail the whole procedure the same way I failed, may be there is also a hidden bug there, as if I'll enable the broken repository, system still fails to add the host with weird errors...

Please decide on this and make changes to How-To anyway.

Comment 16 Eyal Edri 2014-07-22 10:51:04 UTC
mojo was updated. https://mojo.redhat.com/docs/DOC-962690
i removed the bad repo until rel-eng will fix it.
for now people can use the pkg available from latest_av_dev/el7 repo.

Comment 17 Eyal Edri 2014-07-22 12:06:34 UTC
mojo was updated. https://mojo.redhat.com/docs/DOC-962690
i removed the bad repo until rel-eng will fix it.
for now people can use the pkg available from latest_av_dev/el7 repo.

i also opened a ticket to rel-eng to fix it.:https://engineering.redhat.com/rt/Ticket/Display.html?id=307273

closing the bug.


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