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

[RajPrakash681]

Description

karpenter/src/helpers/parseRam.tsx matches the quantity against /^(\d+)([KMGT]i?)?$/i. Two valid Kubernetes memory quantities fall outside that pattern and return 0:

• Decimals. 1.5Gi has no digit-only mantissa, so the match fails. A NodePool with spec.limits.memory: 1.5Gi displays its memory limit as 0, and because the code treats limit > 0 as "a limit exists", the view then reports "No limit" for a NodePool that has one.
• Pi and Ei. The unit group only covers K, M, G and T. 2Pi returns 0.

There is also a unit-semantics problem in the values that do parse. Kubernetes treats the suffixes without i as decimal multiples and the i suffixes as binary ones, so 1G is 10^9 bytes and 1Gi is 2^30. The helper maps both to 1024^3, so an unsuffixed-form limit reads about 7% high.

Affected code

karpenter/src/helpers/parseRam.tsx, used by NodePool/List.tsx and NodePool/Details.tsx for both status.resources.memory and spec.limits.memory.

Steps to reproduce

1. Apply a NodePool with spec.limits.memory: 1.5Gi.
2. Open Karpenter → NodePools.

Current behaviour

The Memory column shows 0 (No limit), and the percentage bar has a total of 1 byte. The details page shows the same. Using 2Pi behaves identically.

Expected behaviour

The limit is parsed as 1610612736 bytes and rendered as 1.5Gi, and the bar is scaled against it.

Notes

Reproduced with a unit test calling the helper directly:

parseRam('64Gi')  = 68719476736
parseRam('1.5Gi') = 0
parseRam('1.5G')  = 0
parseRam('700Mi') = 734003200
parseRam('2Pi')   = 0
parseRam('1000')  = 1000

The SDK's parseRam in @kinvolk/headlamp-plugin/lib/lib/units handles Pi/Ei and the decimal-vs-binary distinction, but in the pinned 0.14.0 it parses the mantissa with a leading-digits match, so 1.5Gi comes back as 1 rather than 1610612736. Fixing the local helper avoids swapping this bug for that one.