On Mon, Jul 6, 2020 at 7:11 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > This sort of worries me though: abusing Ansible to do this sort of > thing is not what it was made for. It also makes mentally modeling how > everything works so much harder because the sequencing (or execution > flow) of actions is non-obvious. You're right that Ansible originally only operated on systems with SSH. However, there are a lot of modules and plugins now that do many more things. I completely agree that it's possible to make a mess and make Ansible non-obvious. The sequencing and execution flow must be obvious or we're not making the world better. I've found that when I implement loops or complex conditionals in Ansible playbooks, that does get hard to read and understand. Ansible shines when the modules are easy to use for non-programmers. The essential complexity should live inside the modules or plugins. At a high level, we're talking about "configuration management", and whether it's SSH or other systems, I've found Ansible is a good fit. This script reads and executes top-to-bottom: https://pagure.io/releng/blob/master/f/scripts/branching/make-koji-release-tags , and a corresponding Ansible playbook would also read and execute top-to-bottom. > And Ansible's own APIs are horrifically unstable, to the point that > I've had *bar conversations* about how people have to pin to specific > Ansible releases because all the crap they build on top of it to bend > Ansible to their needs relies on the part of Ansible that's > deliberately *not* stable: the Python module extension interface. I can't speak to or defend the decisions Ansible's made in the past, and I can't say that they'll never break us again. There are two things to consider though: 1. The Ansible core engineers are more incentivized than ever before to make the Python API for out-of-tree modules stable, because they've pulled almost all of the modules out of the ansible monorepo in 2.10. https://www.ansible.com/resources/webinars-training/collections-future-of-how-ansible-content-is-handled explains more about where RH's Ansible product managers intend to go strategically here. 2. In the spirit of "trust-but-verify", we also test against multiple versions of Ansible (and Python, etc). The CI system for koji-ansible runs unit tests and integration tests for all the Ansible modules on every pull request. The integration tests are a series of playbooks that we run against ephemeral Koji hubs and assert that the hub's data looks the way we expect. Today we run the integration tests against the latest GA version of Ansible on PyPI (2.9) and the latest pre-release on PyPI (2.10). It's important to do this because the blast radius for bugs is pretty high. The Ansible pre-release testing in particular gives us an early heads' up if something problematic is coming. - Ken _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
