gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, you now have the option to configure the Kernel Module Management (KMM) module to not load an out-of-tree kernel driver and use the in-tree driver instead, and run only the device plugin. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-intree-modules_kernel-module-management-operator[Using in-tree modules with the device plugin].
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, KMM configurations are now persistent after cluster and KMM Operator upgrades and redeployments of KMM.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: In earlier releases, a cluster or KMM upgrade or any other action, such as upgrading a non-default configuration like the firmware path that redeploys KMM, could create the need to reconfigure KMM. In this release, KMM configurations now remain persistent regardless of any of such actions.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * Improvements have been added to KMM so that GPU Operator vendors do not need to replicate KMM functionality in their code, but instead use KMM as is. This change greatly improves Operators' code size, tests, and reliability.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * In this release, KMM no longer uses HTTP(S) direct requests to check if a kmod image exists. Instead, CRI-O is used internally to check for the images. This mitigates the need to access container image registries directly from HTTP(S) requests and manually handle tasks such as reading `/etc/containers/registries.conf` for mirroring configuration, accessing the image cluster resource for TLS configuration, mounting the CAs from the node, and maintaining your own cache in Hub & Spoke.
Original: * You can now schedule KMM pods by defining taints and tolerations. For more information, see xref:../hardware_enablement/kmm-kernel-module-management.adoc#kmm-using-tolerations-for-kernel-module-scheduling_kernel-module-management-operator[Using tolerations for kernel module scheduling].
Revised: * You can now install KMM on compute nodes, if needed. Previously, it was not possible to deploy workloads on the control-plane nodes. Because the compute nodes do not have the `node-role.kubernetes.io/control-plane` or `node-role.kubernetes.io/master` labels, the Kernel Module Management Operator might need further configurations. An internal code change has resolved this issue.
Original: The Central DB component now uses PostgreSQL 15, and {product-title-short} 4.8
supports this version for external databases. A new installation with an
internal database now uses this version by default. When upgrading an existing
cluster to {product-title-short} 4.8, Central DB will perform an upgrade of the
data it has collected.
* If you are not upgrading by using the Operator, check the disk space
available for the database by viewing the
`rox_central_postgres_available_size_bytes` metric. For the purposes of the
upgrade, the value should be double the amount of the already-consumed disk
space, as shown in the `rox_central_postgres_total_size_bytes` metric. If the
value is not correct, extend the database PVC.
* Do not interrupt the upgrade procedure. If the upgrade is interrupted, a
manual intervention might be required to proceed.
Depending on the amount of data, the upgrade can take extra time to finish.
====
[id="notable-technical-changes-rn-48_{context}"]
Revised: By default, this feature is disabled. However, when enabled, you see external IPs in the Network Graph. Additionally, Unauthorized Network Flow violations automatically include detailed external IP information, which streamlines your investigation process.
Original: The Central DB component now uses PostgreSQL 15, and {product-title-short} 4.8
supports this version for external databases. A new installation with an
internal database now uses this version by default. When upgrading an existing
cluster to {product-title-short} 4.8, Central DB will perform an upgrade of the
data it has collected.
* If you are not upgrading by using the Operator, check the disk space
available for the database by viewing the
`rox_central_postgres_available_size_bytes` metric. For the purposes of the
upgrade, the value should be double the amount of the already-consumed disk
space, as shown in the `rox_central_postgres_total_size_bytes` metric. If the
value is not correct, extend the database PVC.
* Do not interrupt the upgrade procedure. If the upgrade is interrupted, a
manual intervention might be required to proceed.
Depending on the amount of data, the upgrade can take extra time to finish.
====
[id="notable-technical-changes-rn-48_{context}"]
Revised: * {product-title-short} 4.8 preserves the current scanner configuration for existing deployments that you upgrade. If you are using the StackRox Scanner, it remains in use after the upgrade. For switching to Scanner V4, see xref:../operating/examine-images-for-vulnerabilities.adoc#enabling_scanner_v4_examine-images-for-vulnerabilities[Enabling Scanner V4].
Original: The Central DB component now uses PostgreSQL 15, and {product-title-short} 4.8
supports this version for external databases. A new installation with an
internal database now uses this version by default. When upgrading an existing
cluster to {product-title-short} 4.8, Central DB will perform an upgrade of the
data it has collected.
* If you are not upgrading by using the Operator, check the disk space
available for the database by viewing the
`rox_central_postgres_available_size_bytes` metric. For the purposes of the
upgrade, the value should be double the amount of the already-consumed disk
space, as shown in the `rox_central_postgres_total_size_bytes` metric. If the
value is not correct, extend the database PVC.
* Do not interrupt the upgrade procedure. If the upgrade is interrupted, a
manual intervention might be required to proceed.
Depending on the amount of data, the upgrade can take extra time to finish.
====
[id="notable-technical-changes-rn-48_{context}"]
Revised: * Red Hat has moved the `SecurityPolicy`` Custom Resource Definition (CRD) to the template directory within the Helm chart. This change simplifies CRD maintenance if you are using Helm, as it now automatically upgrades.
Original: You can expose controller metrics for the {cert-manager-operator} in the format provided by the Prometheus Operator.
// Enabling metrics for the {cert-manager-operator}
include::modules/cert-manager-enable-metrics.adoc[leveloffset=+1]
* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#setting-up-metrics-collection-for-user-defined-projects_configuring-metrics-uwm[Setting up metrics collection for user-defined projects]
Revised: [role="_additional-resources"]
.Additional resources

* xref:../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Configuring user workload monitoring]
Original: You can expose controller metrics for the {cert-manager-operator} in the format provided by the Prometheus Operator.
// Enabling metrics for the {cert-manager-operator}
include::modules/cert-manager-enable-metrics.adoc[leveloffset=+1]
* xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#setting-up-metrics-collection-for-user-defined-projects_configuring-metrics-uwm[Setting up metrics collection for user-defined projects]
Revised: * xref:../../observability/monitoring/configuring-user-workload-monitoring/configuring-metrics-uwm.adoc#setting-up-metrics-collection-for-user-defined-projects_configuring-metrics-uwm[Setting up metrics collection for user-defined projects]
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
* You have access to the cluster with `cluster-admin` privileges.
* The {cert-manager-operator} is installed.
. Add the label to enable cluster monitoring by running the following command:
+
[source,terminal]
----
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
----

. Create a service monitor:
.. Create a YAML file that defines the `Role`, `RoleBinding`, and `ServiceMonitor` objects:
.Example `monitoring.yaml` file

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-k8s
namespace: cert-manager
rules:
- apiGroups:
- ""
resources:
- services
- endpoints
- pods
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-k8s
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: prometheus-k8s
subjects:
- kind: ServiceAccount
name: prometheus-k8s
namespace: openshift-monitoring
---
app.kubernetes.io/component: controller
- interval: 30s
port: tcp-prometheus-servicemonitor
scheme: http
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: cert-manager
app.kubernetes.io/name: cert-manager
.. Create the `Role`, `RoleBinding`, and `ServiceMonitor` objects by running the following command:
$ oc create -f monitoring.yaml
----
Revised: $ oc apply -f servicemonitor-cert-manager.yaml
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
* You have access to the cluster with `cluster-admin` privileges.
* The {cert-manager-operator} is installed.
. Add the label to enable cluster monitoring by running the following command:
+
[source,terminal]
----
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
----

. Create a service monitor:
.. Create a YAML file that defines the `Role`, `RoleBinding`, and `ServiceMonitor` objects:
.Example `monitoring.yaml` file

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-k8s
namespace: cert-manager
rules:
- apiGroups:
- ""
resources:
- services
- endpoints
- pods
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-k8s
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: prometheus-k8s
subjects:
- kind: ServiceAccount
name: prometheus-k8s
namespace: openshift-monitoring
---
app.kubernetes.io/component: controller
- interval: 30s
port: tcp-prometheus-servicemonitor
scheme: http
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: cert-manager
app.kubernetes.io/name: cert-manager
.. Create the `Role`, `RoleBinding`, and `ServiceMonitor` objects by running the following command:
$ oc create -f monitoring.yaml
----
Revised: . In the *Label* filter field, enter the following labels to filter the metrics targets for each operand:

[source,terminal]
$ service=cert-manager

[source,terminal]
$ service=cert-manager-webhook

[source,terminal]
$ service=cert-manager-cainjector
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
* You have access to the cluster with `cluster-admin` privileges.
* The {cert-manager-operator} is installed.
. Add the label to enable cluster monitoring by running the following command:
+
[source,terminal]
----
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
----

. Create a service monitor:
.. Create a YAML file that defines the `Role`, `RoleBinding`, and `ServiceMonitor` objects:
.Example `monitoring.yaml` file

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-k8s
namespace: cert-manager
rules:
- apiGroups:
- ""
resources:
- services
- endpoints
- pods
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-k8s
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: prometheus-k8s
subjects:
- kind: ServiceAccount
name: prometheus-k8s
namespace: openshift-monitoring
---
app.kubernetes.io/component: controller
- interval: 30s
port: tcp-prometheus-servicemonitor
scheme: http
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: cert-manager
app.kubernetes.io/name: cert-manager
.. Create the `Role`, `RoleBinding`, and `ServiceMonitor` objects by running the following command:
$ oc create -f monitoring.yaml
----
Revised: . Confirm that the *Status* column shows `Up` for the `cert-manager`, `cert-manager-webhook`, and `cert-manager-cainjector` entries.
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
Revised: . In the query field, enter the following PromQL expressions to query the cert-manager operands metric for each operand:
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
[source,promql]
Revised: [source,promql]
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
[source,promql]
{instance="<endpoint>"} <1>
Revised: {job="cert-manager"}
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
[source,promql]
{instance="<endpoint>"} <1>
<1> Replace `<endpoint>` with the value of the endpoint for the `cert-manager` service. You can find the endpoint value by running the following command: `oc describe service cert-manager -n cert-manager`.

** Specify the `tcp-prometheus-servicemonitor` port:
[source,promql]
Revised: [source,promql]
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
[source,promql]
{instance="<endpoint>"} <1>
<1> Replace `<endpoint>` with the value of the endpoint for the `cert-manager` service. You can find the endpoint value by running the following command: `oc describe service cert-manager -n cert-manager`.

** Specify the `tcp-prometheus-servicemonitor` port:
[source,promql]
{endpoint="tcp-prometheus-servicemonitor"}
----
Revised: {job="cert-manager-webhook"}
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
[source,promql]
{instance="<endpoint>"} <1>
<1> Replace `<endpoint>` with the value of the endpoint for the `cert-manager` service. You can find the endpoint value by running the following command: `oc describe service cert-manager -n cert-manager`.

** Specify the `tcp-prometheus-servicemonitor` port:
[source,promql]
{endpoint="tcp-prometheus-servicemonitor"}
----
Revised: [source, promql]
{job="cert-manager-cainjector"}
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
Revised: The {cert-manager-operator} operands exposes metrics by default on port `9402` at the `/metrics` service endpoint. You can configure metrics collection for the cert-manager operands by creating a `ServiceMonitor` custom resource (CR) that enables Prometheus Operator to collect custom metrics. For more information, see "Configuring user workload monitoring".
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
* You have access to the cluster with `cluster-admin` privileges.
* The {cert-manager-operator} is installed.
. Add the label to enable cluster monitoring by running the following command:
+
[source,terminal]
----
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
----
Revised: . Create the `ServiceMonitor` CR:
Original: = Enabling monitoring by using a service monitor for the {cert-manager-operator}
You can enable monitoring and metrics collection for the {cert-manager-operator} by using a service monitor to perform the custom metrics scraping.
* You have access to the cluster with `cluster-admin` privileges.
* The {cert-manager-operator} is installed.
. Add the label to enable cluster monitoring by running the following command:
+
[source,terminal]
----
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
----
. Create a service monitor:

.. Create a YAML file that defines the `Role`, `RoleBinding`, and `ServiceMonitor` objects:
.Example `monitoring.yaml` file

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus-k8s
namespace: cert-manager
rules:
- apiGroups:
- ""
resources:
- services
- endpoints
- pods
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: prometheus-k8s
namespace: cert-manager
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: prometheus-k8s
subjects:
- kind: ServiceAccount
name: prometheus-k8s
namespace: openshift-monitoring
---
app.kubernetes.io/component: controller
- interval: 30s
port: tcp-prometheus-servicemonitor
scheme: http
matchLabels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: cert-manager
app.kubernetes.io/name: cert-manager
Revised: After the `ServiceMonitor` CR is created, the user workload Prometheus instance begins metrics collection from the {cert-manager-operator} operands. The collected metrics are labeled with `job="cert-manager"`,`job="cert-manager-cainjector"`, and `job="cert-manager-webhook"`.
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
Revised: As a cluster administrator, or as a user with view access to all namespaces, you can query {cert-manager-operator} operands metrics by using the {product-title} web console or the command-line interface (CLI). For more information, see "Accessing metrics".
Original: = Querying metrics for the {cert-manager-operator}
After you have enabled monitoring for the {cert-manager-operator}, you can query its metrics by using the {product-title} web console.
* You have enabled monitoring and metrics collection for the {cert-manager-operator}.
. From the {product-title} web console, navigate to *Observe* -> *Metrics*.
. Add a query by using one of the following formats:

** Specify the endpoints:
Revised: . In the query field, enter the following PromQL expressions to query the {cert-manager-operator} operands metric for each operand:
Original: * A known issue exists where a Technology Preview-enabled cluster has Sigstore verification for payload images in `policy.json`, but the Podman version in the base image does not support Sigstore configuration, so the new node is not available. As a workaround, the node starts running when the Podman version in the base image does not support Sigstore, so use the default `policy.json` that does not have Sigstore verification if the base image is 4.11 or earlier. (link:https://issues.redhat.com/browse/OCPBUGS-52313[OCPBUGS-52313])
Revised: * A known issue exists where a Technology Preview-enabled cluster has Sigstore verification for payload images in the `policy.json` file, but the Podman version in the base image does not support Sigstore configuration, so the new node is not available. As a workaround, the node starts running when the Podman version in the base image does not support Sigstore, so use the default `policy.json` file that does not have Sigstore verification if the base image is 4.11 or earlier. (link:https://issues.redhat.com/browse/OCPBUGS-52313[OCPBUGS-52313])
Original: * Previously, if you tried to update a hosted cluster that used in-place updates, the proxy variables were not honored and the update failed. With this release, the pod that performs in-place upgrades honors the cluster proxy settings. As a result, updates now work for hosted clusters that use in-place updates. (link:https://issues.redhat.com/browse/OCPBUGS-57432[OCPBUGS-57432])
Revised: * Previously, if you tried to update a hosted cluster that used in-place updates, the proxy variables were ignored and the update failed. With this release, the pod that performs in-place upgrades honors the cluster proxy settings. As a result, updates now work for hosted clusters that use in-place updates. (link:https://issues.redhat.com/browse/OCPBUGS-57432[OCPBUGS-57432])