Bug 1577247

Summary: ansible-tower-setup installs several new non-Red Hat yum repositories
Product: Red Hat CloudForms Management Engine Reporter: Peter McGowan <pmcgowan>
Component: ApplianceAssignee: Satoe Imaishi <simaishi>
Status: CLOSED ERRATA QA Contact: Dmitry Misharov <dmisharo>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.9.0CC: abellott, brant.evans, cbolz, cpelland, dmisharo, fdewaley, gmainwar, greartes, jclaretm, obarenbo, rspagnol, smcdonal
Target Milestone: GA   
Target Release: 5.9.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.9.3.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-12 13:14:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1561041    

Description Peter McGowan 2018-05-11 14:34:48 UTC
Description of problem:
The installation of ansible-tower-setup in a CFME 5.9.2 upgrade installs several non-Red Hat yum repositories such as epel-7, ansible-el7, pgdg-96-centos and jlaska-rabbitmq. If a subsequent yum update is performed then packages will be installed from these repositories, overwriting the correct and tested packages from the cf-me repository.

Version-Release number of selected component (if applicable):
5.9.2.4

How reproducible:
Every time

Steps to Reproduce:
1. Update a CFME 5.9.1 appliance to CFME 5.9.2
2. Perform a 'yum repolist', and notice the extra repositories
3. Perform a 'yum update' and notice that inappropriate packages such as 2.5.2-1.el7 would be installed

Expected results:
Additional repositories should not be installed.

Additional info:

Comment 2 Peter McGowan 2018-05-11 14:36:28 UTC
I meant to write "Ansible 2.5.2-1.el7 would be installed"

Comment 4 Graham Mainwaring 2018-05-11 15:16:16 UTC
This is the expected behavior of the Tower setup playbooks. CFME is supposed to pass skip-tags arguments to setup.sh to suppress this. Can we verify that those arguments are being passed?

Comment 5 Graham Mainwaring 2018-05-11 15:16:17 UTC
This is the expected behavior of the Tower setup playbooks. CFME is supposed to pass skip-tags arguments to setup.sh to suppress this. Can we verify that those arguments are being passed?

Comment 6 Graham Mainwaring 2018-05-11 15:16:36 UTC
This is the expected behavior of the Tower setup playbooks. CFME is supposed to pass skip-tags arguments to setup.sh to suppress this. Can we verify that those arguments are being passed?

Comment 7 Reartes Guillermo 2018-05-11 15:20:07 UTC
Hi,

Please review if a solution doc is needed for cfme appliances behind a Satellite. Since those repositories will not be available.

Cheers.

Comment 8 Shane McDonald 2018-05-11 15:46:57 UTC
In Tower 3.2.0 the installer was refactored and the tasks that install the yum repos were moved into a separate Ansible role.

From an old Slack conversation I can see that the argument currently being passed by CFME to the installer is: --skip-tags=packages.

I believe the solution is to apply the same --skip-tags tag CFME is using where this new role is included in the Tower installer.

Comment 10 Graham Mainwaring 2018-05-15 15:28:59 UTC
We have updated the Tower installer so that it will correctly respect --skip-tags=packages again.  The fix will be in Tower 3.1.7/3.2.5, which will be going out today or tomorrow.

Comment 11 Graham Mainwaring 2018-05-22 19:17:56 UTC
We have resolved build issues that prevented us from getting 3.1.7/3.2.5 in brew. 3.1.7 now exists and 3.2.5 will be in progress shortly. These versions should properly respect --skip-tags=packages again.

Comment 13 Satoe Imaishi 2018-06-07 02:13:10 UTC
*** Bug 1582757 has been marked as a duplicate of this bug. ***

Comment 14 Dmitry Misharov 2018-06-12 08:55:54 UTC
Fixed and verified in 5.9.3.1.20180606184006_8d120c0. ansible installer respects --skip-tags=packages. No additional repos is not added.

Comment 16 errata-xmlrpc 2018-07-12 13:14:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2184