Translating Ansible Roles to Python with Reemote

DEV Community

Migrating Ansible roles to Python: a library-level translation target

Abstract When a large language model rewrites an Ansible role in ordinary Python, the result typically executes but does not behave like the role it replaces: fleet-wide lock-step execution, dry-run capability, and per-host change reporting are lost. We argue that the cause is structural rather than a deficit of model capability: translation tasks succeed when a canonical target idiom exists, and Python has lacked a configuration-management library for the model to translate into. We survey prior Python-based approaches — programmatic control of Ansible, general remote-execution libraries, and Python-native configuration management — with particular attention to pyinfra, the closest existing analogue, which we find falls short as a translation target on five axes: its concurrency model is not built on asyncio, its results interface is oriented toward the command line rather than a typed return value, its module vocabulary covers a fraction of Ansible's, its deploys read mutable live state without a determinism guarantee, and its file operations depend on the controller's file system. We then describe Reemote, an open-source library designed against these five criteria, and report an evaluation in which two Ansible Galaxy roles were converted automatically and verified for idempotence in an offline simulation. 1. Introduction Ansible expresses server configuration as declarative playbooks and roles in YAML [1]. The language is widely deployed, but it offers limited support for the surrounding engineering practice: infrastructure logic is not unit-testable with ordinary Python test frameworks, is not checkable with static type analysis, and cannot directly express computations that exceed the limits of a declarative DSL with a templating dialect. Migrating roles to Python would recover these properties, and large language models make such a migration appear cheap: a role can be pasted into a model with the instruction to rewrite it in Python. The output, however, is typically a script that shells out to package managers and wraps the sequence in error handling — a program that reproduces the role's happy path while discarding the machinery that made the role operable. This paper examines why. Section 2 surveys prior work and analyses pyinfra, the closest prior approach, against five requirements of a translation target. Section 3 formulates the problem: the properties a translated program loses, and the motivation for reaching Python without losing them. Section 4 describes the design of Reemote [15], an open-source library that implements configuration management as a library rather than a command-line tool. Section 5 reports an evaluation in which two Galaxy roles were converted automatically, and Section 6 states the limitations of that evaluation. 2. Prior work 2.1 Programmatic control of Ansible The most direct approach to operating Ansible from Python is to keep Ansible. ansible-runner [2] provides a stable interface for launching playbooks and consuming their events; Ansible's internal Python API exposes playbook parsing and execution. Neither removes Ansible from the execution path: the YAML, the state engine, and the CLI-shaped result all remain. These tools wrap Ansible; they do not provide a Python vocabulary of configuration operations that a translator could map roles onto. 2.2 Remote-execution libraries Fabric [3] and Paramiko [4] provide SSH connectivity and remote command execution. They operate at the level of shell commands: there are no facts that describe host state, no operations that compare desired and actual state, and no change reporting beyond command exit status. They are the primitives that an improvised translation reaches for, not a target idiom for one. 2.3 Python-native configuration management Salt [5] implements configuration management in Python, but as a distributed system — a daemon on each managed host (or an agentless SSH mode) driven by a CLI and its own state and pillar subsystems. It...

Powered by Readybot.io