Simulating Events in Ansible EDA: A Practical Use Case of ansible.eda.generic

When developing an Event-Driven Ansible rulebook to automate tasks like handling a server outage or responding to a failed CI/CD job, testing the logic can be tricky if we don’t have a live system constantly generating events. That’s where the ansible.eda.generic source plugin comes in handy. It allows us to define mock events and inject them directly into the EDA workflow. This makes it easy to simulate real-time scenarios, test the rule conditions, and ensure the playbooks run as expected in a safe and controlled environment. 

In this article, I’ll walk you through how to include payloads directly within an Ansible EDA rulebook, as well as how to read payloads from an external file and use that data in rule conditions. I’ll also include some of the parameters like loop_count and loop_delay, which will help to control the number of times an event is triggered and the delay between each trigger. These features are especially helpful for simulating and managing event flow effectively during testing and development.

Working With Payloads in Ansible EDA Rulebooks

In this demo, we’ll look at two different ways to work with payloads in Ansible EDA rulebooks. The first rulebook, generic-payload.yml, includes the payload directly within the rulebook itself, making it simple and self-contained. The second, generic-payloadfile.yml, reads the payload from an external YAML file, allowing for better organization and reuse. The external payload is stored in events.yml, which makes it easy to manage test data separately. Both rulebooks trigger the same playbook, generic-handle.yml, which prints the payload details passed from the rulebook.

Examples of generic-payload.yml and generic-payloadfile.yml Rulebooks

Below are examples of the generic-payload.yml rulebook as well as the generic-payloadfile.yml rulebook. Screenshots of each outcome are also found below.

generic-payload.yml

- name: Generic Source Payload
 hosts: localhost
 sources:
 - ansible.eda.generic:
 payload:
 - { service_name: "webapp", status: "unhealthy", timestamp: "2025-03-30T12:00:00Z" }
 display: true
 loop_count: 3 
 loop_delay: 30 
 create_index: i
 rules:
 - name: Check if the service is unhealthy
 condition: event.status == "unhealthy"
 action:
 run_playbook:
          name: generic-handle.yml

generic-payloadfile.yml

- name: Generic Source Payload File
 hosts: localhost
 sources:
 - ansible.eda.generic:
 payload_file:
 "events.yml"
 display: true
 loop_count: 3 
 loop_delay: 30 
 create_index: i
 rules:
 - name: Check if the service is unhealthy
 condition: event.status == "unhealthy"
 action:
 run_playbook:
          name: generic-handle.yml

events.yml

 service_name: "webapp"
 status: "unhealthy"
  timestamp: "2025-03-30T12:00:00Z"

generic-handle.yml

- name: Handle Unhealthy Service Event
 hosts: localhost
 gather_facts: false
 tasks:
 - name: Print service issue
 debug:
 msg: >
          Detected that '{{ ansible_eda.event.service_name }}' is '{{ ansible_eda.event.status }}' at '{{ ansible_eda.event.timestamp }}', current system timestp '{{ now(fmt='%Y-%m-%d %H:%M:%S') }}'

Output Screenshot From thegeneric-payload.yml Execution

Below you can find the resulting screenshot from leveraging the generic-payload.yml execution:

Output screenshot from generic-payloadfile.yml execution

Conversely, you can now see the output from the generic-payloadfile.yml execution. 

Conclusion

The ansible.eda.generic module is a valuable tool for developing and testing event-driven automation workflows in Ansible EDA. It enables the simulation of events through static payloads, allowing for easy validation of rule conditions and playbook behavior without needing live external systems. This approach is particularly useful during the development phase, where generating real-time events can be difficult. Leveraging the ansible.eda.generic plugin, we can design, test, and fine-tune the automation logic before integrating it with actual event sources.

Note: The views expressed in this article are my own and do not necessarily reflect the views of my employer.