Summary

Evaluate and implement version history tracking for NodePools, similar to how HostedCluster tracks version history via ClusterVersionStatus.History.

Background

Today, NodePool.Status.Version holds only a single string representing the current semantic version. There is no record of previous versions applied to a NodePool. In contrast, HostedCluster already maintains a version history via ClusterVersionStatus.History (an ordered list of configv1.UpdateHistory entries with state and timestamps).

The enhancement OCPSTRAT-1751 (openshift/enhancements#1950) introduces ControlPlaneVersionStatus to independently track management-side control plane component version history. Adding version history to NodePools would complement this by providing complete upgrade visibility across the entire cluster lifecycle.

Motivation

• Operational visibility: Operators managing multiple NodePools per HostedCluster have no record of when upgrades occurred or their progression.
• Audit and compliance: A version history with timestamps enables incident investigation and compliance reporting.
• Upgrade failure tracking: If a NodePool upgrade fails and is retried, the failure history is currently lost. History entries with Partial/Completed state would preserve this.
• Multi-NodePool environments: Different NodePools may upgrade at different times with different strategies (Replace vs InPlace). History per NodePool captures this.

Scope

• Design a NodePoolVersionHistory type (or reuse existing types) to track version transitions with state and timestamps.
• Add a VersionHistory field to NodePoolStatus.
• Update the NodePool controller to populate history entries on version changes.
• Consider history size limits and pruning strategy (the control plane enhancement caps at 100 entries with weighted pruning).
• Update documentation and API references.

Notes

• Version skew validation (n-3 minor version rule) does not require NodePool history — it compares two current values. This epic is primarily about observability and operational tooling.
• This should be coordinated with the control plane version status enhancement (OCPSTRAT-1751) for consistency in approach and API patterns.