Bug 2242824

Summary: Can't use consumer_type with the redhat_subscription module and dbus
Product: [Fedora] Fedora Reporter: Radek Bíba <rbiba>
Component: ansibleAssignee: Pino Toscano <ptoscano>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: a.badger, kevin, maxwell, moi, patrick, ptoscano
Target Milestone: ---Keywords: Upstream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-10-10 19:43:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Radek Bíba 2023-10-09 08:36:49 UTC
I want to call the redhat_subscription module with consumer_type: rhui, but the playbook fails. With the default verbosity, the output reads:

TASK [rhui_nodes : register with RHSM] *******************************************************************************************************************************************************
fatal: [ec2-52-51-130-154.eu-west-1.compute.amazonaws.com]: FAILED! => {"changed": false, "msg": "Failed to register with 'None': com.redhat.RHSM1.Error: {\"exception\": \"ValidationError\", \"severity\": \"error\", \"message\": \"Unknown arguments: dict_keys(['consumer_type'])\"}"}

With -vvv:

The full traceback is:
  File "/tmp/ansible_redhat_subscription_payload_nwgy781h/ansible_redhat_subscription_payload.zip/ansible_collections/community/general/plugins/modules/redhat_subscription.py", line 1205, in main
  File "/tmp/ansible_redhat_subscription_payload_nwgy781h/ansible_redhat_subscription_payload.zip/ansible_collections/community/general/plugins/modules/redhat_subscription.py", line 480, in register
  File "/tmp/ansible_redhat_subscription_payload_nwgy781h/ansible_redhat_subscription_payload.zip/ansible_collections/community/general/plugins/modules/redhat_subscription.py", line 683, in _register_using_dbus
  File "/usr/lib64/python3.6/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
fatal: [ec2-52-51-130-154.eu-west-1.compute.amazonaws.com]: FAILED! => {
    "changed": false,
    "invocation": {
        "module_args": {
            "activationkey": null,
            "auto_attach": null,
            "consumer_id": null,
            "consumer_name": null,
            "consumer_type": "rhui",
            "environment": null,
            "force_register": false,
            "org_id": null,
            "password": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
            "pool": "^Red Hat Update Infrastructure",
            "pool_ids": [],
            "release": null,
            "rhsm_baseurl": null,
            "rhsm_repo_ca_cert": null,
            "server_hostname": null,
            "server_insecure": null,
            "server_port": null,
            "server_prefix": null,
            "server_proxy_hostname": null,
            "server_proxy_password": null,
            "server_proxy_port": null,
            "server_proxy_scheme": null,
            "server_proxy_user": null,
            "state": "present",
            "syspurpose": null,
            "token": null,
            "username": "rbiba_ccsp"
        }
    },
    "msg": "Failed to register with 'None': com.redhat.RHSM1.Error: {\"exception\": \"ValidationError\", \"severity\": \"error\", \"message\": \"Unknown arguments: dict_keys(['consumer_type'])\"}"
}

The target node's OS is RHEL 8.

It works when I edit the module to avoid dbus; basically I tried adding return False to _can_connect_to_dbus in /usr/lib/python3.11/site-packages/ansible_collections/community/general/plugins/modules/redhat_subscription.py, and it allowed the system to get registered as expected.

Here's a relevant part from the rhsm.log file on the target system before the workaround:

