stdevel / ansible-collection-uyuni Goto Github PK

Currently, the modules won't return the action ID given by the Uyuni task scheduler. Those information might be necessary for debugging purposes.

First off, thanks Christian for the collection and the nice SUSECON talk.

I picked up my Uyuni experiments and integrated your collection into my little vagrant setup. I used a playbook like the following:

[...]
  roles:                                                                                                                                                                                     
    - role: 'stdevel.uyuni.storage'                                                                                                                                                          
      uyuni_pv: '/dev/vdb'                                                                                                                                                                   
    - role: 'stdevel.uyuni.server'
      [...]

My guess was that the storage should be prepared first, before installing the server and using the mounts.

But this fails, as xfsprogs is not yet installed when the storage role runs:

TASK [stdevel.uyuni.storage : Create file systems] *****************************
failed: [uyuniserver01] (item={'name': 'lv_uyuni', 'type': 'xfs', 'mountpoint': '/var/spacewalk', 'size': 10240}) => {"ansible_loop_var": "item", "changed": false, "item": {"mountpoint": "/var/spacewalk", "name": "lv_uyuni", "size": 10240, "type": "xfs"}, "msg": "Failed to find required executable \"mkfs.xfs\" in paths: /usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"}
failed: [uyuniserver01] (item={'name': 'lv_pgsql', 'type': 'xfs', 'mountpoint': '/var/lib/pgsql', 'size': 10240}) => {"ansible_loop_var": "item", "changed": false, "item": {"mountpoint": "/var/lib/pgsql", "name": "lv_pgsql", "size": 10240, "type": "xfs"}, "msg": "Failed to find required executable \"mkfs.xfs\" in paths: /usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"}
failed: [uyuniserver01] (item={'name': 'lv_cache', 'type': 'xfs', 'mountpoint': '/var/cache/rhn', 'size': 10240}) => {"ansible_loop_var": "item", "changed": false, "item": {"mountpoint": "/var/cache/rhn", "name": "lv_cache", "size": 10240, "type": "xfs"}, "msg": "Failed to find required executable \"mkfs.xfs\" in paths: /usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"}

Manually installing the xfsprogs package before running the storage role fixes the issue.

I think it would be best to move the xfsprogs installation into the storage role. If desired, I can create a PR for that.

It woulde be nice having a dynamic inventory that offers the following features:

• listing hosts and hostgroups
• listing IPv4/IPv6 addresses
• listing custom parameters and values

It would be useful to check for senseful hardware minimum requirements:

• SUSE Manager 4.3
• Uyuni

The new API will be considered as "production ready" with SUMA 4.3.2 so it would be a great option to drop XMLRPC.

Currently, uyuni.py includes a lot of overhead required for katprep - e.g. ABCs, additional classes, plain functions. It would be nice to remove these for the library to become more maintainable.

It would be nice having the possibility to also install proxy servers.

When I using uyuni collection to bootstrap a few linux servers, AWX show me following error:

"HTTP Error 404: 404", "status_code": 404, "url": "http://myuyunifqdn/pub/bootstrap/bootstrap-oraclelinux8.9.sh"}

looking for uyuni docs and open manually repo bootstrap I saw that URL its working just https but bootstrap.yml (roles/client/tasks/bootstrap.yml) are set to using http

• name: Download Uyuni bootstrap script
  ansible.builtin.get_url:
  url: "http://{{ uyuni_server }}/pub/bootstrap/{{ uyuni_bootstrap_filename }}"
  dest: "{{ uyuni_bootstrap_folder }}/bootstrap.sh"

It would be nice to have a shiny documentation (like for foreman-ansible-modules) created automatically.

It would be great to have a client role that bootstraps new clients.

It would be nice to have the possibility to filter systems based on their Custom Hostinfo keys, e.g.:

plugin: stdevel.uyuni.inventory
host: 192.168.180.1
user: admin
password: admin
verify_ssl: false
show_custom_values: true
custom_values:
  - katprep_snapshot
  - katprep_virt_snapshot = 1

As event-driven Ansible seems to be a real thing, it would be nice to have the possible to leverage it - e.g.

• listening for systems requiring a reboot
• listening for systems that are unreachable (e.g. Salt Minion down)

This collection can't be used without special circumstances on SLES 15 as the system-wide Python 3.6 version is way too old.
It would be nice to document how to deal with it.

Currently, the dynamic inventory plugin only combines groups, it would also be nice to intersect them like SSM does.

For some scenarios it would be nice to have the option to pin LVs (Cache, Spacewalk, Database) to dedicated VGs.

It would be nice to have the possibility to also automate containerized installations: https://www.uyuni-project.org/uyuni-docs/en/uyuni/installation-and-upgrade/container-deployment/uyuni/opensuse-leap-micro-deployment.html

From time to time there are regression bugs in openSUSE Leap / SLES that result in a orphaned task during patch installation. As a result, the patch task is still in "Scheduled" or "Picked Up" state, even though some patches might have been installed - or not.
It would be good to install all package management stack updates first before installing all remaining patches.

This could be implemented as a parameter for the install_patches module, e.g. mgmt_stack_only.

Unfortunately, there is no API call for this in Uyuni - so we need to be more creative. It could be possible to filter for errata affecting the zypper, libzypp, salt-minion and venv-salt-minion packages.

It would be great to have custom SSL certificates installed before installation: https://documentation.suse.com/suma/4.3/en/suse-manager/administration/ssl-certs-selfsigned.html

For some actions (e.g. installing patches) it is required to wait until they are finished before the next step (e.g. rebooting the host) is executed. For this specific example, we can't rely on the Uyuni task scheduler, as requests are in mixed order sometimes. A module like stdevel.uyuni.wait_for_task could be a benefit.

Requires #37.

It would be nice to move the Uyuni Ansible role (https://github.com/stdevel/ansible-uyuni) to this collection.

It would be nice having an Ansible Role for upgrading SUSE Manager - including database migrations.

Maybe it would be easier to outsource the Uyuni Python library to a dedicated project?

Dear Christian,

for a small demo setup I have all the tooling ready to automatically setup the server and bootstrap the client. For now, there is one manual step in between, and that is creating a bootstrap script and an activation key.

I am not sure how much use this would get outside of demos, but I could imaging that this could be a nice addition to your collection.

(Or is this already possible and I just missed it?)

It would be nice to implement testing:

• add example playbooks
• add Vagrant box for testing
• add module tests

It would be nice to have the possibility to schedule OpenSCAP runs.

I ran the sample ansible playbook install_patches and received the following error from my Uyuni:

...
TASK [Installing patches] ***************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible_collections.stdevel.uyuni.plugins.module_utils.exceptions.SessionException: Generic remote communication error: "redstone.xmlrpc.XmlRpcFault: Operation not allowed for systems that have modular channels assigned. Please consider setting 'allowModules=true'."
...

I tried adding allowModules = True to the API call and it works. Can I contribute code adding this parameter to install_patches?

References: https://github.com/uyuni-project/poc-uyuni-api/blob/master/cmd/mgr-api.spec.conf

It would be great if the collection could be used to build "Content Lifecycle Projects". I plan an automation to roll out kernel live patches (e.g. monthly). I have predefined filters in my project which allow newly released kernel live patches to be included in a new build. So I need a function to (re-)build the project and promote it to higher stages. After that I can use function the collection already offers to apply the patches.
This should be possible through the [contentmanagement.buildProject] and [contentmanagement.promoteProject] API calls.