Merge pull request #43890 from amolnar-rh/consolidated-ZTP

[WIP] Consolidated 4.10 RAN docs

Author: EricPonvelle

_attributes/common-attributes.adoc

@@ -133,5 +133,10 @@ endif::[]
 :ibmzProductName: IBM Z
 // Red Hat Quay Container Security Operator
 :rhq-cso: Red Hat Quay Container Security Operator
-:sno: single-node OpenShift
-:sno-caps: Single-node OpenShift
+:sno: single-node Openshift
+:sno-caps: Single-node Openshift
+//TALO and Redfish events Operators
+:cgu-operator-first: Topology Aware Lifecycle Manager (TALM)
+:cgu-operator-full: Topology Aware Lifecycle Manager
+:cgu-operator: TALM
+:redfish-operator: Bare Metal Event Relay

_topic_maps/_topic_map.yml

@@ -2227,6 +2227,8 @@ Topics:
   File: managing-alerts
 - Name: Reviewing monitoring dashboards
   File: reviewing-monitoring-dashboards
+- Name: Monitoring bare-metal events
+  File: using-rfhe
 - Name: Accessing third-party monitoring APIs
   File: accessing-third-party-monitoring-apis
 - Name: Troubleshooting monitoring issues
@@ -2282,6 +2284,8 @@ Topics:
   Distros: openshift-origin,openshift-enterprise
 - Name: Improving cluster stability in high latency environments using worker latency profiles
   File: scaling-worker-latency-profiles
+- Name: Topology Aware Lifecycle Manager for cluster updates
+  File: cnf-talm-for-cluster-upgrades
   Distros: openshift-origin,openshift-enterprise
 - Name: Creating a performance profile
   File: cnf-create-performance-profiles

images/211_OpenShift_Redfish_dataflow_0222.png

@@ -0,0 +1,25 @@
+// Module included in the following assemblies:
+//
+// *scalability_and_performance/ztp-deploying-disconnected.adoc
+
+:_content-type: CONCEPT
+[id="about-ztp-and-distributed-units-on-openshift-clusters_{context}"]
+= About ZTP and distributed units on OpenShift clusters
+
+You can install a distributed unit (DU) on {product-title} clusters at scale with {rh-rhacm-first} using the assisted installer (AI) and the policy generator with core-reduction technology enabled. The DU installation is done using zero touch provisioning (ZTP) in a disconnected environment.
+
+{rh-rhacm} manages clusters in a hub-and-spoke architecture, where a single hub cluster manages many spoke clusters. {rh-rhacm} applies radio access network (RAN) policies from predefined custom resources (CRs). Hub clusters running ACM provision and deploy the spoke clusters using ZTP and AI. DU installation follows the AI installation of {product-title} on each cluster.
+
+The AI service handles provisioning of {product-title} on single node clusters, three-node clusters, or standard clusters running on bare metal. ACM ships with and deploys the AI when the `MultiClusterHub` custom resource is installed.
+
+With ZTP and AI, you can provision {product-title} clusters to run your DUs at scale. A high-level overview of ZTP for distributed units in a disconnected environment is as follows:
+
+* A hub cluster running {rh-rhacm-first} manages a disconnected internal registry that mirrors the {product-title} release images. The internal registry is used to provision the spoke clusters.
+
+* You manage the bare metal host machines for your DUs in an inventory file that uses YAML for formatting. You store the inventory file in a Git repository.
+
+* You install the DU bare metal host machines on site, and make the hosts ready for provisioning. To be ready for provisioning, the following is required for each bare metal host:
+
+** Network connectivity - including DNS for your network. Hosts should be reachable through the hub and managed spoke clusters. Ensure there is layer 3 connectivity between the hub and the host where you want to install your hub cluster.
+
+** Baseboard Management Controller (BMC) details for each host - ZTP uses BMC details to connect the URL and credentials for accessing the BMC. ZTP manages the spoke cluster definition CRs, with the exception of the `BMCSecret` CR, which you create manually. These define the relevant elements for the managed clusters.

images/217_OpenShift_Zero_Touch_Provisioning_updates_0222_1.png

@@ -0,0 +1,52 @@
+// Module included in the following assemblies:
+//
+// * operators/operator-reference.adoc
+[id="baremetal-event-relay_{context}"]
+= {redfish-operator}
+
+[discrete]
+== Purpose
+The OpenShift {redfish-operator} manages the life-cycle of the Bare Metal Event Relay. The Bare Metal Event Relay enables you to configure the types of cluster event that are monitored using Redfish hardware events.
+
+[discrete]
+== Configuration Objects
+You can use this command to edit the configuration after installation: for example, the webhook port.
+You can edit configuration objects with:
+
+[source,terminal]
+----
+$ oc -n [namespace] edit cm hw-event-proxy-operator-manager-config
+----
+
+[source,terminal]
+----
+apiVersion: controller-runtime.sigs.k8s.io/v1alpha1
+kind: ControllerManagerConfig
+health:
+  healthProbeBindAddress: :8081
+metrics:
+  bindAddress: 127.0.0.1:8080
+webhook:
+  port: 9443
+leaderElection:
+  leaderElect: true
+  resourceName: 6e7a703c.redhat-cne.org
+----
+
+[discrete]
+== Project
+link:https://github.com/redhat-cne/hw-event-proxy-operator[hw-event-proxy-operator]
+
+[discrete]
+== CRD
+The proxy enables applications running on bare-metal clusters to respond quickly to Redfish hardware changes and failures such as breaches of temperature thresholds, fan failure, disk loss, power outages, and memory failure, reported using the HardwareEvent CR.
+
+`hardwareevents.event.redhat-cne.org`:
+
+* Scope: Namespaced
+* CR: HardwareEvent
+* Validation: Yes
+
+[discrete]
+== Additional Resources
+You can learn more in the topic xref:../monitoring/using-rfhe.adoc[Monitoring Redfish hardware events].