Roadmap¶
Shipped¶
Four components are real, tested Go libraries with CI running on every push and pull request:
vault— Ansible Vault 1.1 compatible AES-256 encryptioninventory— INI/YAML inventory parsing, group ancestry, host-pattern matchingvars— the variable precedence laddertemplate— Jinja2-compatible templating with Ansible's filter and test library
In progress¶
The following repositories exist in the go-ansible organization but do not yet have working code — this documentation makes no capability claims about them, and they are intentionally not linked from the components pages above until they do:
modules— the Ansible module execution protocol (the JSON-over-stdin/stdout contract a module implements) plus the core module libraryplaybook— the playbook/role/task/handler engine: loops, conditionals, blocks, strategies. This is the piece that will actually drivevarsandtemplatetogether against a real play, rather than each being exercised standalone as they are today.facts— fact gathering, the Go equivalent of thesetupmodulegalaxy— role and collection installer,requirements.yml, a Galaxy API clientcli— theansible,ansible-playbook,ansible-vault, andansible-galaxybinaries, once there is an engine underneath them worth shipping a CLI for
Design principles carried through every component¶
- Byte/wire compatible, not merely similar.
vaultreproducesansible.parsing.vault.VaultAES256's exact format; a file it writes decrypts with the realansible-vaultand vice versa. Every future component holds itself to the same bar against the realansible-corebehavior, not against this project's own prior guesses. - Pure Go,
CGO_ENABLED=0. No component here, or planned, depends on a C library or an external interpreter. - Each concern its own module.
vaulthas no dependency on the other three; a program that only needs Vault-compatible decryption does not pull in a Jinja2 engine it will never call. The same separation is intended formodules,playbook,facts, andgalaxyas they land.