karpenter: parseRam: Accept decimal and Pi/Ei quantities - #1246
Open
RajPrakash681 wants to merge 1 commit into
Open
karpenter: parseRam: Accept decimal and Pi/Ei quantities#1246RajPrakash681 wants to merge 1 commit into
RajPrakash681 wants to merge 1 commit into
Conversation
Signed-off-by: RajPrakash681 <rjnt452@gmail.com>
RajPrakash681
requested review from
ashu8912,
illume,
joaquimrocha,
skoeva,
sniok,
vyncent-t and
yolossn
as code owners
August 25, 2026 10:08
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
parseRammatched memory quantities against/^(\d+)([KMGT]i?)?$/i, which rejects two valid forms and returns0for both:1.5Gihas no digit-only mantissa, so a NodePool withspec.limits.memory: 1.5Gishowed its limit as0. Because the callers treatlimit > 0as "a limit exists", the view then reported "No limit" for a NodePool that has one, and the percentage bar was scaled against a total of 1 byte.T, so2Pireturned0.The suffixes that did parse were also scaled with the wrong base. Kubernetes reads a suffix without
ias a decimal multiple and one withias binary, so1Gis 10^9 bytes while1Giis 2^30. The old map sent both to 1024^3, making unsuffixed limits read about 7% high.Related Issue
Fixes #1245
Changes
parseRamnow accepts an optional fractional part, coversPandE, and picks base 1000 or 1024 from the presence of theisuffix. Unparseable input and an unknown unit still return 0, andiis only accepted when it follows a unit.karpenter/src/helpers/parseRam.test.tscovering decimals,Pi/Ei, the decimal-versus-binary distinction, plain byte counts, and the unparseable cases. Three of the five fail against the previous implementation.I did not switch to the SDK's
parseRamfrom@kinvolk/headlamp-plugin/lib/lib/units: it handlesPi/Eiand the base correctly, but in the pinned 0.14.0 it takes the mantissa from a leading-digits match, so1.5Gicomes back as1instead of1610612736. That is better than the current0but still wrong, so fixing the local helper avoids trading one bug for another.Steps to Test
cd karpenter && npm install && npm run test— the fiveparseRamcases pass.npm run lint && npm run tsc— both clean.mainforkarpenter/src/helpers/parseRam.tsxonly, keeping the test file, and re-run: the decimal,Pi/Ei, and decimal-multiple cases fail.spec.limits.memory: 1.5Giand open Karpenter → NodePools. The Memory column reads1.5Giwith a scaled bar instead of0 (No limit).