Skip to content

Commit b5f195c

Browse files
committed
OSDOCS-8938: Cluster notifications docs for Managed OpenShift
1 parent 0b33f21 commit b5f195c

25 files changed

+354
-38
lines changed

_topic_maps/_topic_map_osd.yml

+3
Original file line numberDiff line numberDiff line change
@@ -339,6 +339,9 @@ Name: Cluster administration
339339
Dir: osd_cluster_admin
340340
Distros: openshift-dedicated
341341
Topics:
342+
- Name: Cluster notifications
343+
File: osd-cluster-notifications
344+
Distros: openshift-dedicated
342345
- Name: Configuring private connections
343346
Dir: osd_private_connections
344347
Distros: openshift-dedicated

_topic_maps/_topic_map_rosa.yml

+3
Original file line numberDiff line numberDiff line change
@@ -554,6 +554,9 @@ Topics:
554554
# File: rosa-cluster-auth
555555
# - Name: Authorization and RBAC
556556
# File: rosa-auth-rbac
557+
- Name: Cluster notifications
558+
File: rosa-cluster-notifications
559+
Distros: openshift-rosa
557560
- Name: Configuring private connections
558561
Dir: cloud_infrastructure_access
559562
Distros: openshift-rosa

_topic_maps/_topic_map_rosa_hcp.yml

+8-5
Original file line numberDiff line numberDiff line change
@@ -541,17 +541,20 @@ Topics:
541541
# File: ocm-overview
542542
# - Name: Using the OpenShift web console
543543
# File: rosa-using-openshift-console
544-
# ---
545-
# Name: Cluster administration
546-
# Dir: rosa_cluster_admin
547-
# Distros: openshift-rosa-hcp
548-
# Topics:
544+
---
545+
Name: Cluster administration
546+
Dir: rosa_cluster_admin
547+
Distros: openshift-rosa-hcp
548+
Topics:
549549
# - Name: Cluster configurations
550550
# File: rosa-cluster-config
551551
# - Name: Cluster authentication
552552
# File: rosa-cluster-auth
553553
# - Name: Authorization and RBAC
554554
# File: rosa-auth-rbac
555+
- Name: Cluster notifications
556+
File: rosa-cluster-notifications
557+
Distros: openshift-rosa-hcp
555558
# - Name: Configuring private connections
556559
# Dir: cloud_infrastructure_access
557560
# Distros: openshift-rosa-hcp
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: CONCEPT
7+
[id="add-notification-contact_{context}"]
8+
= Adding notification contacts to your cluster
9+
10+
Notification contacts receive emails when cluster notifications are sent to the cluster.
11+
By default, only the cluster owner receives cluster notification emails. You can configure other cluster users as additional notification contacts in your cluster support settings.
12+
13+
.Prerequisites
14+
* Your cluster is deployed and registered to the {hybrid-console}.
15+
* You are logged in to the {hybrid-console-second}.
16+
* The intended notification recipient has a user account on your cluster.
17+
18+
.Procedure
19+
. Navigate to the Clusters page of the {hybrid-console-second}.
20+
. Click the name of your cluster to go to the cluster details page.
21+
. Click the **Support** tab.
22+
. On the **Support** tab, find the **Notification contacts** section.
23+
. Click **Add notification contact**.
24+
. In the **Red Hat username or email** field, enter the email address or the user name of the new recipient.
25+
//. In the type field, select the types of cluster notification to send to this recipient.
26+
. Click **Add contact**.
27+
28+
.Verification steps
29+
* The "Notification contact added successfully" message displays.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: PROCEDURE
7+
[id="config-notification-types-received_{context}"]
8+
= Configuring notification types received
9+
10+
Notification contacts receive emails when cluster notifications are sent to the cluster.
11+
12+
By default, a notification contact receives an email for every notification sent to the cluster, regardless of notification type. You can configure the type of notification you want to receive in the {hybrid-console} notification settings for OpenShift.
13+
14+
.Prerequisites
15+
* Your cluster is deployed and registered to the {hybrid-console-second}.
16+
* You are logged in to the {hybrid-console-second}.
17+
18+
.Procedure
19+
. Log in to the {hybrid-console-second}.
20+
. Click **Settings** -> **Notifications** to open the Notifications overview.
21+
. Click **Notification Preferences**.
22+
. On the My Notifications page, under OpenShift, click **Cluster Manager**.
23+
. Specify the notification types that you want to receive by selecting or clearing the relevant checkbox.
24+
. Click **Save**.
25+
26+
.Verification steps
27+
* The "Notification preferences successfully saved" message displays.
28+
29+
// .Additional resources
30+
// * Cluster notification types
31+
// * Configuring notifications on Hybrid Cloud Console
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: CONCEPT
7+
[id="managed-cluster-notification-policy_{context}"]
8+
= Cluster notification policy
9+
10+
Cluster notifications are designed to keep you informed about the health of your cluster and high impact events that affect it.
11+
12+
Most cluster notifications are generated and sent automatically to ensure that you are immediately informed of problems or important changes to the state of your cluster.
13+
14+
In certain situations, Red Hat Site Reliability Engineering (SRE) creates and sends cluster notifications to provide additional context and guidance for a complex issue.
15+
16+
Cluster notifications are not sent for low-impact events, low-risk security updates, routine operations and maintenance, or minor, transient issues that are quickly resolved by SRE.
17+
18+
Red Hat services automatically send notifications when:
19+
20+
* Remote health monitoring or environment verification checks detect an issue in your cluster, for example, when a worker node has low disk space.
21+
* Significant cluster life cycle events occur, for example, when scheduled maintenance or upgrades begin, or cluster operations are impacted by an event, but do not require customer intervention.
22+
* Significant cluster management changes occur, for example, when cluster ownership or administrative control is transferred from one user to another.
23+
* Your cluster subscription is changed or updated, for example, when Red Hat makes updates to subscription terms or features available to your cluster.
24+
25+
SRE creates and sends notifications when:
26+
27+
* An incident results in a degradation or outage that impacts your cluster's availability or performance, for example, your cloud provider has a regional outage. SRE sends subsequent notifications to inform you of incident resolution progress, and when the incident is resolved.
28+
* A security vulnerability, security breach, or unusual activity is detected on your cluster.
29+
* Red Hat detects that changes you have made are creating or may result in cluster instability.
30+
* Red Hat detects that your workloads are causing performance degradation or instability in your cluster.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: REFERENCE
7+
[id="managed-cluster-notification-severity_{context}"]
8+
= Cluster notification severity levels
9+
10+
Each cluster notification has an associated severity level to help you identify notifications with the greatest impact to your business. You can filter cluster notifications according to these severity levels in the {hybrid-console}, in the **Cluster history** tab for your cluster.
11+
12+
Red Hat uses the following severity levels for cluster notifications, from most to least severe:
13+
14+
Critical:: Immediate action is required. One or more key functions of a service or cluster is not working, or will stop working soon. A critical alert is important enough to page on-call staff and interrupt regular workflows.
15+
Major:: Immediate action is strongly recommended. One or more key functions of the cluster will soon stop working. A major issue may lead to a critical issue if it is not addressed in a timely manner.
16+
Warning:: Action is required as soon as possible. One or more key functions of the cluster are not working optimally and may degrade further, but do not pose an immediate danger to the functioning of the cluster.
17+
Info:: No action necessary. This severity does not describe problems that need to be addressed, only important information about meaningful or important life cycle, service, or cluster events.
18+
Debug:: No action necessary. Debug notifications provide low-level information about less important lifecycle, service, or cluster events to aid in debugging unexpected behavior.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: REFERENCE
7+
[id="managed-cluster-notification-types_{context}"]
8+
= Cluster notification types
9+
10+
Each cluster notification has an associated notification type to help you identify notifications that are relevant to your role and responsibilities. You can filter cluster notifications according to these types in the {hybrid-console}, in the **Cluster history** tab for your cluster.
11+
12+
Red Hat uses the following notification types to indicate notification relevance.
13+
14+
Capacity management:: Notifications for events related to updating, creating, or deleting node pools, machine pools, compute replicas or quotas (load balancer, storage, etc.).
15+
Cluster access:: Notifications for events related to adding or deleting groups, roles or identity providers, for example, when SRE cannot access your cluster because STS credentials have expired, when there is a configuration problem with your AWS roles, or when you add or remove identity providers.
16+
Cluster add-ons:: Notifications for events related to add-on management or upgrade maintenance for add-ons, for example, when an add-on is installed, upgraded, or removed, or cannot be installed due to unmet requirements.
17+
Cluster configuration:: Notifications for cluster tuning events, workload monitoring, and inflight checks.
18+
Cluster lifecycle:: Notifications for cluster or cluster resource creation, deletion, and registration, or change in cluster or resource status (for example, ready or hibernating).
19+
Cluster networking:: Notifications related to cluster networking, including HTTP/S proxy, router, and ingress state.
20+
Cluster ownership:: Notifications related to cluster ownership transfer from one user to another.
21+
Cluster scaling:: Notifications related to updating, creating, or deleting node pools, machine pools, compute replicas or quota.
22+
Cluster security:: Events related to cluster security, for example, an increased number of failed access attempts, updates to trust bundles, or software updates with security impact.
23+
Cluster subscription:: Cluster expiration, trial cluster notifications, or switching from free to paid.
24+
Cluster updates:: Anything relating to upgrades, such as upgrade maintenance or enablement.
25+
Customer support:: Updates on support case status.
26+
General notification:: The default notification type. This is only used for notifications that do not have a more specific category.
27+
// Omitted, as no definition provided as part of OSDOCS-8938
28+
// cluster-state-updates
29+
// clustercreate-details
30+
// clustercreate-high-level
31+
// clusterremove-details
32+
// clusterremove-high-level
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: PROCEDURE
7+
[id="managed-cluster-notification-view-hcc_{context}"]
8+
= Viewing cluster notifications using the {hybrid-console}
9+
10+
Cluster notifications provide important information about the health of your cluster. You can view notifications that have been sent to your cluster in the **Cluster history** tab on the {hybrid-console}.
11+
12+
.Prerequisites
13+
* You are logged in to the {hybrid-console-second}.
14+
15+
.Procedure
16+
. Navigate to the link:https://console.redhat.com/openshift[Clusters] page of the {hybrid-console-second}.
17+
. Click the name of your cluster to go to the cluster details page.
18+
. Click the **Cluster history** tab.
19+
+
20+
Cluster notifications appear under the Cluster history heading.
21+
. Optional: Filter for relevant cluster notifications
22+
+
23+
Use the filter controls to hide cluster notifications that are not relevant to you, so that you can focus on your area of expertise or on resolving a critical issue. You can filter notifications based on text in the notification description, severity level, notification type, when the notification was received, and which system or person triggered the notification.
24+
25+
// .Additional resources
26+
// * Cluster notification types
27+
// * Cluster notification severity levels
28+
// * Cluster notification emails
29+
// * Troubleshooting: Cluster notifications
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * rosa_cluster_admin/rosa-cluster-notifications.adoc
4+
// * osd_cluster_admin/osd-cluster-notifications.adoc
5+
6+
:_mod-docs-content-type: CONCEPT
7+
[id="remove-notification-contact_{context}"]
8+
= Removing notification contacts from your cluster
9+
10+
Notification contacts receive emails when cluster notifications are sent to the cluster.
11+
12+
You can remove notification contacts in your cluster support settings to prevent them from receiving notification emails.
13+
14+
.Prerequisites
15+
* Your cluster is deployed and registered to the {hybrid-console}.
16+
* You are logged in to the {hybrid-console-second}.
17+
18+
.Procedure
19+
. Navigate to the Clusters page of the {hybrid-console-second}.
20+
. Click the name of your cluster to go to the cluster details page.
21+
. Click the **Support** tab.
22+
. On the **Support** tab, find the **Notification contacts** section.
23+
. Click the options menu (**⚙**) beside the recipient you want to remove.
24+
. Click **Delete**.
25+
26+
.Verification steps
27+
* The "Notification contact deleted successfully" message displays.

