CfgMgmtCamp, 2025 - Ansible Contributor Summit

News & Announcements Blog
,
1

Ansible Contributor Summit is the day to celebrate community, technology and Ansible. The agenda of the day was divided into three parts:

  1. Warmup Discussion
  2. Talks
  3. Content Creator Experience (Dev Tools Workshop)

Discussion Session

The session continued from Kirill Satarin’s earlier talk on Functional Programming Design Patterns in Ansible Code. Felix Fontein suggested creating an action plugin called Evaluate, which would allow expressions to be evaluated and registered for later use, similar to set_facts.

The proposal was to introduce an evaluated task that could process expressions at a specific point in time and optionally run with run_once: true. The evaluated results could then be registered in the vars: section for reuse.

This approach aims to improve flexibility and efficiency in Ansible workflows by simplifying the handling of evaluated expressions.

Key Links:

Next steps:

Talks

Building the Ansible Pilot community

Presenter: Luca Berton

Video: Link

Luca began his journey by creating a YouTube video. He noticed that many Ansible videos on the platform were lengthy—often over two hours—so he decided to create shorter, more focused content. His videos, particularly those addressing Windows systems, gained traction as he noticed there was a high volume of searches and questions around this topic.

As Luca continued creating content, he received positive feedback and made valuable connections within the tech community. Building on this success, he expanded his efforts into writing books, eventually publishing five practical guides on interacting with Ansible.

Luca’s key advice is to not only focus on improving professional skills but also to invest in personal branding that highlights your abilities and expertise.

Key Links:

Next steps:

  • Empower our international communities (with varied language)
  • Ensure awesome-ansible & the Forum’s international communities link to Luca’s non-English content
  • Add in a pinned-post in each language that has links to resources in the native language
  • Consider which countries don’t have as many English speakers (such as Italy) and countries with very different languages (Chinese & Japanese)

How to Become an Ansible Contributor?

Presenter: Anwesha Das

The talk began with a broader perspective on why contributing to an open-source project is valuable. The speaker highlighted how it can foster personal growth, enhance learning, and open doors for career development. Drawing from her own experiences, she shared insights on the benefits of becoming an open-source contributor.

The session also explored the various ways individuals can contribute to Ansible. The speaker provided a detailed overview of the different roles and contribution opportunities available within the Ansible community. These included positions such as technical writer, community gardener, system administrator, release management, and, of course, contributions as Python developers.

Key links:

Ansible core architecture: Handlers

Presenter:Martin Krizek

Slides: Link

Martin kicked off his talk with a deep dive into the concept of Handlers in Ansible. A handler is a special type of task that is executed only when notified by a task that has changed. This session covered essential practices for working with handlers in Ansible playbooks.

Key Concepts and Best Practices:

  • Notify and Listen: To trigger handlers, you can use the notify: or listen: keywords. These allow you to notify handlers when specific tasks are marked as changed.

  • Topics and Multiple Handlers: Handlers can be triggered using topics, allowing you to notify multiple handlers at once.

  • Naming and Topics: Every handler needs a unique name and topic. Without these, handlers serve no purpose and will not function correctly.

  • Defining Handlers in Roles: Handlers are typically defined within the handlers directory of a role. To notify a handler within a role, use the special syntax role_name: handler_name.

  • Using include_tasks and import_tasks as Handlers: You can treat include_tasks and import_tasks as handlers in your playbook. include_tasks is executed at runtime, while import_tasks is handled at parse time. This distinction means that while both are technically handlers, include_tasks behaves dynamically, and import_tasks is more static.

Chaining Handlers:

Handlers can notify other handlers, allowing you to chain them for more complex workflows. This is a powerful feature that lets you build layered and interdependent tasks.

Ansible-Core 2.14 and Later:

In Ansible-Core 2.14 and above, handlers are treated as regular tasks and follow the same execution flow as tasks, managed by the PlayIterator state machine. This change makes handlers more consistent with other tasks in Ansible.

Audience Poll Insights:

During the session, Martin asked the audience some insightful questions:

  • Who uses a custom strategy plugin?
    Answer: Only a few, about 2 people, use them occasionally.

  • Who reads the ansible-core porting guides?
    Answer: Around 5 people actively read them.

  • Who knows what a meta task is?
    Answer: Approximately 20% of the audience was familiar with meta tasks.

Key Takeaways and Advice:

Martin shared several valuable pointers to enhance your use of handlers in Ansible:

  • Unique Handler Naming: To avoid conflicts, always name your handlers uniquely.

  • Flush Handlers: The flush_handlers meta task triggers handlers and is automatically added by the core engine. However, you can also explicitly call flush_handlers if needed.

  • Handler Execution on Failure: If a play fails, the handlers will not be executed by default. You can override this behavior at the play level or via the CLI using force_handlers: true.

  • Execution Order: Handlers are executed in the order they are defined in the playbook, not the order in which they are notified.

  • Limitations: Check the handler documentation for details on its limitations.

  • Templates in Handler Names: Be cautious when using templates in handler names, as it can lead to unexpected behavior.

  • Porting Guides: Always refer to the porting guides in the documentation to stay up to date with best practices.

  • Cross-role Handlers: You can reference a handler from another role, but this introduces dependencies between roles, which isn’t considered a best practice. It’s recommended to run handlers explicitly in the roles when needed by using flush_handlers.

  • Role Execution in Playbooks: Roles must be included in the playbook to notify their handlers. Handlers in roles that are not part of the play cannot be notified.

Conclusion:

Handlers are an essential feature in Ansible that help automate workflows efficiently. By following these best practices and understanding the details of handler execution, you can create more robust and predictable Ansible playbooks. Don’t forget to dive into the handler documentation for more advanced tips and limitations!

Contributing to Ansible collections : fireside chat about community.general

Presenter: Felix Fontein

community.general is a monolith with 700+ open PRs. It was created with the “left overs” that didn’t have a dedicated home after the big move into Collections. The maintainers managed to spin out some content into dedicated repos. The repo is in need of active maintainers to maintain community.general. It still is one of the crucial ones of the Ansible community (there were 90% of the attendees who used community.general). Felix asks for help and offers help with issues and pull requests.

Key links

Recording Ansible benchmarking

Presenter: David M. Simard

Video: Link

Slides from last year’s presentation about the prometheus implementation

2 Likes