A new feature is being added to the "edpm_update" ansible role in order to leverage kpatch (live kernel update). Proper documentation must be created.

Here's a bit of context and data to make writing the doc easier:

By default, the feature is disabled, the user has to pass a new parameter to the service: edpm_update_enable_kpatch: true

Toggling this boolean will disable kernel and kernel-core package update in the run, and install the valid kpatch-patch-KERNEL_VERSION package instead.

Note that live patches like that are more for a "quick way to fix a bug or a CVE", but is in no way a 1:1 replacement to a proper kernel and system update. In case a user wants to address a CVE or a bug via kpatch, they want to check the kpatch content in the Red Hat Errata to ensure the package fixes the needed issue.

References:

• Red Hat Live Kernel patching: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/applying-patches-with-kernel-live-patching_managing-monitoring-and-updating-the-kernel

Detailed doc plan template for refinement:

• Is this feature fully supported or technical preview?

• • Full support: Documentation will be published on the customer portal
  • Tech preview (TP): Documentation is not published, release note only
  • TP exception: If there is a strong customer demand for testing this feature and the writer has capacity, dev/PM can author a KB article or gdoc and if the writer has capacity they can review/edit the article.
  • A: TP exception

• Does the procedural content need to be tested by QE?

• • Yes - QE needs to create a doc testing story per How-to Jira with the docs team
  • No - Exemption approved by <STAKEHOLDER NAME>
  • A: Yes, manual validation at least

• Does the doc epic need a release note in addition to the parent feature?

• • Yes - Writer fills in the Release Note Text and Release Note Type in the doc epic fields (not the engineering epic)
  • No - The engineering feature or epic might still need a release note. Engineers need to follow the guidance set in[ How-to Jira with the docs team|https://spaces.redhat.com/display/RHOSPDOC/How-to-Jira+with+the+RHOS+docs+team.]
  • A: The release note should be on the Feature

• Are there any upstream or internal resources that the writer can use for planning and drafting the content? 

• • Steps to enable kpatch on Compute nodes: https://docs.google.com/document/d/10TKgJNnTNJHD1-o58Cx3NL9xhPSZ58ltWQ4VQzzK6Ss/edit?tab=t.0#heading=h.nnxnrgdlpzak 
  • Demo: https://drive.google.com/drive/folders/1nw2HVsROKz1Ss-YLtKfCFoflbEoWEezi 

• Does the content require input from multiple DFGs?

• • Yes - Writer creates spikes or stories under this epic and assign them to the relevant writers for scoping
  • No - Stories are not required unless the epic needs to be divided to user stories that can be delivered separately (for personal use, consider sub-tasks instead)
  • A: No

• What type of information does the user need to know in order to use the feature?

• • Procedures to implement or enable the feature
  • Procedures to customize or configure the feature after installation
  • Procedures or considerations for upgrades, adoption, or minor updates
  • Procedures to verify that the feature is enabled and is working as expected
  • Procedures to operate or maintain the feature
  • Concepts that need to be explained or planning decisions that must be made before the user can perform any of these procedures
  • Permissions level required (RHOSO/OCP) or security considerations
  • Known issues, limitations, or troubleshooting guidance
  • A:
    • A procedure to use the feature (it is optional)
    • Verification that the procedure took effect
    • Considerations: we're enabling a feature but not guaranteeing that it can work well with all workloads. (Should include a link to RHEL docs about kpatch.)
    • A note: the kpatch service cannot be disabled via EDPM but we can switch the kpatch param to "false" to return to the normal way of updating kernel

• Does the content need to be included in any of the following guides?

• • Validated architecture (VA) guide: Is the content a part of a VA workflow, such as HCI, NFV, BGP, etc?
  • Planning guide: Are there prerequisites or planning decisions to add to the Planning guide? 
  • Deployment/Customization guide: Does the feature need to be enabled during the deployment  process, or can it be enabled post-deployment?
  • Adoption/minor updates guide: Are there any considerations or impact of this feature on adoption from pre-18 environments or from earlier 18z versions? At what point during the minor update would a customer need to enable kpatch? https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/updating_your_environment_to_the_latest_maintenance_release/index
  • A:
    • For FR3 time frame we'd like to have a KCS with the kpatch instructions, and a note/link from the minor update guide. This is to avoid conflicting with the operating system update split off from the update procedure, which is also targeted at FR3.
    • Later we would merge the KCS into the main update docs.