modules/policy-incident.adoc

+3-14
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,9 @@
55
[id="policy-incident_{context}"]
66
= Incident and operations management
77

8-
9-
This documentation details the Red Hat responsibilities for the {product-title} managed service.
8+
This documentation details the Red Hat responsibilities for the {product-title} managed service.
9+
The cloud provider is responsible for protecting the hardware infrastructure that runs the services offered by the cloud provider.
10+
The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
1011

1112
[id="platform-monitoring_{context}"]
1213
== Platform monitoring
@@ -27,18 +28,6 @@ The general workflow of how a new incident is managed by Red Hat:
2728
. The incident is documented and a root cause analysis is performed within 5 business days of the incident.
2829
. A root cause analysis (RCA) draft document is shared with the customer within 7 business days of the incident.
2930

30-
[id="notifications_{context}"]
31-
== Notifications
32-
Platform notifications are configured using email. Any customer notification is also sent to the corresponding Red Hat account team and if applicable, the Red Hat Technical Account Manager.
33-
34-
The following activities can trigger notifications:
35-
36-
* Platform incident
37-
* Performance degradation
38-
* Cluster capacity warnings
39-
* Critical vulnerabilities and resolution
40-
* Upgrade scheduling
41-
4231
[id="backup-recovery_{context}"]
4332
== Backup and recovery
4433
All {product-title} clusters are backed up using cloud provider snapshots. Notably, this does not include customer data stored on persistent volumes (PVs). All snapshots are taken using the appropriate cloud provider snapshot APIs and are uploaded to a secure object storage bucket (S3 in AWS, and GCS in Google Cloud) in the same account as the cluster.

