forked from openshift/openshift-docs
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request openshift#2 from aireilly/amolnar-rh_consolidated-ZTP
TELCODOCS-261: Applied sagidlow's Redfish peer review comments
- Loading branch information
Showing
8 changed files
with
45 additions
and
37 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,45 +1,50 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * networking/multiple_networks/configuring-ptp.adoc | ||
| // * monitoring/using-rfhe.adoc | ||
|
|
||
| :_content-type: CONCEPT | ||
| [id="nw-rfhe-introduction_{context}"] | ||
| = How Redfish hardware events work | ||
| The Baremetal Hardware Event Proxy enables applications running on baremetal 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. These hardware events are delivered over a reliable low-latency transport channel based on Advanced Message Queuing Protocol (AMQP). The latency of the messaging service is in the 10~20 millisecond range. | ||
|
|
||
| The hardware event proxy provides a publish-subscribe service for the hardware events, where multiple applications can use REST APIs to subscribe and consume the events. | ||
| The hardware event proxy supports hardware that complies with Redfish OpenAPI v1.8 or higher. | ||
| The Baremetal Hardware Event Proxy enables applications running on baremetal 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. These hardware events are delivered over a reliable low-latency transport channel based on Advanced Message Queuing Protocol (AMQP). The latency of the messaging service is between 10 to 20 milliseconds. | ||
|
|
||
| The hardware event proxy provides a publish-subscribe service for the hardware events, where multiple applications can use REST APIs to subscribe and consume the events. The hardware event proxy supports hardware that complies with Redfish OpenAPI v1.8 or higher. | ||
|
|
||
| [id="rfhe-elements_{context}"] | ||
| == Redfish hardware events data flow | ||
| The following figure illustrates an example Redfish hardware events data flow. vDU is used here as an example of an application interacting with Redfish events: | ||
|
|
||
| The following figure illustrates an example Redfish hardware events data flow. vDU is used as an example of an application interacting with Redfish events: | ||
|
|
||
| .Redfish hardware events data flow | ||
| image::211_OpenShift_Redfish_dataflow_0222.png[Redfish hardware events data flow] | ||
|
|
||
| === Operator-managed pod | ||
| The Operator makes use of custom resources to manage the pod containing the hardware event proxy and its components using the HardwareEvent CR. | ||
|
|
||
| The Operator uses custom resources to manage the pod containing the hardware event proxy and its components using the `HardwareEvent` CR. | ||
|
|
||
| === Hardware event proxy | ||
| A container created to handle Redfish events. At startup, the hardware event proxy queries the Redfish API and downloads all the Message Registries, including custom registries. The hardware event proxy then begins to receive subscribed events from the Redfish hardware. | ||
|
|
||
| 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. | ||
| At startup, the hardware event proxy queries the Redfish API and downloads all the message registries, including custom registries. The hardware event proxy then begins to receive subscribed events from the Redfish hardware. | ||
|
|
||
| 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. The events are reported using the `HardwareEvent` CR. | ||
|
|
||
| === Cloud Native Event | ||
| Cloud Native Events (CNE) is a Rest-API specification for defining the format of event data: https://github.com/redhat-cne/spec/blob/main/event_spec.md. | ||
|
|
||
| Cloud Native Events (CNE) is a REST API specification for defining the format of event data. | ||
|
|
||
| === CNCF CloudEvents | ||
| CloudEvents is a vendor-neutral specification for defining the format of event data. | ||
| A specification developed by the Cloud Native Computing Foundation (CNCF) for describing event data in a common way: | ||
| https://cloudevents.io/. | ||
|
|
||
| === Dispatch router (AMQP 1.0 qpid) | ||
| The dispatch router is responsible for the message delivery service between publisher and subscriber. AMQP 1.0 qpid is an open standard designed to support reliable, high-performance, fully-symmetrical messaging over the internet. AMQP connects systems, supports management processes with the information they need and reliably transmits onward the instructions that run a distributed network via a connection-oriented messaging API. | ||
| link:https://cloudevents.io/[CloudEvents] is a vendor-neutral specification developed by the Cloud Native Computing Foundation (CNCF) for defining the format of event data. | ||
|
|
||
| === AMQP dispatch router | ||
|
|
||
| The dispatch router is responsible for the message delivery service between publisher and subscriber. AMQP 1.0 qpid is an open standard that supports reliable, high-performance, fully-symmetrical messaging over the internet. | ||
|
|
||
| === Cloud event proxy sidecar | ||
|
|
||
| === Sidecar: Cloud event proxys | ||
| A cloud events framework (based on ORAN API specifications) container image that provides an event publish-subscribe framework for hardware events. | ||
| The cloud event proxy sidecar container image is based on the ORAN API specification and provides a publish-subscribe event framework for hardware events. | ||
|
|
||
| [id="rfhe-data-flow_{context}"] | ||
| == Redfish message parsing service | ||
|
|
||
| In addition to relating Redfish events, the Redfish Hardware Event Proxy provides message parsing service for events without a `Message` property. The proxy downloads all the Redfish Message Registries including vendor specific registries from the hardware when it starts. If a event it received does not contain a Message property, the proxy will use the information from registries to construct the `Message` and `Resolution` properties and add them to the event before passing the event to the cloud events framework. | ||
| This service allows Redfish events to be generated with smaller message size and achieve lower latency. | ||
| In addition to handling Redfish events, the Redfish hardware event proxy provides message parsing for events without a `Message` property. The proxy downloads all the Redfish message registries including vendor specific registries from the hardware when it starts. If an event does not contain a `Message` property, the proxy uses the Redfish message registries to construct the `Message` and `Resolution` properties and add them to the event before passing the event to the cloud events framework. This service allows Redfish events to have smaller message size and lower transmission latency. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters