Bug 1303144

Summary: Failed dependencies on openssl and gnutls causes undercloud installation failure
Product: Red Hat OpenStack Reporter: Raoul Scarazzini <rscarazz>
Component: rhosp-directorAssignee: Hugh Brock <hbrock>
Status: CLOSED WORKSFORME QA Contact: Shai Revivo <srevivo>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.0 (Liberty)CC: abeekhof, dtantsur, fdinitto, jcoufal, mburns, michele, rhel-osp-director-maint, royoung, rscarazz
Target Milestone: ---   
Target Release: 8.0 (Liberty)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-14 15:04:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Raoul Scarazzini 2016-01-29 16:40:09 UTC
Description of problem:

Installation of the undercloud in an ospd8 environment it's impossible to dependency failures.
The setup was made as usual:

# sudo rm -rf /etc/yum.repos.d/*
# sudo yum localinstall -y http://rhos-release.virt.bos.redhat.com/repos/rhos-release/rhos-release-latest.noarch.rpm
# sudo rhos-release -P 8-director
# sudo yum update -y
# sudo yum install -y python-tripleoclient

How reproducible:

Always if you use openstack-tripleo-heat-templates-0.8.7-2.el7ost.noarch.

Steps to Reproduce:
1. Launch

# openstack undercloud install

Actual results:

...
...
Error: Package: 1:openssl-devel-1.0.1e-51.el7_2.1.x86_64 (rhelosp-rhel-7-z)
           Requires: openssl-libs(x86-64) = 1:1.0.1e-51.el7_2.1
           Installed: 1:openssl-libs-1.0.1e-51.el7_2.2.x86_64
(@rhel-7-server)
               openssl-libs(x86-64) = 1:1.0.1e-51.el7_2.2
           Available: 1:openssl-libs-1.0.1e-42.el7_1.9.x86_64
(rhelosp-rhel-7-server)
               openssl-libs(x86-64) = 1:1.0.1e-42.el7_1.9
           Available: 1:openssl-libs-1.0.1e-51.el7_2.1.x86_64
(rhelosp-rhel-7-z)
               openssl-libs(x86-64) = 1:1.0.1e-51.el7_2.1
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
INFO: 2016-01-27 06:53:58,311 -- ############### End stdout/stderr
logging ###############
ERROR: 2016-01-27 06:53:58,312 --     Hook FAILED.
ERROR: 2016-01-27 06:53:58,312 -- Failed running command
['dib-run-parts', u'/tmp/tmp2k_UAR/install.d']
  File "/usr/lib/python2.7/site-packages/instack/main.py", line 163, in main
    em.run()
  File "/usr/lib/python2.7/site-packages/instack/runner.py", line 79, in run
    self.run_hook(hook)
  File "/usr/lib/python2.7/site-packages/instack/runner.py", line 174,
in run_hook
    raise Exception("Failed running command %s" % command)
ERROR: 2016-01-27 06:53:58,312 -- None
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File
"/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
line 555, in install
    _run_instack(instack_env)
  File
"/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
line 487, in _run_instack
    _run_live_command(args, instack_env, 'instack')
  File
"/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py",
line 325, in _run_live_command
    raise RuntimeError('%s failed. See log for details.' % name)
RuntimeError: instack failed. See log for details.
Command 'instack-install-undercloud' returned non-zero exit status 1
Version-Release number of selected component (if applicable):

And after fixing this...

...
...
Error: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-compute' returned 1: Error: Package: gnutls-dane-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
           Requires: gnutls(x86-64) = 3.3.8-12.el7_1.1
           Installed: gnutls-3.3.8-14.el7_2.x86_64 (@rhel-7-server)
               gnutls(x86-64) = 3.3.8-14.el7_2
           Available: gnutls-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
               gnutls(x86-64) = 3.3.8-12.el7_1.1
Error: Package: gnutls-utils-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
           Requires: gnutls(x86-64) = 3.3.8-12.el7_1.1
           Installed: gnutls-3.3.8-14.el7_2.x86_64 (@rhel-7-server)
               gnutls(x86-64) = 3.3.8-14.el7_2
           Available: gnutls-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
               gnutls(x86-64) = 3.3.8-12.el7_1.1
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
Error: /Stage[main]/Nova::Compute/Nova::Generic_service[compute]/Package[nova-compute]/ensure: change from absent to present failed: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nov
a-compute' returned 1: Error: Package: gnutls-dane-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
           Requires: gnutls(x86-64) = 3.3.8-12.el7_1.1
           Installed: gnutls-3.3.8-14.el7_2.x86_64 (@rhel-7-server)
               gnutls(x86-64) = 3.3.8-14.el7_2
           Available: gnutls-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
               gnutls(x86-64) = 3.3.8-12.el7_1.1
Error: Package: gnutls-utils-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
           Requires: gnutls(x86-64) = 3.3.8-12.el7_1.1
           Installed: gnutls-3.3.8-14.el7_2.x86_64 (@rhel-7-server)
               gnutls(x86-64) = 3.3.8-14.el7_2
           Available: gnutls-3.3.8-12.el7_1.1.x86_64 (rhelosp-rhel-7-server)
               gnutls(x86-64) = 3.3.8-12.el7_1.1
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Expected results:

Success.

Additional info:

The workaround to fix this is to downgrade the packages:

# sudo yum downgrade openssl-libs-1.0.1e-42.el7_1.9.x86_64 openssl-1.0.1e-42.el7_1.9.x86_64
# sudo yum downgrade gnutls-3.3.8-12.el7_1.1

And then relaunch the installation which finishes with success.

Comment 3 Mike Burns 2016-04-07 21:07:13 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 5 Dmitry Tantsur 2016-10-14 14:50:16 UTC
Hi! Is this problem still reproducible?

Comment 6 Raoul Scarazzini 2016-10-14 14:55:45 UTC
Hi Dmitry,
no, it is not.

Comment 7 Dmitry Tantsur 2016-10-14 15:04:52 UTC
Thanks!