Patching
Apply approved operating-system updates to managed Linux hosts.
Patching applies operating-system updates to Infra nodes through a reviewed maintenance plan. Guest operating systems remain the responsibility of the workload owner unless a separate guest-management procedure is configured.
Patch policy
Open Operations → Patching → Policies and define the eligible distributions, package repositories, update class, exclusions, and reboot policy. Nodes must have access to the approved repositories or an internal mirror.
The default policy selects security updates from the approved repositories and has no package exclusions. Select all approved updates when the wider package change is intended. Record exclusions with an owner and review date.
Reboots require the approved maintenance step by default. A package manager reporting that a reboot is needed does not itself authorize a host restart. Preflight is required, and the default failure policy pauses the rollout after a failed node sequence.
Package selection is resolved for the node's operating system. Unsupported repository metadata or distribution versions fail validation rather than being treated as successfully patched.
Preview and apply
- Open Operations → Patching → Policies, select a policy, and choose the target nodes.
- Refresh the available-update inventory.
- Review package versions, exclusions, reboot requirements, and drain blockers.
- Create a maintenance plan with the intended concurrency.
- Run the plan and inspect each node's patch operation.
The normal sequence cordons and drains compute, validates storage safety, applies updates, reboots when approved, verifies health, and restores admission. A host that fails validation remains cordoned.
Package manager failures
A repository authentication error stops package resolution. A package lock held by another process leaves the patch step waiting or failed according to its timeout. A package installation failure can leave some packages updated and others unchanged.
Infra records the package-manager result and observed versions. It does not promise transactional rollback of operating-system packages. Use the distribution's recovery tools or reprovision from an approved image when the host cannot be repaired reliably.
Kernel and hypervisor updates
A kernel or hypervisor update can change CPU capabilities, device behavior, or migration compatibility. Test it on a canary pool before a region-wide rollout. Verify that the node still supports the pool's declared CPU profile before uncordoning it.
A reboot is not complete until the node reconnects with the intended identity, required services pass health checks, and storage or mesh dependencies recover. A reachable management controller alone is insufficient.
Compliance view
The patch inventory shows last scan, available updates, applied versions, and exceptions. A recent scan is distinct from a successful patch operation. Exceptions should identify an owner and review date so excluded packages remain an explicit operational decision.
Use Audit log for policy and approval history and Agent updates for updating Infra's own node software.
Kernel livepatch waves distinguish live-applicable fixes from reboot-required updates. A successful artifact install alone does not establish that the running kernel has the intended patch.