You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: support/troubleshooting/sd-managed-resources.adoc
+106-4Lines changed: 106 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -9,27 +9,38 @@ toc::[]
9
9
[id="sd-managed-resources-overview_{context}"]
10
10
== Overview
11
11
12
-
The following covers all {product-title} resources that are managed or protected by the Service Reliability Engineering Platform (SRE-P) Team. Customers should not try to change these resources because doing so can lead to cluster instability.
12
+
The following covers all {product-title} resources that are managed or protected by the Service Reliability Engineering Platform (SRE-P) Team. Customers must not modify these resources because doing so can lead to cluster instability.
13
13
14
14
[id="sd-managed-resources-all_{context}"]
15
+
ifdef::openshift-rosa,openshift-dedicated[]
15
16
== Hive managed resources
16
17
17
-
The following list displays the {product-title} resources managed by OpenShift Hive, the centralized fleet configuration management system. These resources are in addition to the OpenShift Container Platform resources created during installation. OpenShift Hive continually attempts to maintain consistency across all {product-title} clusters. Changes to {product-title} resources should be made through {cluster-manager} so that {cluster-manager} and Hive are synchronized. Contact ocm-feedback@redhat.com if {cluster-manager} does not support modifying the resources in question.
18
+
The following list displays the {product-title} resources managed by OpenShift Hive, the centralized fleet configuration management system. These resources are in addition to the OpenShift Container Platform resources created during installation. OpenShift Hive continually attempts to maintain consistency across all {product-title} clusters. Changes to {product-title} resources should be made through {cluster-manager} so that {cluster-manager} and Hive are synchronized. Contact `ocm-feedback@redhat.com` if {cluster-manager} does not support modifying the resources in question.
18
19
19
20
.List of Hive managed resources
21
+
endif::openshift-rosa,openshift-dedicated[]
22
+
ifdef::openshift-rosa-hcp[]
23
+
== Red{nbsp}Hat managed resources
24
+
25
+
The following resources are created and managed by the management cluster, which is managed by Red{nbsp}Hat.
{product-title} add-ons are services available for installation after cluster installation. These additional services include {openshift-dev-spaces-productname}, Red{nbsp}Hat OpenShift API Management, and Cluster Logging Operator. Any changes to resources within the following namespaces can be overridden by the add-on during upgrades, which can lead to unsupported configurations for the add-on functionality.
146
+
{product-title} add-ons are services available for installation after cluster installation. These additional services include AWS CloudWatch, {openshift-dev-spaces-productname}, Red{nbsp}Hat OpenShift API Management, and Cluster Logging Operator. Any changes to resources within the following namespaces might be overridden by the add-on during upgrades, which can lead to unsupported configurations for the add-on functionality.
{product-title} validating webhooks are a set of dynamic admission controls maintained by the OpenShift SRE team. These HTTP callbacks, also known as webhooks, are called for various types of requests to ensure cluster stability. The following list describes the various webhooks with rules containing the registered operations and resources that are controlled. Any attempt to circumvent these validating webhooks could affect the stability and supportability of the cluster.
161
+
{product-title} validating webhooks are a set of dynamic admission controls maintained by the OpenShift SRE team. These HTTP callbacks, also known as webhooks, are called for various types of requests to ensure cluster stability. The webhooks evaluate each request and either accept or reject them. The following list describes the various webhooks with rules containing the registered operations and resources that are controlled. Any attempt to circumvent these validating webhooks could affect the stability and supportability of the cluster.
0 commit comments