###### tags: `CfgMgmtCamp 2026` # Ansible talks CfgMgmtCamp 2026 - HackMD notes for Monday & Tuesday: https://red.ht/ghent2026 - Short URL to notes for Monday & Tuesday's talks: https://red.ht/ansible-contributors-summit - [Contributor Summit agenda in the forum](https://forum.ansible.com/t/cfgmgmtcamp-2026/44250) - [Ansible Code of Conduct](https://docs.ansible.com/projects/ansible/latest/community/code_of_conduct.html) - Live stream: - Monday: Room [B.1.014](https://www.youtube.com/watch?v=71tDyeo1Flk) - Monday: Room [B.1.017](https://www.youtube.com/watch?v=cLT8tSGXCDc) - Tuesday: Room [B.1.014](https://www.youtube.com/watch?v=EUz3S-Jj7MA) - Tuesday: Room [B.1.017](https://www.youtube.com/watch?v=oJDGZnTDWJo) - [Wednesday Live Stream - Contributor Summit](https://youtube.com/live/I5-T-RuhJzY?feature=share). ## Overview Everybody is welcome to make notes on the talks, especially any ideas, actions and offers to get involved. ## Wednesday: Ansible Contributor Summit Notes Please make notes for this session at [Ansible Contributor Summit, CfgMgmtCamp 2026](https://hackmd.io/hqN5QNMNQ-SawQPL1hfbdg) ## Talk: Debugging Playbooks Made Easy: The Ansible Playbook Debugger ### Use Cases - Retrieve task result structure - Evaluating jinja expressions - Listing ansible facts - FQCN names - Precedence of arguments evaluation VSCode plugin - spotter Supported Ansible: - Version: 2.11-2.18 from any thread - Ansible 2.19 must run in main thread Control flows supported: - breakpoints - stop on custom task - stop on start - stop before gather facts - step - execute till next step - continue - execute to next breakpoint or the end Additional choices: - stop once per task (`strategy`) or for every iteration inside loop (`task`) → `debugType` attribute watch/debug console (only in strategy debugType mode) What it is not: - action plugin debugger - use python debugger - inventory plugin debugger - filter, test or lookup plugin debugger - user python debugger Security considerations: - masking secrets - Debugger must have access to ALL variables, even those in vault. Potential for data tagging feature introduced in Ansible Core 2.19 Overriding variable values - not implemented ### Questions * Advice for how to use the debugger for writing plugins in an enterprise setting. * The debugger can debug everything but modules, recommend using breakpoints during debugging sesisons. * Is it possible to re-run the task while the debugger is running? * No simple way to do that right now. Potential to explore in the future? ### Idea Potential in newer versions of Ansible Core to use the [Data Tagging](https://forum.ansible.com/t/core-2-19-and-data-tagging-playground/39909) feature to prevent secrets being exposed during debugging. Tagging varibales as *sensitive* (or equivilent) to prevent exposure during debugging sessions. ## Talk: Don't Fear the Jinja - Beyond the Handlebars with Ansible Is a playbook a Jinja template? - Common misconception, but no. Template ability implemented by each keyword. - Special sauce over Jinja for Ansible features - Automatic lazy template-on-fetch. - Native mode (Core team contributed to Jinja upstream project for enhancements to this). Native mode is by default Jinja Template Behavour in Ansible * Only run on the Ansible controller. * Should not have side effects * May be evaulated more than once. Can be done during a best effort scenario. Can sometimes happen when a debugger is being used. * Lazy recursive templating: Templates are not evaulated untl referenced. Laziness was vastly improved in 2.19. Jinja macros: * Easier to write than (Python) Jinja plugins. * Building CI CD pipeline with Ansible. ### Questions * Alternative to Jinja? Jinja plugins. A lot of overhead to do that safely. - Genarating changelog: can we use singular for a minor change in changelog fragment and will it enarating a new changelog? - How to figure out when to use a collection? How big a playbook should be to make a collection and/or role? ## Building CI/CD pipelines for your Ansible code Due to nature of Ansible, make sure to think about file/code structure beforehand Have your Ansible code in Git CI/CD pipelines: execute jobs on git events, usually on a runner. For tests, linting, releases, deployments, ... GItLab CI/CD: in .gitlab-ci.yml Divided into stages, executed one after after another. a stage can contain multiple jobs which can run in parallel Git hooks can be use for same purpose and are great but CI/CD pipelines are better 😃 : - much more workflows - nice logging - dedicated runners - and much more ### ansible-lint First pipeline when code is in git: lint the code (static analysis of the code): Check for best practices and possible caveats and to enforce standards yamllint? Generic for YAML, ansible-lint also uses yamllint, so no separate yamllint is required You can override lint complains on per line basis using #noqa syntax ### Ansible collections when code grows, good idea to package the code in a collection: - modular and reusable - easily distributed - clearer context - easier version control - easier to maintain ansible-galaxy cli tool : init collection: ansible-galaxy collection init <name> build: ansible-galaxy collection build publish on galaxy, private galaxy NG or AAP: ansible-galaxy collection publish install: ansible-galaxy install (downloads all requirements + collection) CI/CD pipeline: built collection → tarbal → saved as artefact → publish to galaxy server or AAP ### Changelog clear project history easier maintenance and support better user trust tool: antsibull-changelog → add changelog fragment to each commit: describe what the change does antsibull-changelog release → collects all changelog fragments and adds it to CHANGELOG.rst also reads inline docs from plugins/modules, so no separate changelog fragment required syntax: ```yaml deprecated_features: - >- ... breaking_changes: - >- ... minor_changes: - ... ``` Run from CI/CD on version bump → generate changelog → push new tag ### Execution Environments - Container images for executing Ansible - created with ansible-builder - customizable with: own collections, python packages, certificates, ... - use with ansible-navigator, AWX or AAP definition in execution-environment.yml:set dependencies, base image, additional build steps ansible-builder build --container-runtime docker -t <registry>/<image>:<tag> CI/CD: run builder to build image → push new image to registry ### Molecule - create test infrastructure - run ansible code against it - verify results - test idempotence - destroy test infrastructure Steps: - Init: molecule init scenario my_scenario - create infra: molecule create - run test: molecule converge - test idempotence molecule idempotence - destroy: molecule destroy or all in sequence: molecule test ## antsibull-nox 1. Why using toml is so difficult in Ansible? ## Building self-contained installers for Ansible The presentation, as well as the code alongside explanations can be found at: https://github.com/danielpodwysocki/self-contained-ansible-demo The real-world case the presentation is based off of can be found at: https://github.com/juno-fx/K8s-Playbooks/blob/main/.github/workflows/release-oneclick.yml Questions that had come up during the talk: 1) Q: Are there safety/stability implications to mounting /proc and /dev into a chroot A: Not for an installer - however you want to add safeties to not mount over /dev/ twice - this will kill all PTYs and force a machine reboot. You can see how I safeguard against it here: https://github.com/danielpodwysocki/self-contained-ansible-demo/blob/main/installer/installer.run#L35 Mounting those in is very similar to running a privileged container - it does the same thing. 2) Q: Have you tried any tools that create a single python executable A: I considered it briefly, but I quickly ruled that out and opted for deriving the installer from an OCI base. The prime reason for it had been the customer needing to also run an Execution Environment (ansible lingo for: container where you execute your playbook runs) I wanted to have a shared base for both. 3) Q: Why not require some container tooling on the host, since the first use case had been to deploy a container platform? A: What we were deploying shipped with its own executable, containing containerd. Having 2 implementations of it would bloat the amount of software on the machine and our end users didn't like that. ## Talk: How we opened up Ansible's documentation infrastructure to the community Dependency challenges initially. Lost reasoning for why certain versions were pinned in `requirements.txt` files. Dependency pinning strategy: - Keep production builds stable. - Create tested and relaxed dependencies. - Don't force users to install pinned dependencies. - Bump dependencies automatically. Using `nox` to help with test automation - linting documentation for any formatting issues. Ansible documentation bot for engaging with the community contributing to documentation. Implemented patchback for backporting certain pieces of documentation. Reducing manual maintainer burden. Will the magic va work in 2.19? ## Talk: Writing, running, and testing awesome Ansible content with natural language and AI - powered by Ansible's MCP server ### Questions - Best practices for Ansible Content - How did the devtools team generated that Markdown file used for the MCP context, were Ansible Lint rules used to generate that? - `define_and_build_execution_env` - Is it able to install `podman` for me too? Say I'm on a system which doesn't have `podman` installed, or I don't know much about containers. Help reduce the barrier to entry for new users. - How many tokens does it use? - All of the tooling is shared so the token count is not excessive. The feature is still in the process of being developed. - how to do streaming output work in ansible? - how does data tagging work (the support) in 2.19? (sensative data tagging) - Visualizer debugging in 2.19 (protomater collection finder) - How does tag on the variable work? - Is it possible to see all the deprication working after the run of the playbook? - If the include task can have return value?