Skip to content

karpenter: parseRam: Accept decimal and Pi/Ei quantities - #1246

Open
RajPrakash681 wants to merge 1 commit into
headlamp-k8s:mainfrom
RajPrakash681:fix/karpenter-ram-quantity
Open

karpenter: parseRam: Accept decimal and Pi/Ei quantities#1246
RajPrakash681 wants to merge 1 commit into
headlamp-k8s:mainfrom
RajPrakash681:fix/karpenter-ram-quantity

Conversation

@RajPrakash681

Copy link
Copy Markdown

Summary

parseRam matched memory quantities against /^(\d+)([KMGT]i?)?$/i, which rejects two valid forms and returns 0 for both:

  • Decimals. 1.5Gi has no digit-only mantissa, so a NodePool with spec.limits.memory: 1.5Gi showed its limit as 0. Because the callers treat limit > 0 as "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.
  • Pi and Ei. The unit group stopped at T, so 2Pi returned 0.

The suffixes that did parse were also scaled with the wrong base. Kubernetes reads a suffix without i as a decimal multiple and one with i as binary, so 1G is 10^9 bytes while 1Gi is 2^30. The old map sent both to 1024^3, making unsuffixed limits read about 7% high.

Related Issue

Fixes #1245

Changes

  • parseRam now accepts an optional fractional part, covers P and E, and picks base 1000 or 1024 from the presence of the i suffix. Unparseable input and an unknown unit still return 0, and i is only accepted when it follows a unit.
  • Added karpenter/src/helpers/parseRam.test.ts covering 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 parseRam from @kinvolk/headlamp-plugin/lib/lib/units: it handles Pi/Ei and the base correctly, but in the pinned 0.14.0 it takes the mantissa from a leading-digits match, so 1.5Gi comes back as 1 instead of 1610612736. That is better than the current 0 but still wrong, so fixing the local helper avoids trading one bug for another.

Steps to Test

  1. cd karpenter && npm install && npm run test — the five parseRam cases pass.
  2. npm run lint && npm run tsc — both clean.
  3. Check out main for karpenter/src/helpers/parseRam.tsx only, keeping the test file, and re-run: the decimal, Pi/Ei, and decimal-multiple cases fail.
  4. Against a cluster running Karpenter, apply a NodePool with spec.limits.memory: 1.5Gi and open Karpenter → NodePools. The Memory column reads 1.5Gi with a scaled bar instead of 0 (No limit).

Signed-off-by: RajPrakash681 <rjnt452@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

karpenter: parseRam returns 0 for decimal and Pi/Ei memory quantities

1 participant