Epic Goal

When an xKS cluster is registered into a RH product, we need to label the cluster with a similar unique identifier like the OpenShift Cluster ID

Why is this important?

Today, when a given xKS cluster is registered into both ACM and ACS; there is not a solution to uniquely identify that a cluster registered into both products is the same cluster. The cluster can be named differently across products.
For xCM, as we move towards providing a global cluster inventory for all Kubernetes clusters owned by a user. We need unique identifiers present for the cluster to be able to correctly display and map them to their correct integrations across products.
Currently the name of the cluster is being used as the ID in the acm_managed_cluster_info metric which is synced to RH Telemetry, which may make the cluster highly identifiable and a compliance problem (previously emailed legal and compliance, but they did not respond).

When an xKS cluster is registered into ACM, the ACM agent creates a resource or labels the cluster in a way that is similar to the OpenShift installer behavior.
When an xKS cluster is registered into ACS, the ACS agent creates a resource or labels the cluster in a way that is siimilar to the OpenShift installer behavior.
This functionality needs to be able to be pulled in and adopted across multiple products.

CI - MUST be running successfully with tests automated
Release Technical Enablement - Provide necessary release enablement details and documents.
...

CI - CI is running, tests are automated and merged.
Release Enablement <link to Feature Enablement Presentation>
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DEV - Downstream build attached to advisory: <link to errata>
QE - Test plans in Polarion: <link or reference to Polarion>
QE - Automated tests merged: <link or reference to automated tests>
DOC - Downstream documentation merged: <link to meaningful PR>