Bug 2242824 - Can't use consumer_type with the redhat_subscription module and dbus
Summary: Can't use consumer_type with the redhat_subscription module and dbus
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ansible
Version: 38
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Pino Toscano
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-10-09 08:36 UTC by Radek Bíba
Modified: 2023-10-19 01:11 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-10-10 19:43:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ansible-collections community.general pull 7378 0 None Merged redhat_subscription: fix D-Bus option for consumer type on older distros 2023-10-11 11:31:37 UTC

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.


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