Bug 1640230 - Upgrade from RHSAT 6.3 to 6.4 fails if .hammer directory 'in the way'
Summary: Upgrade from RHSAT 6.3 to 6.4 fails if .hammer directory 'in the way'
Keywords:
Status: CLOSED DUPLICATE of bug 1632768
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Upgrades
Version: 6.4
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-17 15:25 UTC by Oliver Falk
Modified: 2021-08-30 12:26 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-18 06:15:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3659041 0 None None None 2018-10-18 06:13:22 UTC

Description Oliver Falk 2018-10-17 15:25:14 UTC
Description of problem:
Customer opened a case, mentioning that if /rooot/.hammer/cgi_config.yml is there, the upgrade fails with the following error:


Setup hammer: Configuring Hammer CLI...
Hammer admin password:                                                                       [FAIL]
Hammer configuration failed: Is the admin password correct? (it was stored in /etc/foreman-maintain/foreman-maintain-hammer.yml)Is the server down?
--------------------------------------------------------------------------------
Scenario [preparation steps required to run the next scenarios] failed.

The following steps ended up in failing state:

  [hammer-setup]

Resolve the failed steps and rerun
the command. In case the failures are false positives,
use --whitelist="hammer-setup"


katello-service restart failed! Check the output for error!
Upgrade step restart_services failed. Check logs for more information.
                                      [FAIL]

After quite a lot of testing the upgrade from 6.3.4 to 6.4 on my side (on a pretty fresh RHSAT6.3 install) and asking the customer what he did to fix it, I had to find out that I have to remove the whole /root/.hammer directory in order for the upgrade to go through.


Version-Release number of selected component (if applicable):
RHSAT 6.4
rubygem-foreman_maintain-0.2.11-1.el7sat.noarch


How reproducible:
Always for me if .hammer/ was there.


Steps to Reproduce:
1. Install RHSAT 6.3
2. Try to upgrade to RHSAT 6.4

Actual results:
Upgrade doesn't finish successfully.


Expected results:
Upgrade should finish successfully.


Additional info:
I'm not sure what particular file in /root/.hammer causes this to happen. Only removing cli_config.yml did NOT help. I did not create that files manually, something in RHSAT 6.3 must have created that. So this could affect more users. Eventually we want to introduce an additional step in the documentation, asking the user to remove that directory?

Comment 7 Martijn ten Heuvel 2018-10-17 19:14:33 UTC
Extra remarks after some discussions in the Rocketchat channel:

My satellite is a 6.2.2 (or whatever) upgrade to 6.2.x > 6.3.0 > 6.3.x > 6.3.4 > 6.4.0.

In my /root/.hammer I had the following files:
[root@satellite62 .hammerold]# tree
.
├── cli_config.yml
├── cli.modules.d
│   └── foreman.yml
├── defaults.yml
└── log
    └── hammer.log

Removing the defaults.yml seems to resolve this, but I do have to test using 'foreman-maintain upgrade run --target-version 6.4.z --whitelist="disk-performance,installer-upgrade"' over and over.

I ran the upgrade command with the defaults.yml in place, it failed, same message as BZ. Then, I renamed the defaults.yml file to kaput.yml and everything worked like a charm.

Contents of the file:
[root@satellite62 .hammer]# cat kaput.yml 
---
:defaults:
  :organization_id:
    :value: '1'

The cli_config.yaml is in place as it was when I initially ran the update, contents like this:
[root@satellite62 .hammer]# cat cli_config.yml 
:foreman:  
  :host: 'https://satellite62.mobile.mth/'  
  :username: 'admin'  
  :password: 'password'  
  :request_timeout: -1

Comment 8 Mike McCune 2018-10-17 19:25:06 UTC
it is likely defaults.yml causing the problem, that is being tracked here:

https://bugzilla.redhat.com/show_bug.cgi?id=1632768

if that is the case, we can close this as a dupe of the above

Comment 12 Simon Reber 2018-10-18 06:15:32 UTC

*** This bug has been marked as a duplicate of bug 1632768 ***


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