modules/policy-shared-responsibility.adoc

+1-1
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ The customer and Red Hat share responsibility for the monitoring and maintenance
1010

1111
[id="incident-operations-management_{context}"]
1212
== Incident and operations management
13-
The customer is responsible for incident and operations management of customer application data and any custom networking the customer might have configured for the cluster network or virtual network.
13+
The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
1414

1515
[cols= "2a,3a,3a",options="header"]
1616
|===

modules/rosa-policy-incident.adoc

+1-13
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
= Incident and operations management
77

88
Red Hat is responsible for overseeing the service components required for default platform networking.
9-
AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the AWS Cloud. The customer is responsible for incident and operations management of customer application data and any custom networking the customer may have configured for the cluster network or virtual network.
9+
AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the AWS Cloud. The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
1010

1111
[cols= "2a,3a,3a",options="header"]
1212
|===
@@ -116,18 +116,6 @@ Red Hat can assist with activities including but not limited to:
116116
* Guiding compute image collection
117117
* Providing collected audit logs
118118

119-
[id="rosa-policy-notifications_{context}"]
120-
== Notifications
121-
Platform notifications are configured using email. Some customer notifications are also sent to an account's corresponding Red Hat account team, including a Technical Account Manager, if applicable.
122-
123-
The following activities can trigger notifications:
124-
125-
- Platform incident
126-
- Performance degradation
127-
- Cluster capacity warnings
128-
- Critical vulnerabilities and resolution
129-
- Upgrade scheduling
130-
131119
//Note: The following content will be used again in the future (per OSDOCS:4654)
132120
//[id="backup-recovery_{context}"]
133121
//== Backup and recovery

modules/rosa-sdpolicy-monitoring.adoc

+2-2
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,6 @@ This section provides information about the service definition for {product-titl
1616
{product-title} clusters come with an integrated Prometheus stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by an {product-title} user.
1717

1818
[id="rosa-sdpolicy-cluster-status-notifications_{context}"]
19-
== Cluster status notification
19+
== Cluster notifications
2020

21-
Red Hat communicates the health and status of {product-title} clusters through a combination of a cluster dashboard available in {cluster-manager}, and email notifications sent to the email address of the contact that originally deployed the cluster, and any additional contacts specified by the customer.
21+
include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]

modules/sdpolicy-monitoring.adoc

+2-2
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,6 @@
1111
{product-title} clusters come with an integrated Prometheus/Grafana stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console and can also be used to view cluster-level status and capacity/usage through a Grafana dashboard. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by an {product-title} user.
1212

1313
[id="cluster-status-notification_{context}"]
14-
== Cluster status notification
14+
== Cluster notifications
1515

16-
Red Hat communicates the health and status of {product-title} clusters through a combination of a cluster dashboard available in {cluster-manager-first}, and email notifications sent to the email address of the contact that originally deployed the cluster.
16+
include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]

osd_architecture/osd_policy/policy-process-security.adoc

+7
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,13 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
66

77
toc::[]
88

9+
[id="review-action-notifications_{context}"]
10+
== Review and action cluster notifications
11+
12+
include::snippets/managed-openshift-about-cluster-notifications.adoc[leveloffset=+0]
13+
include::modules/managed-cluster-notification-policy.adoc[leveloffset=+2]
14+
15+
//---
916
1017
include::modules/policy-incident.adoc[leveloffset=+1]
1118
include::modules/policy-change-management.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)