mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
TELCODOCS-1947: Removing BMER from docs as it is EOL
This commit is contained in:
Ronan Hennessy
@@ -3030,8 +3030,6 @@ Topics:
|
||||
- Name: Managing bare metal hosts
|
||||
File: managing-bare-metal-hosts
|
||||
Distros: openshift-origin,openshift-enterprise
|
||||
- Name: Monitoring bare-metal events
|
||||
File: using-rfhe
|
||||
- Name: What huge pages do and how they are consumed by apps
|
||||
File: what-huge-pages-do-and-how-they-are-consumed-by-apps
|
||||
Distros: openshift-origin,openshift-enterprise
|
||||
|
||||
@@ -89,24 +89,6 @@ include::modules/ztp-configuring-ptp-fast-events-amqp.adoc[leveloffset=+2]
|
||||
|
||||
* xref:../../registry/index.adoc#registry-overview[{product-registry} overview]
|
||||
|
||||
[id="ztp-advanced-policy-config-bare-metal_{context}"]
|
||||
== Configuring bare-metal events with {policy-gen-cr} CRs
|
||||
|
||||
You can use the {ztp} pipeline to configure bare-metal events that use HTTP or AMQP transport.
|
||||
|
||||
include::snippets/ptp-amq-interconnect-eol.adoc[]
|
||||
|
||||
include::modules/ztp-configuring-hwevents-using-pgt.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../scalability_and_performance/using-rfhe.adoc#nw-rfhe-installing-operator-cli_using-rfhe[Installing the {redfish-operator} using the CLI]
|
||||
|
||||
* xref:../../scalability_and_performance/using-rfhe.adoc#nw-rfhe-creating-hardware-event_using-rfhe[Creating the bare-metal event and Secret CRs]
|
||||
|
||||
include::modules/ztp-creating-hwevents-amqp.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/ztp-add-local-reg-for-sno-duprofile.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -85,24 +85,6 @@ include::modules/ztp-configuring-ptp-fast-events-amqp.adoc[leveloffset=+2]
|
||||
|
||||
* xref:../../registry/index.adoc#registry-overview[{product-registry} overview]
|
||||
|
||||
[id="ztp-advanced-policy-config-bare-metal_{context}"]
|
||||
== Configuring bare-metal events with PolicyGenTemplate CRs
|
||||
|
||||
You can use the {ztp} pipeline to configure bare-metal events that use HTTP or AMQP transport.
|
||||
|
||||
include::snippets/ptp-amq-interconnect-eol.adoc[]
|
||||
|
||||
include::modules/ztp-configuring-hwevents-using-pgt.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../scalability_and_performance/using-rfhe.adoc#nw-rfhe-installing-operator-cli_using-rfhe[Installing the {redfish-operator} using the CLI]
|
||||
|
||||
* xref:../../scalability_and_performance/using-rfhe.adoc#nw-rfhe-creating-hardware-event_using-rfhe[Creating the bare-metal event and Secret CRs]
|
||||
|
||||
include::modules/ztp-creating-hwevents-amqp.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/ztp-add-local-reg-for-sno-duprofile.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
// 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
|
||||
@@ -1,13 +1,12 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
// * networking/ptp/using-ptp-events.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="cnf-migrating-from-amqp-to-http-transport_{context}"]
|
||||
= Migrating consumer applications to use HTTP transport for PTP or bare-metal events
|
||||
= Migrating consumer applications to use HTTP transport for PTP
|
||||
|
||||
If you have previously deployed PTP or bare-metal events consumer applications, you need to update the applications to use HTTP message transport.
|
||||
If you have previously deployed PTP consumer applications, you need to update the applications to use HTTP message transport.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -15,7 +14,7 @@ If you have previously deployed PTP or bare-metal events consumer applications,
|
||||
|
||||
* You have logged in as a user with `cluster-admin` privileges.
|
||||
|
||||
* You have updated the PTP Operator or {redfish-operator} to version 4.13+ which uses HTTP transport by default.
|
||||
* You have updated the PTP Operator to version 4.13+ which uses HTTP transport by default.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -39,7 +38,6 @@ containers:
|
||||
<1> The PTP Operator automatically resolves `NODE_NAME` to the host that is generating the PTP events.
|
||||
For example, `compute-1.example.com`.
|
||||
+
|
||||
In a cluster with bare-metal events configured, set the `http-event-publishers` field to `hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043` in the cloud event sidecar deployment CR.
|
||||
|
||||
. Deploy the `consumer-events-subscription-service` service alongside the events consumer application.
|
||||
For example:
|
||||
|
||||
@@ -1,132 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: REFERENCE
|
||||
[id="cnf-rfhe-notifications-api-refererence_{context}"]
|
||||
= Subscribing applications to bare-metal events REST API reference
|
||||
|
||||
Use the bare-metal events REST API to subscribe an application to the bare-metal events that are generated on the parent node.
|
||||
|
||||
Subscribe applications to Redfish events by using the resource address `/cluster/node/<node_name>/redfish/event`, where `<node_name>` is the cluster node running the application.
|
||||
|
||||
Deploy your `cloud-event-consumer` application container and `cloud-event-proxy` sidecar container in a separate application pod. The `cloud-event-consumer` application subscribes to the `cloud-event-proxy` container in the application pod.
|
||||
|
||||
Use the following API endpoints to subscribe the `cloud-event-consumer` application to Redfish events posted by the `cloud-event-proxy` container at [x-]`http://localhost:8089/api/ocloudNotifications/v1/` in the application pod:
|
||||
|
||||
* `/api/ocloudNotifications/v1/subscriptions`
|
||||
- `POST`: Creates a new subscription
|
||||
- `GET`: Retrieves a list of subscriptions
|
||||
* `/api/ocloudNotifications/v1/subscriptions/<subscription_id>`
|
||||
- `PUT`: Creates a new status ping request for the specified subscription ID
|
||||
* `/api/ocloudNotifications/v1/health`
|
||||
- `GET`: Returns the health status of `ocloudNotifications` API
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
`9089` is the default port for the `cloud-event-consumer` container deployed in the application pod. You can configure a different port for your application as required.
|
||||
====
|
||||
|
||||
[discrete]
|
||||
== api/ocloudNotifications/v1/subscriptions
|
||||
|
||||
[discrete]
|
||||
=== HTTP method
|
||||
|
||||
`GET api/ocloudNotifications/v1/subscriptions`
|
||||
|
||||
[discrete]
|
||||
==== Description
|
||||
|
||||
Returns a list of subscriptions. If subscriptions exist, a `200 OK` status code is returned along with the list of subscriptions.
|
||||
|
||||
.Example API response
|
||||
[source,json]
|
||||
----
|
||||
[
|
||||
{
|
||||
"id": "ca11ab76-86f9-428c-8d3a-666c24e34d32",
|
||||
"endpointUri": "http://localhost:9089/api/ocloudNotifications/v1/dummy",
|
||||
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
|
||||
"resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
|
||||
}
|
||||
]
|
||||
----
|
||||
|
||||
[discrete]
|
||||
=== HTTP method
|
||||
|
||||
`POST api/ocloudNotifications/v1/subscriptions`
|
||||
|
||||
[discrete]
|
||||
==== Description
|
||||
|
||||
Creates a new subscription. If a subscription is successfully created, or if it already exists, a `201 Created` status code is returned.
|
||||
|
||||
.Query parameters
|
||||
|===
|
||||
| Parameter | Type
|
||||
|
||||
| subscription
|
||||
| data
|
||||
|===
|
||||
|
||||
.Example payload
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
|
||||
"resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
|
||||
}
|
||||
----
|
||||
|
||||
[discrete]
|
||||
== api/ocloudNotifications/v1/subscriptions/<subscription_id>
|
||||
|
||||
[discrete]
|
||||
=== HTTP method
|
||||
|
||||
`GET api/ocloudNotifications/v1/subscriptions/<subscription_id>`
|
||||
|
||||
[discrete]
|
||||
==== Description
|
||||
|
||||
Returns details for the subscription with ID `<subscription_id>`
|
||||
|
||||
.Query parameters
|
||||
|===
|
||||
| Parameter | Type
|
||||
|
||||
| `<subscription_id>`
|
||||
| string
|
||||
|===
|
||||
|
||||
.Example API response
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"id":"ca11ab76-86f9-428c-8d3a-666c24e34d32",
|
||||
"endpointUri":"http://localhost:9089/api/ocloudNotifications/v1/dummy",
|
||||
"uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
|
||||
"resource":"/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
|
||||
}
|
||||
----
|
||||
|
||||
[discrete]
|
||||
== api/ocloudNotifications/v1/health/
|
||||
|
||||
[discrete]
|
||||
=== HTTP method
|
||||
|
||||
`GET api/ocloudNotifications/v1/health/`
|
||||
|
||||
[discrete]
|
||||
==== Description
|
||||
|
||||
Returns the health status for the `ocloudNotifications` REST API.
|
||||
|
||||
.Example API response
|
||||
[source,terminal]
|
||||
----
|
||||
OK
|
||||
----
|
||||
@@ -1,54 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="hw-installing-amq-interconnect-messaging-bus_{context}"]
|
||||
= Installing the AMQ messaging bus
|
||||
|
||||
To pass Redfish bare-metal event notifications between publisher and subscriber on a node, you can install and configure an AMQ messaging bus to run locally on the node. You do this by installing the AMQ Interconnect Operator for use in the cluster.
|
||||
|
||||
include::snippets/ptp-amq-interconnect-eol.adoc[]
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Install the {product-title} CLI (`oc`).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
.Procedure
|
||||
|
||||
* Install the AMQ Interconnect Operator to its own `amq-interconnect` namespace. See link:https://access.redhat.com/documentation/en-us/red_hat_amq/2021.q1/html/deploying_amq_interconnect_on_openshift/adding-operator-router-ocp[Installing the AMQ Interconnect Operator].
|
||||
|
||||
.Verification
|
||||
|
||||
. Verify that the AMQ Interconnect Operator is available and the required pods are running:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get pods -n amq-interconnect
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h
|
||||
interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
|
||||
----
|
||||
|
||||
. Verify that the required `bare-metal-event-relay` bare-metal event producer pod is running in the `openshift-bare-metal-events` namespace:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get pods -n openshift-bare-metal-events
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl 2/2 Running 0 25s
|
||||
----
|
||||
|
||||
|
||||
|
||||
@@ -1,168 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-rfhe-creating-bmc-event-sub_{context}"]
|
||||
= Subscribing to bare-metal events
|
||||
|
||||
You can configure the baseboard management controller (BMC) to send bare-metal events to subscribed applications running in an {product-title} cluster. Example Redfish bare-metal events include an increase in device temperature, or removal of a device. You subscribe applications to bare-metal events using a REST API.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
You can only create a `BMCEventSubscription` custom resource (CR) for physical hardware that supports Redfish and has a vendor interface set to `redfish` or `idrac-redfish`.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Use the `BMCEventSubscription` CR to subscribe to predefined Redfish events. The Redfish standard does not provide an option to create specific alerts and thresholds. For example, to receive an alert event when an enclosure's temperature exceeds 40° Celsius, you must manually configure the event according to the vendor's recommendations.
|
||||
====
|
||||
|
||||
Perform the following procedure to subscribe to bare-metal events for the node using a `BMCEventSubscription` CR.
|
||||
|
||||
.Prerequisites
|
||||
* Install the OpenShift CLI (`oc`).
|
||||
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
* Get the user name and password for the BMC.
|
||||
|
||||
* Deploy a bare-metal node with a Redfish-enabled Baseboard Management Controller (BMC) in your cluster, and enable Redfish events on the BMC.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Enabling Redfish events on specific hardware is outside the scope of this information. For more information about enabling Redfish events for your specific hardware, consult the BMC manufacturer documentation.
|
||||
====
|
||||
|
||||
.Procedure
|
||||
|
||||
. Confirm that the node hardware has the Redfish `EventService` enabled by running the following `curl` command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
bmc_ip_address:: is the IP address of the BMC where the Redfish events are generated.
|
||||
--
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
{
|
||||
"@odata.context": "/redfish/v1/$metadata#EventService.EventService",
|
||||
"@odata.id": "/redfish/v1/EventService",
|
||||
"@odata.type": "#EventService.v1_0_2.EventService",
|
||||
"Actions": {
|
||||
"#EventService.SubmitTestEvent": {
|
||||
"EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
|
||||
"target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
|
||||
}
|
||||
},
|
||||
"DeliveryRetryAttempts": 3,
|
||||
"DeliveryRetryIntervalSeconds": 30,
|
||||
"Description": "Event Service represents the properties for the service",
|
||||
"EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
|
||||
"EventTypesForSubscription@odata.count": 5,
|
||||
"Id": "EventService",
|
||||
"Name": "Event Service",
|
||||
"ServiceEnabled": true,
|
||||
"Status": {
|
||||
"Health": "OK",
|
||||
"HealthRollup": "OK",
|
||||
"State": "Enabled"
|
||||
},
|
||||
"Subscriptions": {
|
||||
"@odata.id": "/redfish/v1/EventService/Subscriptions"
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
. Get the {redfish-operator} service route for the cluster by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get route -n openshift-bare-metal-events
|
||||
----
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
|
||||
hw-event-proxy hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com hw-event-proxy-service 9087 edge None
|
||||
----
|
||||
|
||||
. Create a `BMCEventSubscription` resource to subscribe to the Redfish events:
|
||||
|
||||
.. Save the following YAML in the `bmc_sub.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: metal3.io/v1alpha1
|
||||
kind: BMCEventSubscription
|
||||
metadata:
|
||||
name: sub-01
|
||||
namespace: openshift-machine-api
|
||||
spec:
|
||||
hostName: <hostname> <1>
|
||||
destination: <proxy_service_url> <2>
|
||||
context: ''
|
||||
----
|
||||
<1> Specifies the name or UUID of the worker node where the Redfish events are generated.
|
||||
<2> Specifies the bare-metal event proxy service, for example, `https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook`.
|
||||
|
||||
.. Create the `BMCEventSubscription` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f bmc_sub.yaml
|
||||
----
|
||||
|
||||
. Optional: To delete the BMC event subscription, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc delete -f bmc_sub.yaml
|
||||
----
|
||||
|
||||
. Optional: To manually create a Redfish event subscription without creating a `BMCEventSubscription` CR, run the following `curl` command, specifying the BMC username and password.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl -i -k -X POST -H "Content-Type: application/json" -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
proxy_service_url:: is the bare-metal event proxy service, for example, `https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook`.
|
||||
--
|
||||
+
|
||||
--
|
||||
bmc_ip_address:: is the IP address of the BMC where the Redfish events are generated.
|
||||
--
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
HTTP/1.1 201 Created
|
||||
Server: AMI MegaRAC Redfish Service
|
||||
Location: /redfish/v1/EventService/Subscriptions/1
|
||||
Allow: GET, POST
|
||||
Access-Control-Allow-Origin: *
|
||||
Access-Control-Expose-Headers: X-Auth-Token
|
||||
Access-Control-Allow-Headers: X-Auth-Token
|
||||
Access-Control-Allow-Credentials: true
|
||||
Cache-Control: no-cache, must-revalidate
|
||||
Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
|
||||
Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
|
||||
Link: </redfish/v1/EventService/Subscriptions>; path=
|
||||
ETag: "1651135676"
|
||||
Content-Type: application/json; charset=UTF-8
|
||||
OData-Version: 4.0
|
||||
Content-Length: 614
|
||||
Date: Thu, 28 Apr 2022 08:47:57 GMT
|
||||
----
|
||||
@@ -1,88 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-rfhe-creating-hardware-event_{context}"]
|
||||
= Creating the bare-metal event and Secret CRs
|
||||
|
||||
To start using bare-metal events, create the `HardwareEvent` custom resource (CR) for the host where the Redfish hardware is present. Hardware events and faults are reported in the `hw-event-proxy` logs.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have installed the {product-title} CLI (`oc`).
|
||||
|
||||
* You have logged in as a user with `cluster-admin` privileges.
|
||||
|
||||
* You have installed the {redfish-operator}.
|
||||
|
||||
* You have created a `BMCEventSubscription` CR for the BMC Redfish hardware.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create the `HardwareEvent` custom resource (CR):
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Multiple `HardwareEvent` resources are not permitted.
|
||||
====
|
||||
|
||||
.. Save the following YAML in the `hw-event.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: "event.redhat-cne.org/v1alpha1"
|
||||
kind: "HardwareEvent"
|
||||
metadata:
|
||||
name: "hardware-event"
|
||||
spec:
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/hw-event: "" <1>
|
||||
logLevel: "debug" <2>
|
||||
msgParserTimeout: "10" <3>
|
||||
----
|
||||
+
|
||||
--
|
||||
<1> Required. Use the `nodeSelector` field to target nodes with the specified label, for example, `node-role.kubernetes.io/hw-event: ""`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
In {product-title} 4.13 or later, you do not need to set the `spec.transportHost` field in the `HardwareEvent` resource when you use HTTP transport for bare-metal events.
|
||||
Set `transportHost` only when you use AMQP transport for bare-metal events.
|
||||
====
|
||||
<2> Optional. The default value is `debug`. Sets the log level in `hw-event-proxy` logs. The following log levels are available: `fatal`, `error`, `warning`, `info`, `debug`, `trace`.
|
||||
<3> Optional. Sets the timeout value in milliseconds for the Message Parser. If a message parsing request is not responded to within the timeout duration, the original hardware event message is passed to the cloud native event framework. The default value is 10.
|
||||
--
|
||||
|
||||
.. Apply the `HardwareEvent` CR in the cluster:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f hardware-event.yaml
|
||||
----
|
||||
|
||||
. Create a BMC username and password `Secret` CR that enables the hardware events proxy to access the Redfish message registry for the bare-metal host.
|
||||
+
|
||||
.. Save the following YAML in the `hw-event-bmc-secret.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: redfish-basic-auth
|
||||
type: Opaque
|
||||
stringData: <1>
|
||||
username: <bmc_username>
|
||||
password: <bmc_password>
|
||||
# BMC host DNS or IP address
|
||||
hostaddr: <bmc_host_ip_address>
|
||||
----
|
||||
<1> Enter plain text values for the various items under `stringData`.
|
||||
+
|
||||
.. Create the `Secret` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f hw-event-bmc-secret.yaml
|
||||
----
|
||||
@@ -1,96 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-rfhe-installing-operator-cli_{context}"]
|
||||
= Installing the {redfish-operator} using the CLI
|
||||
|
||||
As a cluster administrator, you can install the {redfish-operator} Operator by using the CLI.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* A cluster that is installed on bare-metal hardware with nodes that have a RedFish-enabled Baseboard Management Controller (BMC).
|
||||
* Install the OpenShift CLI (`oc`).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Create a namespace for the {redfish-operator}.
|
||||
|
||||
.. Save the following YAML in the `bare-metal-events-namespace.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: openshift-bare-metal-events
|
||||
labels:
|
||||
name: openshift-bare-metal-events
|
||||
openshift.io/cluster-monitoring: "true"
|
||||
----
|
||||
|
||||
.. Create the `Namespace` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f bare-metal-events-namespace.yaml
|
||||
----
|
||||
|
||||
. Create an Operator group for the {redfish-operator} Operator.
|
||||
|
||||
.. Save the following YAML in the `bare-metal-events-operatorgroup.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1
|
||||
kind: OperatorGroup
|
||||
metadata:
|
||||
name: bare-metal-event-relay-group
|
||||
namespace: openshift-bare-metal-events
|
||||
spec:
|
||||
targetNamespaces:
|
||||
- openshift-bare-metal-events
|
||||
----
|
||||
|
||||
.. Create the `OperatorGroup` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f bare-metal-events-operatorgroup.yaml
|
||||
----
|
||||
|
||||
. Subscribe to the {redfish-operator}.
|
||||
|
||||
.. Save the following YAML in the `bare-metal-events-sub.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: bare-metal-event-relay-subscription
|
||||
namespace: openshift-bare-metal-events
|
||||
spec:
|
||||
channel: "stable"
|
||||
name: bare-metal-event-relay
|
||||
source: redhat-operators
|
||||
sourceNamespace: openshift-marketplace
|
||||
----
|
||||
|
||||
.. Create the `Subscription` CR:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f bare-metal-events-sub.yaml
|
||||
----
|
||||
|
||||
.Verification
|
||||
|
||||
To verify that the {redfish-operator} Operator is installed, run the following command:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase
|
||||
----
|
||||
@@ -1,42 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="nw-rfhe-installing-operator-web-console_{context}"]
|
||||
= Installing the {redfish-operator} using the web console
|
||||
|
||||
As a cluster administrator, you can install the {redfish-operator} Operator using the web console.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* A cluster that is installed on bare-metal hardware with nodes that have a RedFish-enabled Baseboard Management Controller (BMC).
|
||||
* Log in as a user with `cluster-admin` privileges.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Install the {redfish-operator} using the {product-title} web console:
|
||||
|
||||
.. In the {product-title} web console, click *Operators* -> *OperatorHub*.
|
||||
|
||||
.. Choose *{redfish-operator}* from the list of available Operators, and then click *Install*.
|
||||
|
||||
.. On the *Install Operator* page, select or create a *Namespace*, select *openshift-bare-metal-events*, and then click *Install*.
|
||||
|
||||
.Verification
|
||||
|
||||
Optional: You can verify that the Operator installed successfully by performing the following check:
|
||||
|
||||
. Switch to the *Operators* -> *Installed Operators* page.
|
||||
|
||||
. Ensure that *{redfish-operator}* is listed in the project with a *Status* of *InstallSucceeded*.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
During installation an Operator might display a *Failed* status. If the installation later succeeds with an *InstallSucceeded* message, you can ignore the *Failed* message.
|
||||
====
|
||||
|
||||
If the Operator does not appear as installed, to troubleshoot further:
|
||||
|
||||
* Go to the *Operators* -> *Installed Operators* page and inspect the *Operator Subscriptions* and *Install Plans* tabs for any failure or errors under *Status*.
|
||||
* Go to the *Workloads* -> *Pods* page and check the logs for pods in the project namespace.
|
||||
@@ -1,52 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="nw-rfhe-introduction_{context}"]
|
||||
= How bare-metal events work
|
||||
|
||||
The {redfish-operator} 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. These hardware events are delivered using an HTTP transport or AMQP mechanism. The latency of the messaging service is between 10 to 20 milliseconds.
|
||||
|
||||
The {redfish-operator} provides a publish-subscribe service for the hardware events. Applications can use a REST API to subscribe to the events. The {redfish-operator} supports hardware that complies with Redfish OpenAPI v1.8 or later.
|
||||
|
||||
[id="rfhe-elements_{context}"]
|
||||
== {redfish-operator} data flow
|
||||
|
||||
The following figure illustrates an example bare-metal events data flow:
|
||||
|
||||
.{redfish-operator} data flow
|
||||
image::319_OpenShift_redfish_bare-metal_OCP_nodes_0323.png[Bare-metal events data flow]
|
||||
|
||||
=== Operator-managed pod
|
||||
|
||||
The Operator uses custom resources to manage the pod containing the {redfish-operator} and its components using the `HardwareEvent` CR.
|
||||
|
||||
=== {redfish-operator}
|
||||
|
||||
At startup, the {redfish-operator} queries the Redfish API and downloads all the message registries, including custom registries. The {redfish-operator} then begins to receive subscribed events from the Redfish hardware.
|
||||
|
||||
The {redfish-operator} 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.
|
||||
|
||||
=== CNCF CloudEvents
|
||||
|
||||
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.
|
||||
|
||||
=== HTTP transport or AMQP dispatch router
|
||||
|
||||
The HTTP transport or AMQP dispatch router is responsible for the message delivery service between publisher and subscriber.
|
||||
|
||||
include::snippets/ptp-amq-interconnect-eol.adoc[]
|
||||
|
||||
=== Cloud event proxy sidecar
|
||||
|
||||
The cloud event proxy sidecar container image is based on the O-RAN API specification and provides a publish-subscribe event framework for hardware events.
|
||||
|
||||
[id="rfhe-data-flow_{context}"]
|
||||
== Redfish message parsing service
|
||||
|
||||
In addition to handling Redfish events, the {redfish-operator} 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.
|
||||
@@ -1,68 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * scalability_and_performance/using-rfhe.adoc
|
||||
|
||||
:_module-type: PROCEDURE
|
||||
[id="nw-rfhe-querying-redfish-hardware-event-subs_{context}"]
|
||||
= Querying Redfish bare-metal event subscriptions with curl
|
||||
|
||||
Some hardware vendors limit the amount of Redfish hardware event subscriptions. You can query the number of Redfish event subscriptions by using `curl`.
|
||||
|
||||
.Prerequisites
|
||||
* Get the user name and password for the BMC.
|
||||
* Deploy a bare-metal node with a Redfish-enabled Baseboard Management Controller (BMC) in your cluster, and enable Redfish hardware events on the BMC.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Check the current subscriptions for the BMC by running the following `curl` command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
bmc_ip_address:: is the IP address of the BMC where the Redfish events are generated.
|
||||
--
|
||||
+
|
||||
.Example output
|
||||
[source,terminal]
|
||||
----
|
||||
% Total % Received % Xferd Average Speed Time Time Time Current
|
||||
Dload Upload Total Spent Left Speed
|
||||
100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
|
||||
{
|
||||
"@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
|
||||
"@odata.etag": ""
|
||||
1651137375 "",
|
||||
"@odata.id": "/redfish/v1/EventService/Subscriptions",
|
||||
"@odata.type": "#EventDestinationCollection.EventDestinationCollection",
|
||||
"Description": "Collection for Event Subscriptions",
|
||||
"Members": [
|
||||
{
|
||||
"@odata.id": "/redfish/v1/EventService/Subscriptions/1"
|
||||
}],
|
||||
"Members@odata.count": 1,
|
||||
"Name": "Event Subscriptions Collection"
|
||||
}
|
||||
----
|
||||
+
|
||||
In this example, a single subscription is configured: `/redfish/v1/EventService/Subscriptions/1`.
|
||||
|
||||
. Optional: To remove the `/redfish/v1/EventService/Subscriptions/1` subscription with `curl`, run the following command, specifying the BMC username and password:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
bmc_ip_address:: is the IP address of the BMC where the Redfish events are generated.
|
||||
--
|
||||
|
||||
|
||||
|
||||
@@ -1,59 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * edge_computing/ztp-advanced-policy-config.adoc
|
||||
// * edge_computing/ztp-advanced-policygenerator-config.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="ztp-creating-hwevents_{context}"]
|
||||
= Configuring bare-metal events that use HTTP transport
|
||||
|
||||
You can configure bare-metal events that use HTTP transport on managed clusters that you deploy with the {ztp-first} pipeline.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have installed the OpenShift CLI (`oc`).
|
||||
|
||||
* You have logged in as a user with `cluster-admin` privileges.
|
||||
|
||||
* You have created a Git repository where you manage your custom site configuration data.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Configure the {redfish-operator} Operator by adding the following YAML to `{rangen-yaml-path}` in the `{policy-prefix}common-ranGen.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"]
|
||||
include::snippets/pgt-ztp-configuring-hwevents-using-pgt.yaml[]
|
||||
endif::[]
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenerator"]
|
||||
include::snippets/pg-ztp-configuring-hwevents.yaml[]
|
||||
endif::[]
|
||||
----
|
||||
|
||||
. Add the `HardwareEvent` CR to `{rangen-yaml-path}` in your specific group configuration file, for example, in the `{policy-prefix}group-du-sno-ranGen.yaml` file:
|
||||
+
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"]
|
||||
include::snippets/pgt-ztp-configuring-hwevents-using-pgt-hardware-event.adoc[]
|
||||
endif::[]
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenerator"]
|
||||
include::snippets/pg-ztp-configuring-hwevents-using-pgt-hardware-event.adoc[]
|
||||
endif::[]
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
In {product-title} 4.13 or later, you do not need to set the `transportHost` field in the `HardwareEvent` custom resource (CR) when you use HTTP transport with bare-metal events.
|
||||
====
|
||||
|
||||
. Merge any other required changes and files with your custom site repository.
|
||||
|
||||
. Push the changes to your site configuration repository to deploy bare-metal events to new sites with {ztp}.
|
||||
|
||||
. Create the Redfish Secret by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
|
||||
--from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
|
||||
--from-literal=hostaddr="<bmc_host_ip_addr>"
|
||||
----
|
||||
@@ -1,72 +0,0 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * edge_computing/ztp-advanced-policy-config.adoc
|
||||
// * edge_computing/ztp-advanced-policygenerator-config.adoc
|
||||
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="ztp-creating-hwevents-amqp_{context}"]
|
||||
= Configuring bare-metal events that use AMQP transport
|
||||
|
||||
You can configure bare-metal events that use AMQP transport on managed clusters that you deploy with the {ztp-first} pipeline.
|
||||
|
||||
include::snippets/ptp-amq-interconnect-eol.adoc[]
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have installed the OpenShift CLI (`oc`).
|
||||
|
||||
* You have logged in as a user with `cluster-admin` privileges.
|
||||
|
||||
* You have created a Git repository where you manage your custom site configuration data.
|
||||
|
||||
.Procedure
|
||||
|
||||
. To configure the AMQ Interconnect Operator and the {redfish-operator} Operator, add the following YAML to `{rangen-yaml-path}` in the `{policy-prefix}common-ranGen.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"]
|
||||
include::snippets/pgt-ztp-creating-hwevents-amqp.yaml[]
|
||||
endif::[]
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenerator"]
|
||||
include::snippets/pg-ztp-creating-hwevents-amqp.yaml[]
|
||||
endif::[]
|
||||
----
|
||||
|
||||
. Add the `Interconnect` CR to `{rangen-yaml-path}` in the site configuration file, for example, the `{policy-prefix}example-sno-site.yaml` file:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"]
|
||||
- fileName: AmqInstance.yaml
|
||||
policyName: "config-policy"
|
||||
endif::[]
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenerator"]
|
||||
- path: source-crs/AmqInstance.yaml
|
||||
endif::[]
|
||||
----
|
||||
|
||||
. Add the `HardwareEvent` CR to `{rangen-yaml-path}` in your specific group configuration file, for example, in the `{policy-prefix}group-du-sno-ranGen.yaml` file:
|
||||
+
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"]
|
||||
include::snippets/ztp-creating-hwevents-amqp-hardware-event.adoc[]
|
||||
endif::[]
|
||||
ifeval::["{policy-gen-cr}" == "PolicyGenerator"]
|
||||
include::snippets/ztp-creating-hwevents-amqp-hardware-event.adoc[]
|
||||
endif::[]
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Each baseboard management controller (BMC) requires a single `HardwareEvent` resource only.
|
||||
====
|
||||
|
||||
. Commit the `{policy-gen-cr}` change in Git, and then push the changes to your site configuration repository to deploy bare-metal events monitoring to new sites using {ztp}.
|
||||
|
||||
. Create the Redfish Secret by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
|
||||
--from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
|
||||
--from-literal=hostaddr="<bmc_host_ip_addr>"
|
||||
----
|
||||
@@ -23,8 +23,6 @@ include::modules/cluster-bare-metal-operator.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
* xref:../installing/overview/cluster-capabilities.adoc#cluster-bare-metal-operator_cluster-capabilities[Bare-metal capability]
|
||||
|
||||
include::modules/baremetal-event-relay.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/cloud-credential-operator.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
:_mod-docs-content-type: SNIPPET
|
||||
[NOTE]
|
||||
====
|
||||
HTTP transport is the default transport for PTP and bare-metal events.
|
||||
Use HTTP transport instead of AMQP for PTP and bare-metal events where possible.
|
||||
HTTP transport is the default transport for PTP.
|
||||
Use HTTP transport instead of AMQP for PTP where possible.
|
||||
AMQ Interconnect is EOL from 30 June 2024.
|
||||
Extended life cycle support (ELS) for AMQ Interconnect ends 29 November 2029.
|
||||
For more information see, link:https://access.redhat.com/support/policy/updates/jboss_notes#p_Interconnect[Red Hat AMQ Interconnect support status].
|
||||
|
||||
Reference in New Issue
Block a user