This RFE addresses a gap in the eventing mechanism of the Topology Aware Lifecycle Manager (TALM), specifically when it interacts with Zero Touch Provisioning (ZTP). When a new cluster is provisioned via ZTP and no explicit policies are immediately associated with it, TALM automatically creates a default ClusterGroupUpgrade (CGU) resource. While this CGU triggers a TALM event, the event currently lacks the cgu.openshift.io/cluster-name event annotation.

This RFE proposes that any TALM event generated for an automatically created CGU (e.g., when a ZTP provisioned cluster is ready but has no policies applied yet) must include the cgu.openshift.io/cluster-name annotation, populated with the name of the newly provisioned cluster.Notice that the CGU with the name of the cluster is always created and event with Reason equals to Success when it is remediated even if no clusters are targeting the CGU. This means that although there are no clusters that have been remediated because there is nothing to remediate, TALM still knows who is the target cluster of the CGU.

Business Requirements

1. Enabling Post-Provisioning Automation for ZTP Clusters: The customer's workflow relies on receiving a clear indication that a ZTP-provisioned cluster is ready for application deployment. The CguSuccess reason for an automatically generated CGU, where the CGU name matches the cluster name, serves as this signal. Without the cgu.openshift.io/cluster-name annotation, it becomes impossible for external automation systems like Ansible Event-Driven Ansible (EDA) to reliably identify which cluster has just completed provisioning.
2. Simplified Event Filtering and Processing: As demonstrated by the provided Ansible playbook snippet, the current lack of cgu.openshift.io/cluster-name in these specific events prevents effective filtering (item.eventAnnotations'{}}}{{{}[cgu.openshift.io/cluster-name is defined) at the EDA rulebook level. This forces complex workarounds or, more critically, causes valid events to be ignored, breaking the automation chain.
3. Consistent Event Data for All CGU Events: For consistency, all TALM events related to CGUs should ideally provide the relevant cluster context. The absence of cluster-name for automatically generated CGUs creates an inconsistency that complicates event-driven logic.
4. Actionable Notifications: The ability to include the specific cluster name in notifications (e.g., Slack messages) is crucial for operations teams to quickly understand the context of an event and take appropriate action. Currently, these important notifications are incomplete or impossible to send with the desired detail.

Functional Requirements

• TALM Event Generation Logic Modification: The TALM component responsible for generating Cloud Events for CGU status changes must be updated.
  • Specifically, when a CGU is automatically created and its state transitions to Success (or any relevant final state indicating provisioning completion), and if this CGU is not directly associated with specific policies targeting clusters (leading to no explicit cluster-name association through policies), the event generator must:
    • Infer the cluster name from the CGU's own name (as it is often named after the cluster in these automatic scenarios).
    • Or, if the cluster name can be derived from the ZTP process or another internal TALM mechanism, use that source.
    • Populate the eventAnnotations field with 'cgu.openshift.io/cluster-name': '<cluster_name>'.
• Ensuring Event Completeness: The goal is that any TALM event indicating the completion of a ZTP cluster provisioning, even if no explicit policies were initially applied, carries the cluster-name annotation.

 
List any affected known dependencies: Doc, UI, etc.

• Topology Aware Lifecycle Manager (TALM) Codebase: The core TALM controller/operator that generates CGU events would require modifications to its event-emitting logic.
• Red Hat Advanced Cluster Management (RHACM) and ZTP Integration: This change directly impacts how TALM integrates and signals completion states for clusters provisioned through ZTP.
• TALM Documentation: The official TALM documentation, especially sections pertaining to eventing and integration with external systems, would need to be updated to reflect the presence of this annotation in all relevant CGU events.
• Ansible Automation Platform Event-Driven Ansible (EDA) Best Practices: EDA examples and KCS articles for integrating with TALM would benefit from this, as event filtering based on cluster-name would become consistently reliable.