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: ** *Consequence*: Two services were generated for the same deployment. One generated by `controller-gen` and added to the bundle manifests and the other that the OLM created.
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: ** *Fix*: Make OLM find an already existing service called `webhook-service` in the cluster because the deployment is called `webhook`.
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: * Using `imageRepoSecret` object in conjunction with DTK as the image stream results in `authorization required` error.
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: ** *Cause*: On the Kernel Module Management (KMM) Operator, when you set `imageRepoSecret` object in the KMM module, and the build's resulting container image is defined to be stored in the cluster's internal registry, the build fails to push the final image and generate an `authorization required` error.
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: ** *Fix*: When the `imageRepoSecret` object is user-defined, it is used as both a pull and push secret by the build process. To support using the cluster's internal registry, you must add the authorization token for that registry to the `imageRepoSecret` object. You can obtain the token from the "build" service account of the KMM module's namespace.
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: * Creating or deleting the image or creating an MCM module does not load the module on the 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: ** *Cause*: In a hub and spoke environment, when creating or deleting the image in registry, or when creating a `ManagedClusterModule` (MCM), the module on the spoke cluster is not loaded.
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: ** *Fix*: The `imageRepoSecret` object configuration is now also used in the build process. The `imageRepoSecret` object specified must include all registries that are being used.
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: ** *Fix*: KMM, now, collects orphaned failing pods upon the modules deletion for garbage.
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: * The KMM Operator tries to create a MIC even when the node selector does not match.
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: ** *Consequence*: The KMM Operator reports an error when reconciling a module that does not target any node.
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: ** *Consequence*: When the reboot happens quickly, in less time than the grace period, the node state does not change. After the node reboots, KMM does not load the kernel module again.
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: ** *Fix*: Instead of relying on the condition state, NMC can rely on the `Status.NodeInfo.BootID` field. This field is set by kubelet based on the `/proc/sys/kernel/random/boot_id` file of the server node, so it is updated after each reboot.
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: ** *Cause*: The Node Machine Configuration (NMC) controller gets spammed with events from node heartbeats. The node heartbeats let the Kubernetes API server know that the node is still connected and functional.
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: ** *Consequence*: The spamming causes a constant reconciliation even when there is no module, and therefore no NMC, are applied to the cluster.
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: ** *Fix*: The NMC controller, now, filters the node's heartbeat from its reconciliation loop.
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: * NMC status contains toleration values, even though there are no tolerations in the `NMC.spec` or in the module.
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: ** *Cause*: The Node Machine Configuration (NMC) status contains toleration values, even though there are no tolerations in the `NMC.spec` or in the module.
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: * The KMM Operator version 2.4 fails to start properly and cannot list the `\modulebuildsignconfigs\` resource .
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: ** *Cause*: On the Kernel Module Management (KMM) Operator, when the Operator is installed using Red Hat Konflux, it does not start properly because the log files contain errors.
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: ** *Fix*: The Cluster Service Version (CSV) file is updated to list the `\modulebuildsignconfigs\` and the `moduleimagesconfig` resources .
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: * The Red Hat Konflux build does not include version and git commit ID in the Operator logs.
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: ** *Cause*: On the Kernel Module Management (KMM) Operator, when the Operator was built using Communications Platform as a Service (CPaas), the build included the Operator version and git commit ID in the log  files. However, with Red Hat Konflux these details are not included in the log files.
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: ** *Result:* The KMM Operator build now includes the Operator version and git commit ID in the log files.
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: ** *Cause*: On the Kernel Module Management (KMM) Operator, the image pull policy for the puller pod and the worker pod is different.
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: ** *Consequence*: An image can be considered as existing while, in fact, it is not.
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: ** *Fix*: Make the image pull policy of the pull pod the same as the pull policy defined in the KMM module since its the same policy that is used by the worker pod.
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: ** *Result:* The MIC represents the state of the image in the same way the worker pod accesses it.
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: * The `job.dcDelay` example in the documentation should specify `0s` instead of `0`.
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: ** *Cause*: The Kernel Module Management (KMM) Operator default `job.gcDelay` duration field is `0s` but the documentation mentions the value as `0`.
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: ** *Consequence*: Entering a custom value of `60` instead of `60s` or `1m` might result in an error due to the wrong input type.
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: ** *Fix*: The `job.gcDelay` field in the documentation is updated to default value of `0s`.
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: * The KMM Operator Hub environment does not work because of missing MIC and MBSC CRDs.
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: ** *Cause*: The Kernel Module Management (KMM) Operator hub environment only generates Custom Resource Definitions (CRD) files based on the `api-hub/` directory. As a result, this does not contain some CRDs that are required for the KMM Operator Hub environment, such as, `ModuleImagesConfig` (MIC) resource and Managed Kubernetes Service (MBSC).
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: ** *Consequence*: The KMM Operator hub environment cannot work because it tries to start controllers reconciling CRDs that do not exist in the cluster.
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: ** *Fix*: The fix generates all CRD files into the `config/crd-hub/bases` directory, but only applies the resources to the cluster that it actually needs.
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: * The KMM OperatorHub environment cannot build when finalisers are not set on a resource.
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: ** *Cause*: The Kernel Module Management (KMM) Operator displays an error with the `ManagedClusterModule` controller failing to build. This is due to the missing `ModuleImagesConfig` (MIC) resource finalizers and Role-based Action Control (RBAC) permissions for the KMM OperatorHub environment.
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: ** *Result:* The KMM OperatorHub environment builds images without errors with the `ManagedClusterModule` controller.
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: * The `PreflightValidationOCP` custom resource with a `kernelVersion: tesdt` causes the KMM Operator to panic.
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: ** *Cause*: Creating a `PreflightValidationOCP` custom resource (CR), with a `kernelVersion` flag that is set to `tesdt`, causes the Kernel Module Management (KMM) Operator to generate a panic runtime error.
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: ** *Fix*: A webhook - a method for one application to automatically send real-time data to another application when a specific event occurs - is now added to the `PreflightValidationOCP` CR.
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: ** *Result:* The `PreflightValidationOCP` CR with invalid kernel versions can no longer be applied to the cluster, therefore, preventing the Operator from generating a panic runtime error.
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: ** *Cause*: Creating a `PreflightValidationOCP` custom resource (CR), with a `kernelVersion` flag that is different from the one of the cluster, does not work.
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: ** *Fix*: You must use the `PreflightValidationOCP` CR and explicitly set the `dtkImage` field in the CR.
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: * Using `imageRepoSecret` in conjunction with DTK as image stream gets authorization required error.
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: * The `ModuleUnloaded` event does not appear when a module is `Unloaded`.
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: ** *Cause*: When a module is `Loaded` (using the create a `ModuleLoad` event) or `Unloaded ` (using the create a `ModuleUnloaded` event) the events might not appear. This happens when you load and unload the kernel module in a quick succession.
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: ** *Consequence*: The `ModuleLoad` and the `ModuleUnloaded` events might not appear in {product-title}.
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: ** *Fix*: Introduce an alerting mechanism for this potential behavior and for awareness when working with modules.
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: ** *Cause*: On the Kernel Module Management (KMM) Operator, when you set the `imageRepoSecret` in the KMM module, and the build's resulting container image is defined to be stored in the cluster's internal registry, the build fails to push the final image and generate an `authorization required` error.
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: * The KMM and KMM-hub Operators have been assigned the "Meets Best Practices" label in the