2023-10-09 07:58:04,952 [ERROR] rhsm-service:16665:MainThread @util.py:41 - Unknown arguments: dict_keys(['consumer_type'])
Traceback (most recent call last):
  File "/usr/lib64/python3.6/site-packages/rhsmlib/dbus/util.py", line 38, in dbus_handle_exceptions
    ret = func(*args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/rhsmlib/dbus/objects/register.py", line 331, in Register
    consumer = register_service.register(org, **options)
  File "/usr/lib64/python3.6/site-packages/rhsmlib/services/register.py", line 45, in register
    raise exceptions.ValidationError(_("Unknown arguments: %s") % kwargs.keys())
rhsmlib.services.exceptions.ValidationError: Unknown arguments: dict_keys(['consumer_type'])


Reproducible: Always

Steps to Reproduce:
1. Have a playbook with the redhat_subscription module as follows:

    state: present
    username: ...
    password: ...
    consumer_type: rhui
    pool: '^Red Hat Update Infrastructure'

2. Run it.
Actual Results:  
Error, as described in detail above.

Expected Results:  
It works.

Comment 1 Radek Bíba 2023-10-09 14:55:52 UTC
OK I took a closer look later this afternoon and here's the fix for this bug:

--- /usr/lib/python3.11/site-packages/ansible_collections/community/general/plugins/modules/redhat_subscription.py.consumer_type	2023-10-09 16:38:08.951778928 +0200
+++ /usr/lib/python3.11/site-packages/ansible_collections/community/general/plugins/modules/redhat_subscription.py	2023-10-09 16:38:26.456963195 +0200
@@ -587,7 +587,7 @@
 
         register_opts = {}
         if consumer_type:
-            register_opts['consumer_type'] = consumer_type
+            register_opts['type'] = consumer_type
         if consumer_name:
             register_opts['name'] = consumer_name
         if consumer_id:

Comment 2 Radek Bíba 2023-10-09 16:19:24 UTC
Oh it's a little more complicated. register_opts['type'] must be used on RHEL 8 (which is the only version where RHUI is currently supported and where this consumer type makes sense) and in theory also on RHEL 7, but register_opts['consumer_type'] actually is the right thing to do if the target node is running RHEL 9. So the patch will have to take distro_id/distro_version into account as well, like:

        if consumer_type:
            if distro_id == 'rhel' and distro_version[0] <= 8:
                register_opts['type'] = consumer_type
            else:   
                register_opts['consumer_type'] = consumer_type

(if the consumer type makes sense outside RHEL at all)

Comment 3 Maxwell G 2023-10-09 17:30:23 UTC
Pino, do you have any insight here? I know you have been working on the redhat_subscription module upstream as of late. The reporter did not include the version of ansible that they have installed, but assuming it's the current ansible-7.7.0 in the F38 repos, the plugin is taken from community.general 6.6.2 (https://github.com/ansible-collections/community.general/blob/6.6.2/plugins/modules/redhat_subscription.py).

Comment 4 Pino Toscano 2023-10-10 05:26:38 UTC
(In reply to Radek Bíba from comment #2)
> Oh it's a little more complicated. register_opts['type'] must be used on
> RHEL 8 (which is the only version where RHUI is currently supported and
> where this consumer type makes sense) and in theory also on RHEL 7, but
> register_opts['consumer_type'] actually is the right thing to do if the
> target node is running RHEL 9.

OMG, yet another incompatibility across versions present -- I was not aware of it.
The 'type' parameter was renamed to 'consumer_type' to avoid a conflict with the builtin Python function, and this is present in subscription-manager >= 1.29.32. This version is available since RHEL 9.2 only, so...

> So the patch will have to take
> distro_id/distro_version into account as well, like:
> 
>         if consumer_type:
>             if distro_id == 'rhel' and distro_version[0] <= 8:
>                 register_opts['type'] = consumer_type
>             else:   
>                 register_opts['consumer_type'] = consumer_type

... this is mostly correct, and the distro check will need to be more complex.

> (if the consumer type makes sense outside RHEL at all)

Yes, I do not think it has anything to do with the distro, it is simply an attribute of a system.

(In reply to Maxwell G from comment #3)
> I know you have been working on the redhat_subscription module upstream as of late.

I'm the maintainer of this module, yes.

> The reporter did not include
> the version of ansible that they have installed, but assuming it's the
> current ansible-7.7.0 in the F38 repos, the plugin is taken from
> community.general 6.6.2

Hm or maybe it is installed from the separate ansible-collection-community-general package, currently version 6.6.0-1 in f38.

I massaged a bit the code needed for this, modelling it according to what done for other bits in the module:
https://github.com/ansible-collections/community.general/pull/7378
would you both please give it a look/try?

Comment 5 Radek Bíba 2023-10-10 06:22:32 UTC
Oops, sorry about the missing information about the affected version. There was no template in the bug creation form to enter this data and I forgot. It's the stock package from Fedora 38, ansible-7.7.0-1.fc38.noarch.

I'll take a closer look at the PR today. Many thanks for the quick response!

Comment 6 Radek Bíba 2023-10-10 08:13:39 UTC
I'm getting:

fatal: [ec2-99-81-46-143.eu-west-1.compute.amazonaws.com]: FAILED! => {"changed": false, "msg": "Failed to register with 'None': Don't know which D-Bus type to use to encode type \"NoneType\""}

from RHEL 7, 8, and 9(.2).

Comment 7 Radek Bíba 2023-10-10 08:20:19 UTC
Oh, I guess you meant:

            register_opts[consumer_type_key] = consumer_type

rather than:

            register_opts[consumer_type_key] = environment

in https://github.com/ansible-collections/community.general/pull/7378/files#diff-b354707cac5ffce6845c0ab9c2070a9063747f9a41d64c284194ce5ca2d982c3R602 .

Comment 8 Pino Toscano 2023-10-10 08:48:56 UTC
(In reply to Radek Bíba from comment #7)
> Oh, I guess you meant:
> 
>             register_opts[consumer_type_key] = consumer_type
> 
> rather than:
> 
>             register_opts[consumer_type_key] = environment

Oops, apologies, fixed, thanks.

(AKA: why you should never do patches before 8 AM)

Comment 9 Radek Bíba 2023-10-10 09:15:52 UTC
Thank you, Pino. It works.

Comment 10 Pino Toscano 2023-10-10 10:11:24 UTC
(In reply to Radek Bíba from comment #9)
> Thank you, Pino. It works.

Thanks for testing! Would you please comment on the github PR?

Comment 11 Radek Bíba 2023-10-10 12:30:22 UTC
Absolutely. Comment added.

Comment 12 Fedora Update System 2023-10-10 19:25:07 UTC
FEDORA-2023-954e1db855 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-954e1db855

Comment 13 Maxwell G 2023-10-10 19:26:30 UTC
I backported the patch to ansible-collection-community-general. You can install that package alongside ansible and the module loader will pick up the updated redhat_subscription module from there. Is that okay? We avoid patching content within the ansible package where possible.

Comment 14 Fedora Update System 2023-10-10 19:42:22 UTC
FEDORA-2023-e25f3ce991 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e25f3ce991

Comment 15 Fedora Update System 2023-10-10 19:43:13 UTC
FEDORA-2023-e25f3ce991 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2023-10-11 02:37:24 UTC
FEDORA-2023-954e1db855 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-954e1db855`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-954e1db855

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Radek Bíba 2023-10-11 06:27:03 UTC
(In reply to Maxwell G from comment #13)
> I backported the patch to ansible-collection-community-general. You can
> install that package alongside ansible and the module loader will pick up
> the updated redhat_subscription module from there. Is that okay? We avoid
> patching content within the ansible package where possible.

No problem at all. I reverted the local changes and installed ansible-collection-community-general-6.6.6-1.fc38.noarch from updates-testing, and it works. Thank you, Maxwell.

Comment 18 Fedora Update System 2023-10-19 01:11:34 UTC
FEDORA-2023-954e1db855 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.