On Mon, Jul 6, 2020 at 7:11 PM Neal Gompa <ngompa13(a)gmail.com> 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
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:
, and a corresponding Ansible playbook would also read and execute
And Ansible's own APIs are horrifically unstable, to the point
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.
explains more about where RH's Ansible product managers intend to go
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