Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-22400

[RFE] Option for Single Event per Message from MultiClusterGlobalHub Agent

XMLWordPrintable

    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • 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

       

      1. 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.

              rh-ee-myan Meng Yan
              alosadag@redhat.com Alberto Losada
              Hui Chen Hui Chen
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: