Closed scott-vick closed 1 month ago
I wonder if it would be possible to use the new rhel-system-roles.rhc for this, though not certain about the state of compatibility with RHEL 7.9. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/automating_system_administration_by_using_rhel_system_roles/using-the-rhc-system-role-to-register-the-system_automating-system-administration-by-using-rhel-system-roles
It could allow a clean definition like the following, especially for the new Insights Tasks for upgrades in the works.
---
- hosts: all
become: true
remote_user: ansible
vars:
rhc_organization: "{{ devsub_orgid }}"
rhc_auth:
activation_keys:
keys:
- "{{ devsub_act_key }}"
rhc_insights:
state: present
remediation: true
tags:
group: demo
location: lab
description:
- "{{ ansible_distribution }}"
- demo
roles:
- role: redhat.rhel_system_roles.rhc
# - role: fedora.linux_system_roles.rhc
is this still an issue?
I have not seen it of late. I think the issue we were seeing was more to do with the customers Satellite infrastructure.
I have observed a very intermittent issue with the tasks that utilize the ansible.builtin.rhsm_subscription module in the leapp-upgrade and leapp-post-upgrade roles.
Even though the tasks are set to use the "force" flag when registering to the various leapp activation keys, the task will still fail and throw the error about the target already being registered and to use the force flag.