sap_*_preconfigure: package_facts

[sean-freeman]

sap_*_preconfigure Ansible Role's may fail upon first usage of Ansible Module package_facts when python3-rpm OS Package is not installed for the System Python.

Specifically noted for SLES in the Ansible Module in-line documentation but should be considered for RHEL also as an administrator may alter any OS Image.

- name: Ensure OS Package for Python Lib of rpm bindings is enabled for System Python - RHEL
  ansible.builtin.command: yum install --assumeyes python3-rpm
  when: ansible_os_family == "RedHat"

- name: Ensure OS Package for Python Lib of rpm bindings is enabled for System Python - SLES
  ansible.builtin.command: zypper install --no-confirm --auto-agree-with-licenses python3-rpm
  when: ansible_os_family == "Suse"

- name: Gather package facts
....
....

[berndfinger]

@sean-freeman We can safely assume that the package python3-rpm is present on RHEL, because:

• The description of the module package_facts does not mention a specific requirement for RHEL or Fedora-based systems.
• When installing RHEL 9.2 with the minimal_install software environment group, this package is installed.

For SLES based systems, the following task should also work and could avoid the use of the command module:

- name: Ensure package python3-rpm is present - required for package_facts module on SLES
  ansible.builtin.package:
    - python3-rpm
  when: ansible_os_family == "Suse"

[marcelmamula]

@sean-freeman Which OS version did you try? I just tried on SLES15 SP4 and SLES4SAP 15 SP5 and python3-rpm is preinstalled on both of them out of box.

[sean-freeman]

@berndfinger In my opinion, it is safer to execute both as shell commands because package Ansible Module in-line documentation is vague with quote "Whatever is required for the package plugins specific for each system". We cannot assume all OS Images are built equally?

@marcelmamula I used SLES 15 SP0..5 - there is variance across different OS Images and how they were prepared.

[berndfinger]

@berndfinger In my opinion, it is safer to execute both as shell commands because package Ansible Module in-line documentation is vague with quote "Whatever is required for the package plugins specific for each system". We cannot assume all OS Images are built equally?

@sean-freeman If there is a limited number of affected SLES versions, the use of the package module should and could be tested for those before using the command module instead of the available special module. If we decide to use the command module, we need a #noqa ansible-lint exception and also a proper justification in a comment before the task name. I don't have a problem in general with using the command or even shell module in place of an existing special module, but I don't think that the comment in the source of the package module is sufficient for a justification here.

[sean-freeman]

@berndfinger Identified the issue on multiple Cloud Platforms, and impacts any OS Image / VM Template on the Hypervisors I have access to (as the Administrators of those environments did not append the package beyond the normal ISO install). I can test the package Ansible Module where there was an impact and provide results within a few hours.

I also was suprised at that package Ansible Module comment, it's very vague.

[sean-freeman]

@berndfinger Forgot about this GH Issue.

I confirm this impacts any SLES OS Image prepared generically by an Administrator from an ISO with default settings.

For RHEL I can see that python3-rpm source is package rpm, and the rpm is part of Core Package Group - which is part of all the installation "Base Environment" choices.

For SLES I can see that python3-rpm source is package python-rpm, and only rpm is part of patterns-base-base Pattern (contained in the SLE Module 'Basesystem') - which is part of all the installation choices.

This is a one-line command that won't cause any incidents but will protect the end-user from OS Images prepared without forecasting Ansible's usage, I am going to open a PR for SLES only using the above code. We cannot create a hard dependency prior to Ansible execution, this is a simple solution to avoid issues.