uyuni VS ansible-build-data

related to a recent discussion about Java exceptions (https://news.ycombinator.com/item?id=36708759), this project clearly haz all teh kwal-uh-teee:

https://github.com/uyuni-project/uyuni/pull/7274/files#diff-...

                catch (IOException e) {

If anybody asks, why I am using Leap for the VM: I am using Uyuni to manage my VMs, and I like the fact, that I only have to download Repositories for one distro. I am willing to use another distro though, if it is on this list. But I do need confirmation, that the distro is really easy to set up, with the amdpro drivers and Jellyfin, before I go and download hundreds of GB of repositories into my Uyuni setup.

In regard on how to distribute things: If you just want an installation server then I would recommend Cobbler. This server is what is used by Uyuni under the hood for auto-installations. But this would be only reasonable if you really want to try to distribute in a broader way. I am aware that both projects are used from a couple of multiple thousands of machines. So you should be able to bend that system to your desire.

Yesterday, while searching for something unrelated i stumbled upon this code : https://github.com/uyuni-project/uyuni/blob/9954f409ea67b557d18e59c19ca4fb8ce7f448f2/spacecmd/src/spacecmd/shell.py

No, not just a GUI for Salt. Uyuni adds a lot more on top of Salt. This presentation is a bit dated but it gives you an idea: https://github.com/uyuni-project/uyuni/wiki/Presentations#openfest-2020

The OpenFest presentation has some screenshots toward the end of the slide deck - https://github.com/uyuni-project/uyuni/wiki/Presentations

Take a look here for more details (a bit dated, it's from November last year): https://github.com/uyuni-project/uyuni/wiki/Presentations#openfest-2020

IBM -> RedHat -> Ansible (https://docs.ansible.com/platform.html)

I think the new ansible docs are opaque, and the new "everything is an ansible collection" scheme makes troubleshooting any issues reported by users hundreds of times harder than "the old days"

I keep this (https://github.com/ansible-community/ansible-build-data/blob...) bookmarked because it's the only way to match up what "ansible 8.1.0" (https://pypi.org/project/ansible/8.1.0/) even means since it for damn sure not any of this: https://github.com/ansible/ansible/releases (they used to have a 'release' pinned on that releases tab saying "these are not the droids you are looking for"). I believe I tried asking for them to update the completely erroneous pypi "source code" link to point to that repo and ... well, one can see how well that turned out

➡️ Check Release Notes📦️🗒️ and Ansible 8 Porting Guide for more details.

💽You can install it by running the following command or download the release tarball directly from pypi: pip install ansible==8.0.0a1 --user ➡️Check Release Notes 📦️🗒️ and Ansible 8 Porting Guide for more details!

You can find the current list for Ansible 7 here: https://github.com/ansible-community/ansible-build-data/blob/main/7/ansible-7.build

Check Release Notes📦️🗒️ and Ansible 6 Porting Guide for more details on changes, improvements, new and deprecated features!!

You can find the release announcement on ansible-announce and the changelog on GitHub. Happy automating!

The vmware.vmware_rest collection has been included in Ansible 5. Thanks to everyone involved!

As https://github.com/ansible-community/ansible-build-data/issues/114 showed we should really check the existing collections included in the Ansible package. Some ideas:

Ansible 5.7.0 has been released with updates to 19 of the included Ansible collections! Read the announcement or check out the update changelog to learn more about this new version.

Debian package "ansible" -> called "ansible" on PyPI -> is called "ansible collections" through most of the documentation -> upstream PyPI packages are generated through https://github.com/ansible-community/ansible-build-data