Bug 1649011 - hammer os list fails with default organization set
Summary: hammer os list fails with default organization set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: API
Version: 6.4.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: 6.10.0
Assignee: satellite6-bugs
QA Contact: Shweta Singh
URL:
Whiteboard:
: 1640617 1667428 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-12 17:15 UTC by Ryan Kimbrell
Modified: 2024-03-25 15:09 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-16 14:08:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 31384 0 Normal Closed hammer os list fails with default organization set 2021-01-31 13:58:36 UTC
Red Hat Knowledge Base (Solution) 3955681 0 None None None 2020-11-12 17:34:00 UTC
Red Hat Product Errata RHSA-2021:4702 0 None None None 2021-11-16 14:08:40 UTC

Description Ryan Kimbrell 2018-11-12 17:15:23 UTC
Description of problem:
When a default organization is set `hammer os list` returns "Association not found for organization. Removing the organization default results in the OS list returning.

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


How reproducible:
Always

Steps to Reproduce:
1. Execute `hammer defaults add --param-name organization_id --param-value 1
2. Execute `hammer os list`

Actual results:
Command returns with "Association not found for organization"

Expected results:
List of operating systems:
ID,TITLE,RELEASE NAME,FAMILY
1,RedHat 7.4,,Redhat

Additional info:
The expected result is returned if the default organization id is removed; however, this results in a change in behavior from 6.2.15, the previous release we used. Alternatively, if there is an argument to pass to hammer to either specify an organization-id of null or to ignore defaults.yml, it would allow us to avoid significantly rewriting our deployment automation.

Comment 1 Martin Bacovsky 2018-11-13 14:30:58 UTC
The organization_id and location_id parameters were addad to API documentation of all API commands to allow setting the org/loc context for the operation. It is similar to Org/Loc selector in the UI. Through the API it is propagated to the hammer options automatically.

The correct behavior should be the API accepts the options and sets the context properly. It is ignored for resources that are not taxable (same as in UI).

Changing the component to API.

As a workaround you can suppress passing the defaults with --organization NIL --location NIL. With Hammer >= 0.15.0 (probably Satellite >= 6.5) there comes ability to turn off defaults from configuration or per command basis with --no-use-defaults.

Comment 2 Martin Bacovsky 2018-11-13 14:39:24 UTC
*** Bug 1640617 has been marked as a duplicate of this bug. ***

Comment 3 Ryan Kimbrell 2018-11-13 15:10:24 UTC
@Martin - Thank you, the NIL option is a successful workaround for me. I also tried specifying --organization-id and --location-id, but that still yields 'Association not found for location'. I also tried creating a new OS via `hammer os create` and specified --organization-id and --location-id in the create command. The newly created OS also does not return when executing `hammer os list --organization-id 1 --location-id 2`. It seems os is not taxable, but I believe that is what you were trying to tell me in Comment 1.

Comment 6 Brad Buckingham 2019-01-21 21:52:19 UTC
*** Bug 1667428 has been marked as a duplicate of this bug. ***

Comment 11 Dylan Gross 2020-11-12 17:14:13 UTC
I have seen other similar bugs marked as duplicates of this one, so unless someone tells me that this is indeed a wholly different bug, I'll focus here.

On Sat6.7.4, if a user will get the same error when attempting to list the settings.

   # hammer settings list
   Association not found for organization

This is precisely because they followed the Hammer CLI guide and set a default organization for the hammer client on an earlier version:  

   https://access.redhat.com/documentation/en-us/red_hat_satellite/6.5/html/hammer_cli_guide/chap-cli_guide-introduction_to_hammer#sect-CLI_Guide-Setting_a_Default_Organization

And it can be worked around by using --no-use-defaults:    # hammer --no-use-defaults settings list

However, without the use of --no-use-defaults, it does trigger an Internal Server Error, logged in ~/.hammer/log/hammer.log

~~~
[ERROR 2020-11-12T17:09:23 API] 500 Internal Server Error
[ERROR 2020-11-12T17:09:23 Exception] Association not found for organization
[ERROR 2020-11-12T17:09:23 Exception] 

RestClient::InternalServerError (500 Internal Server Error):
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/abstract_response.rb:223:in `exception_with_response'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/abstract_response.rb:103:in `return!'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/api.rb:353:in `block in rest_client_call_block'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/request.rb:807:in `process_result'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/request.rb:725:in `block in transmit'
    /opt/rh/rh-ruby25/root/usr/share/ruby/net/http.rb:910:in `start'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/request.rb:715:in `transmit'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/request.rb:145:in `execute'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/request.rb:52:in `execute'
    /opt/theforeman/tfm/root/usr/share/gems/gems/rest-client-2.0.2/lib/restclient/resource.rb:51:in `get'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/api.rb:327:in `call_client'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/api.rb:240:in `http_call'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/api.rb:190:in `call_action'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/api.rb:185:in `call'
    /opt/theforeman/tfm/root/usr/share/gems/gems/apipie-bindings-0.3.0/lib/apipie_bindings/resource.rb:21:in `call'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli-0.19.2.1/lib/hammer_cli/apipie/command.rb:53:in `send_request'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-0.19.6.5/lib/hammer_cli_foreman/commands.rb:188:in `send_request'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-0.19.6.5/lib/hammer_cli_foreman/commands.rb:247:in `send_request'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-0.19.6.5/lib/hammer_cli_foreman/commands.rb:298:in `retrieve_all'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli_foreman-0.19.6.5/lib/hammer_cli_foreman/commands.rb:266:in `execute'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:63:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli-0.19.2.1/lib/hammer_cli/abstract.rb:76:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/subcommand/execution.rb:11:in `execute'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:63:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli-0.19.2.1/lib/hammer_cli/abstract.rb:76:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/subcommand/execution.rb:11:in `execute'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:63:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli-0.19.2.1/lib/hammer_cli/abstract.rb:76:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:132:in `run'
    /opt/theforeman/tfm/root/usr/share/gems/gems/hammer_cli-0.19.2.1/bin/hammer:147:in `<top (required)>'
    /bin/hammer:23:in `load'
    /bin/hammer:23:in `<main>'
~~~

If fixing the "settings list" subcommand call to the API is not within the scope of this BZ, please let me know and I'll open a different Bug.

Comment 12 Yifat Makias 2020-11-24 15:52:48 UTC
Created redmine issue https://projects.theforeman.org/issues/31384 from this bug

Comment 13 Bryan Kearney 2020-11-25 12:02:05 UTC
Upstream bug assigned to ymakias

Comment 14 Bryan Kearney 2020-11-25 12:02:08 UTC
Upstream bug assigned to ymakias

Comment 15 Bryan Kearney 2021-01-31 06:50:48 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/31384 has been resolved.

Comment 17 Shweta Singh 2021-06-07 08:02:31 UTC
Verified "hammer os list" displays list of os system in expected format.

[root@dhcp-2-196 ~]# hammer defaults add --param-name organization_id --param-value 1
Added organization_id default-option with value 1.
[root@dhcp-2-196 ~]# hammer os list
---|------------|--------------|-------
ID | TITLE      | RELEASE NAME | FAMILY
---|------------|--------------|-------
1  | RedHat 7.9 |              | Redhat
---|------------|--------------|-------

Comment 22 errata-xmlrpc 2021-11-16 14:08:27 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 (Moderate: Satellite 6.10 Release), 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-2021:4702


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