Bug 1640462

Summary: hammer config test is not reliable when the user has defaults set
Product: Red Hat Satellite Reporter: Evgeni Golov <egolov>
Component: Satellite MaintainAssignee: Anurag Patel <apatel>
Status: CLOSED DUPLICATE QA Contact: Katello QA List <katello-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: apatel, inecas, kgaikwad, mbacovsk, nkathole
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-18 07:09:15 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:
Embargoed:

Description Evgeni Golov 2018-10-18 06:46:47 UTC
Description of problem:
foreman-maintain uses `hammer architecture list` to verify the generated hammer configuration (username/password) is valid. however, you can construct a scenario where this command will easily fail, while hammer working properly.

We have a machine, that does have two architectures created, but those are not assigned to the organization (I have no idea how this exactly happened, but it seems possible).

# hammer organization list
---|------------|------------|-------------|------------|------------
ID | TITLE      | NAME       | DESCRIPTION | LABEL      | DESCRIPTION
---|------------|------------|-------------|------------|------------
1  | Adrian Inc | Adrian Inc |             | Adrian_Inc |            
---|------------|------------|-------------|------------|------------

# hammer architecture list
---|-------
ID | NAME  
---|-------
1  | x86_64
2  | i386  
---|-------

# hammer architecture list --organization-id 1
Association not found for organization

The last command obviously exits non-zero, as an error happened (the error is an Exception raised by the API).

Now, the user creates a  ~/.hammer/defaults.yml with the following content:

---
:defaults:
  :organization:
    :value: Adrian Inc

Which now passes "Adrian Inc" to *all* commands. And of course, hammer a l now fails:

# hammer architecture list
Association not found for organization

With this setup, "foreman-maintain health check", and any other command that needs a correctly setup hammer fails:

# foreman-maintain health check
Running preparation steps required to run the next scenarios
================================================================================
Setup hammer: 
Configuring Hammer CLI...
Hammer admin password: <correct password entered>
                                                                      [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"

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

How reproducible:
100%

Steps to Reproduce:
1. have a Satellite with only architectures that are not assigned to an organization
2. use hammer defaults file to force the addition of an organization to all commands
3. run foreman-maintain health check

Actual results:
foreman-maintain health check fails with
Hammer configuration failed: Is the admin password correct? (it was stored in /etc/foreman-maintain/foreman-maintain-hammer.yml)Is the server down?


Expected results:
foreman-maintain health check works

Additional info:

* I am not sure if we should switch to another command (like "hammer user list") or make foreman-maintain ignore hammer configs in ~/.hammer (but then the user could have set the same defaults in /etc/hammer…)

* --whitelist=hammer-setup does not completely help, as other commands try to setup hammer too:
# foreman-maintain health check --whitelist="hammer-setup"
Running preparation steps required to run the next scenarios
================================================================================
Setup hammer:                                                         [SKIPPED]
--------------------------------------------------------------------------------


Running ForemanMaintain::Scenario::FilteredScenario
================================================================================
Check for verifying syntax for ISP DHCP configurations:               [OK]
--------------------------------------------------------------------------------
Check whether all services are running:                               [OK]
--------------------------------------------------------------------------------
Check whether all services are running using hammer ping: 
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?
--------------------------------------------------------------------------------
Check for paused tasks:                                               [OK]
--------------------------------------------------------------------------------
Scenario [ForemanMaintain::Scenario::FilteredScenario] failed.

The following steps ended up in failing state:

  [hammer-ping]

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

Comment 1 Nikhil Kathole 2018-10-18 06:52:00 UTC
Looks Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1632768

Comment 2 Evgeni Golov 2018-10-18 07:09:15 UTC
Nikhil, you're right, that's the same bug, closing as dupe.

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

Comment 3 Martin Bacovsky 2018-10-18 08:45:32 UTC
Evgeni, thanks for the useful information provided.