Our float parsing logic for olm.maxOpenShiftVersion has a bug related to floating-point math. For example:
- 4.18 (float) parsed to 4.18.0 (semver), but
- 4.19 (float) parsed to 4.20.0 (semver)
This PR resolves that bug, adds regression tests, and also does some slight refactoring to make the overall max OCP version logic easier to understand for maintainers.
NOTE: This may not actually be reproducible on 4.18 with any operators current in the catalog since it seems like our buggy logic happens to work with a floating point value like `4.18`. However, there are likely other inputs that trigger similar bugs, so we want to proactively fix this bug in 4.18 because we know that our floating point math-based parsing is fundamentally flawed.
- clones
-
OCPBUGS-56796 Component Readiness: [OLM] [OCPFeatureGate:NewOLM] test regressed
-
- Closed
-
- depends on
-
OCPBUGS-56825 [release-4.19] OLMv1: faulty parsing of olm.maxOpenShiftVersion allows cluster upgrades when they should be blocked
-
- Closed
-
- duplicates
-
OCPBUGS-57767 [release-4.18] OLMv1: faulty parsing of olm.maxOpenShiftVersion allows cluster upgrades when they should be blocked
-
- Closed
-