-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
Product / Portfolio Work
-
False
-
-
False
-
Not Selected
Feature Overview
This RFE requests an enhancement to the MultiClusterGlobalHub (MCGH) agent responsible for sending Cloud Events to external systems, particularly Red Hat Ansible Automation Platform (AAP) Event-Driven Ansible (EDA). Currently, this agent aggregates multiple Cloud Events generated within the hub cluster into a single message, which is then dispatched. The number of individual events bundled within a single message is not predictable.
This RFE proposes introducing a configuration option in the MCGH agent that allows users to explicitly enable a "one event per message" delivery model. This means the agent would send each generated Cloud Event as a separate, distinct message, rather than grouping them into a list.
Business Requirements
- Simplified Event Processing in Event-Driven Ansible (EDA):
-
- Direct Condition Matching: When EDA rulebooks receive a message containing a list of events, it becomes significantly more complex to define precise conditions. Users are forced to employ advanced methods like regular expressions or selectattr filters to check for the existence of a specific event within the received list.
- Reduced Rulebook Complexity: With individual events, rulebook conditions can be straightforward and direct (e.g., event.type == "cluster.created"), leading to simpler, more readable, and easier-to-maintain rulebooks.
- Increased Efficiency and Resource Optimization:
- Elimination of Redundant Processing: When a list of events is received by EDA, the entire list is passed to AAP for processing if any event in the list triggers a rule. This often leads to playbooks iterating over all elements in the list, even if only one or a few events are relevant. This consumes unnecessary time and computational resources on the AAP controller.
- Fine-Grained Automation Triggers: Sending individual events allows EDA to perform fine-grained filtering at the rulebook level. Only events that directly match a rule's conditions would trigger an action, avoiding the need to process irrelevant events within playbooks.
- Enhanced Integration with Event-Driven Workflows: True event-driven architectures thrive on atomic, discrete events. Aggregating events complicates integration with other event consumers and makes it harder to build reactive automation workflows that respond immediately to specific changes.
- Improved Observability and Troubleshooting: When events are sent individually, it simplifies logging, tracing, and debugging processes, as each message directly corresponds to a single, distinct occurrence.
Functional Requirements
- MCGH Agent Configuration Option: Introduce a new configuration parameter in the MCGH agent (e.g., in its deployment configuration, Helm values, or operator settings) that controls the event aggregation behavior.
-
- Proposed Parameter: event_delivery_mode (or similar).
- Proposed Values:
- aggregated (default, current behavior): Events are grouped into lists before sending.
- individual: Each Cloud Event is sent as a separate message.
- Single Event Payload: When event_delivery_mode is set to individual, the agent must ensure that each message payload contains only one Cloud Event object, adhering to the CloudEvents specification for individual events.
2. Backward Compatibility: The default behavior should remain aggregated to ensure backward compatibility for existing deployments that might rely on the current grouping behavior.
3. Performance Considerations: The implementation should consider the potential impact of sending a high volume of individual messages on the Kafka broker and the network, ensuring it remains performant.